'unit_test_main' failure when compiling statically

[michaelhutt]

When compiling statically (the --static and link=static options), the unit tests are still compiled with -DBOOST_TEST_DYN_LINK, which causes them to reference boost::unit_test::unit_test_main(bool (*)(), int, char**), but during linking an error is produced:

phrase-extract/ScoreFeatureTest.cpp:(.text+0x4f): undefined reference to 'boost::unit_test::unit_testmain(bool ()(), int, char_*)`

...because the static unit_test_framework library (libboost_unit_test_framework.a) has a different function signature for unit_test_main.

I'm running bjam -d+2 -q link=static --static --threading=multi variant=release --with-boost=/path/to/boost

At the start of compilation, I get:

Performing configuration checks

• Shared Boost : yes
• Static Boost : no

So I deleted all of shared library files from my Boost installation, and re-compiled. It gave a 'no' for 'Shared Boost' and a 'yes' for 'Static Boost', but it sill puts the -DBOOST_TEST_DYN_LINK in there and fails at the same spot.

[kpu]

How annoying. Please send me bin/config.log and stdout of the build.

[michaelhutt]

stdout: https://gist.github.com/michaelhutt/1b92d8f2eccb6a9c5ec2 config.log: https://gist.github.com/michaelhutt/c0692c61d14860033382

The exact line I used is:

LDFLAGS="-L/tools/opt/lib/bzip2/bzip2-1.0.6/dist/lib -L/tools/opt/lib/xz/xz-5.2.0/dist/lib -lrt" ./bjam -d+2 -q link=static --static threading=multi variant=release --with-boost=/extra/tempboost/ | tee stdout.txt

[michaelhutt]

Almost forgot, my user-config.jam contains: using intel : linuxgcc49 : : <compileflags>-gcc-name=/tools/compilers/gcc-4.9.0/bin/gcc <linkflags>-gcc-name=/tools/compilers/gcc-4.9.0/bin/gcc ;

[michaelhutt]

Arrg, it seems to work with gcc/g++

[michaelhutt]

This is definitely something with my environment, not moses' fault. Sorry for the noise.

[hieuhoang]

what version of moses are you using? release 3, or the current github version? There has been problems with the unit test before. https://www.mail-archive.com/moses-support%40mit.edu/msg11601.html If everything compiled but the unit test failed, i would just ignore it

[michaelhutt]

It is the current github version. It does look like everything compiled okay. I've apparently modified something locally - a clean checkout seems to build without much massaging. If I figure out exactly what went wrong, I'll post the problem and solution here for anyone else who's searching for that error.

On Fri, Mar 20, 2015 at 6:35 PM, Hieu Hoang notifications@github.com wrote:

what version of moses are you using? release 3, or the current github version? There has been problems with the unit test before. https://www.mail-archive.com/moses-support%40mit.edu/msg11601.html

If everything compiled but the unit test failed, i would just ignore it

Reply to this email directly or view it on GitHub: https://github.com/moses-smt/mosesdecoder/issues/101#issuecomment-84170722

[michaelhutt]

Just to follow up, for posterity: this bug is triggered if I specify a compiler (in user-config.jam) that isn't the default - even another version of GCC.

The workaround is to create a boost distribution that only includes the static libraries. Make sure you run bjam with --clean before you attempt to recompile, or caching will keep -DBOOST_TEST_DYN_LINK around.