Closed dlaehnemann closed 1 year ago
I just saw, that pinning to bison==3.4
was also the fix for the raxml-ng
recipe over at bioconda
...
Am Fri, Apr 21, 2023 at 10:14:08AM -0700 schrieb David Laehnemann:
I just saw, that pinning to
bison==3.4
was also the fix for theraxml-ng
recipe over atbioconda
...
Thanks for the hint to pin bison to some lower version. Unfortunately this does not solve my problem since I need to work with the version provided by the system which in Debian is currently 3.8.2. Do you have any other recommendation? Kind regards, Andreas.
I would recommend using mamba/conda to install the dependencies into an isolated environment with the command I provide above (mamba create ...
) and then activate that environment (mamba activate ...
) to run the build with all the dependencies you installed into it. You don't need root access to install stuff with mamba/conda (or mamba/conda itself), so this should work on any system. Also, from what I understand, none of these dependencies are needed at runtime, so the mamba/conda environment should only need to be activated during the build (howver, this is only true for libpll-2
-- some further dependencies for raxml-ng
are also needed at runtime, in case raxml-ng
was also the case that broke for you).
The installation of mamba itself is also very quick and easy, I recommend this guide:
https://github.com/conda-forge/miniforge#install
You should be up and running in 5 minutest. And if you're the suspicious kind, have a read through the install scripts... ;)
BTW, it took me weeks to finally track this down. So I'll also document this over at raxml-ng
to save others the trouble...
Hi David,
seems like you cloned libpll
and not libpll-2
.
This repository is libpll-2
, which is also the version used by raxml-ng
(and probably most other tools). And libpll-2
does compile with bison 3.8
(I just tested it).
You are right, with the above commands I seem to have cloned libpll
instead of libpll-2
. I was simply following the compilation instructions from the README.md
, that point to libpll
instead of libpll-2
. I created a quick pull request #24 with the docs updates. ;)
However, I can reproduce the same error with libpll-2
, namely with these commands:
mamba create -n libpll_2_build bison=3.8 flex autoconf automake libtool gcc
mamba activate libpll_2_build
git clone https://github.com/xflouris/libpll-2.git
cd libpll-2/
./autogen.sh
./configure
make
This leads to the error:
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC -g -MT libpll_la-parse_utree.lo -MD -MP -MF .deps/libpll_la-parse_utree.Tpo -c -o libpll_la-parse_utree.lo `test -f 'parse_utree.c' || echo './'`parse_utree.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC -g -MT libpll_la-parse_utree.lo -MD -MP -MF .deps/libpll_la-parse_utree.Tpo -c parse_utree.c -fPIC -DPIC -o .libs/libpll_la-parse_utree.o
parse_utree.c:306:6: error: conflicting types for 'pll_utree_error'; have 'void(const char *)'
306 | void pll_utree_error (const char *msg);
| ^~~~~~~~~~~~~~~
parse_utree.y:147:13: note: previous definition of 'pll_utree_error' with type 'void(pll_unode_t *, const char *)' {aka 'void(struct pll_unode_s *, const char *)'}
147 | static void pll_utree_error(pll_unode_t * node, const char * s)
| ^~~~~~~~~~~~~~~
parse_utree.c: In function 'pll_utree_parse':
parse_utree.c:1806:18: warning: passing argument 1 of 'pll_utree_error' from incompatible pointer type [-Wincompatible-pointer-types]
1806 | yyerror (tree, yymsgp);
| ^~~~
| |
| struct pll_unode_s *
parse_utree.c:306:35: note: expected 'const char *' but argument is of type 'struct pll_unode_s *'
306 | void pll_utree_error (const char *msg);
| ~~~~~~~~~~~~^~~
parse_utree.c:70:25: error: too many arguments to function 'pll_utree_error'
70 | #define yyerror pll_utree_error
| ^~~~~~~~~~~~~~~
parse_utree.c:1806:9: note: in expansion of macro 'yyerror'
1806 | yyerror (tree, yymsgp);
| ^~~~~~~
parse_utree.c:306:6: note: declared here
306 | void pll_utree_error (const char *msg);
| ^~~~~~~~~~~~~~~
parse_utree.c:1920:12: warning: passing argument 1 of 'pll_utree_error' from incompatible pointer type [-Wincompatible-pointer-types]
1920 | yyerror (tree, YY_("memory exhausted"));
| ^~~~
| |
| struct pll_unode_s *
parse_utree.c:306:35: note: expected 'const char *' but argument is of type 'struct pll_unode_s *'
306 | void pll_utree_error (const char *msg);
| ~~~~~~~~~~~~^~~
parse_utree.c:70:25: error: too many arguments to function 'pll_utree_error'
70 | #define yyerror pll_utree_error
| ^~~~~~~~~~~~~~~
parse_utree.c:1920:3: note: in expansion of macro 'yyerror'
1920 | yyerror (tree, YY_("memory exhausted"));
| ^~~~~~~
parse_utree.c:306:6: note: declared here
306 | void pll_utree_error (const char *msg);
| ^~~~~~~~~~~~~~~
parse_utree.y: At top level:
parse_utree.y:147:13: warning: 'pll_utree_error' defined but not used [-Wunused-function]
147 | static void pll_utree_error(pll_unode_t * node, const char * s)
| ^~~~~~~~~~~~~~~
make[2]: *** [Makefile:859: libpll_la-parse_utree.lo] Error 1
make[2]: Leaving directory '/path/to/libpll-2/src'
make[1]: *** [Makefile:406: all-recursive] Error 1
make[1]: Leaving directory '/path/to/libpll-2'
make: *** [Makefile:338: all] Error 2
This looks like the same problem.
So maybe you are using some slightly different version of bison 3.8
than the one conda-forge provides for me? The above environment creation got me:
bison 3.8 h9c3ff4c_0 conda-forge/linux-64
And the version given by the tool is:
$ bison --version
bison (GNU Bison) 3.8
Written by Robert Corbett and Richard Stallman.
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Can you try with these instructions and so we can see whether this is a problem with the version on conda-forge
?
Good point, thanks!
I tested with bison 3.8.2
which comes with Ubuntu 22.04:
$ bison --version
bison (GNU Bison) 3.8.2
Written by Robert Corbett and Richard Stallman.
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
OK, seems like the conda-forge
recipe for bison
could do with an update to 3.8.2
. I'll try to get that rolling. If that then fixes the compilation issue here, I'll close this issue.
Alright, the bison
update on conda-forge
to version 3.8.2
has been merged (and is available to install): https://github.com/conda-forge/bison-feedstock/pull/31
And with this version, I can confirm that the build / compiling works with the following setup (as above, just bison pinned to the newest 3.8.2
:
mamba create -n libpll_2_build bison=3.8.2 flex autoconf automake libtool gcc
mamba activate libpll_2_build
git clone https://github.com/xflouris/libpll-2.git
cd libpll-2/
./autogen.sh
./configure
make
It seems like
bison
in its latest version (3.8
) creates incorrect / incompatibleparse_utree
files. I'm just guessing here, but this might be due to breaking changes in3.8
. For me, it works with version3.4
(intermediate versions are not available onconda-forge
, so I can't quickly test them).So as a quick fix, it might be worth recommending a lower
bison
version in theREADME.md
here, and also in projects depending on this library (I came across this inraxml-ng
). And I have no clue how to properly fix this, sorry.Here's a reproducible way of triggering this:
It throws the error below. Note, however, that changing the version to
bison=3.4
allows themake
to succeed.