/usr/include/boost/test/impl/execution_monitor.ipp:1346: note: candidates are: boost::execution_exception::execution_exception(boost::execution_exception::error_code, boost::unit_test::const_string, const boost::execution_exception::location&) /usr/include/boost/test/execution_monitor.hpp:85: note: boost::execution_exception::execution_exception(const boost::execution_exception&) make[5]: *** [test_boost.o] Error 1 make[5]: Leaving directory `/var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/build/corelib' make[5]: Entering directory `/var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/build/corelib' rm -f libtest_boost.so .test_boost.dep .libtest_boost.so.stamp if [ '/bin/sh /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/scripts/common/impl/if_diff.sh "ln -f"' != '@:' -a -d /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/status -a -w /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/status -a /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/src/corelib != . ]; then \ rm -f /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/lib/libtest_boost.so /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/lib/libtest_boost.so \ /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/status/.test_boost.dep /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/status/.test_boost.dep; \ [ '@# ' = '@# ' ] || \ rm -f /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/lib/libtest_boost.so /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/lib/libtest_boost.so; \ fi So, but I cannot see more. I have latest boost emerged.
Created attachment 226347 [details] emerge.info emerge --info
Created attachment 226351 [details] build.log build.log
Same here on amd64: /usr/bin/g++ -c -Wall -Wno-format-y2k -pthread -O2 -pipe -march=nocona -fPIC -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fpermissive -D_MT -D_REENTRANT -D_THREAD_SAFE -I/var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/GCC443-ReleaseMTDLL64/inc -I/var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/include -I/etc/ncbi/boost/include -DBOOST_DISABLE_THREADS /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/src/corelib/test_boost.cpp -o test_boost.o /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/src/corelib/test_boost.cpp: In member function 'virtual void ncbi::CNcbiTestsObserver::test_unit_finish(const boost::unit_test::test_unit&, long unsigned int)': /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r3/work/ncbi_cxx--May_15_2009/src/corelib/test_boost.cpp:1429: error: no matching function for call to 'boost::execution_exception::execution_exception(boost::execution_exception::error_code, const char [17])' Maybe we have too new boost libs (snippet from configure output): checking Boost version... 1_42 configure: WARNING: Untested Boost version; may prove incompatible. configure: WARNING: If so, please re-run this script with the flag --without-boost.
Looking at the configure file (.../src/build_system/configure) it looks like they have only tested it with boost 1.35. It also looks like there is a problem with corelib/test_boost.cpp around line 1429 in that it will not build with boost 1.42 (it appears some of the exception handling may have changed). Two solutions appear to be possible: 1) Restrict ncbi-tools++ to <= boost 1.35; of course this may be problematic as there are many other packages that require up-to-date boost releases (some possibilities include gnash, snpfile, glob2, bmpx, inkscape, stellarium, akonadi-server); 2) Add a "-boost" USE flag to the ebuild which makes use of "--without-boost" during the configure step. Of course one could make --without-boost the default configuration and make +boost optional. There is also the possibility of having multiple boost versions installed. It looks like there is some movement in the direction of "eselect"-ing boost but it may not be quite there yet. There appear to be ebuilds for some of boost 1.35 through 1.42 though it would be undesirable to have to maintain 5 boost versions to build various packages. Or one could bump this upstream and file a bug report with NCBI to get ncbi-tools++ to compile with boost-1.42.
It looks like ncbi-tools++ wants boost 1.35 but the current Gentoo version is 1.41 with the development version 1.42 available. At the same time if I run a "make -i" in the build directory the compiles seem to continue properly even with the wrong boost version (makes sense if the only problem is in test_boost.cpp). Argues that the Gentoo USE options should include a "test/-test" options which interface to the configure "--with-check/--without-check" options which I presume would disable all of the test_*.cpp files in src/corelib (this needs to be confirmed). See also Bug #322199 for my suggestions regarding how emerge could be improved for dealing with bugs like this one.
Thank you for your contribution. I have added '--without-boost' to the configuration flags. Please check if this fixes the problem.
Confirming that --without-boost seems to allow the ebuild to run to completion (with boost 1.42.0 installed on the system) and install *many* (270+) files in /usr/bin. 1) There are ~120 test files (test_*, *test, etc.) installed in /usr/bin which are presumably not required for a production installation (argues that there should be a USE=-test/test (== --with-check) option which allows one to build without/with the test programs. Right now the build Somewhat important given that building ncbi-tools++ takes over two and a half hours on a Pentium IV. Presumably with checking the build would take longer. Even if there is no way to disable building the test files they should probably not end up in /usr/bin. 2) There does not appear to be a USE=doc option as there is with ncbi-tools and there appear to be no man pages for many (all?) of the ncbi-tools++ utilities, e.g. splign, asn2fasta, etc. Minimally it looks like the output of "program -help" needs to be turned into a man page at least for the more commonly used programs.
I am not sure if the adjustments to LD_LIBRARY_PATH are implemented properly. The file /etc/env.d/99ncbi-tools++ appears to be added but I am not sure if one should be setting "LD_LIBRARY_PATH" in it. The other env.d files all set "LDPATH" and then appear to run etc-update to update /etc/ld.so.conf. One might want to check some of the other ebuilds, such as alsa, jdk, fltk, R, etc. to see how their ebuilds setup additional library search directories. As currently implemented I had to explicitly set LD_LIBRARY_PATH myself for programs like blastp to run.
My /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r4/temp/build.log contains: [start of the file] * CPV: sci-biology/ncbi-tools++-2009.05.15-r4 * REPO: gentoo * USE: elibc_glibc kernel_linux sqlite userland_GNU x86 >>> Unpacking source... >>> Unpacking ncbi_cxx--May_15_2009.tar.gz to /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r4/work >>> Source unpacked in /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r4/work >>> Preparing source in /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r4/work/ncbi_cxx--May_15_2009 ... * Applying ncbi-tools++-2009.05.15-gcc44.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r4/work/ncbi_cxx--May_15_2009 ... configure: creating cache config.cache checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes adjusted C compiler: /usr/lib/distcc/bin/gcc adjusted C++ compiler: /usr/lib/distcc/bin/g++ checking whether /usr/lib/distcc/bin/gcc supports -Wl,-E... yes /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../crt1.o: In function `_start': /var/tmp/portage/sys-libs/glibc-2.11.2/work/glibc-2.11.2/csu/../sysdeps/i386/elf/start.S:115: undefined reference to `main' collect2: ld returned 1 exit status distcc[30939] ERROR: compile (null) on localhost failed configure: WARNING: Unable to find static libstdc++ requested by --with-bin-release. checking whether ln -s works... yes checking for ranlib... ranlib I just recompiled sys-libs/glibc-2.11.2, then sys-devel/gcc-4.4.3-r2, then again sys-libs/glibc-2.11.2 to make sure ... # gcc-config -l [1] i686-pc-linux-gnu-3.3.6 [2] i686-pc-linux-gnu-4.2.4 [3] i686-pc-linux-gnu-4.3.4 * [4] i686-pc-linux-gnu-4.4.3 # What's going on? Nevertheless, I compiled&installed sci-biology/ncbi-tools++-2009.05.15-r4 on ~x86.
(In reply to comment #9) > Nevertheless, I compiled&installed sci-biology/ncbi-tools++-2009.05.15-r4 on > ~x86. against dev-libs/boost-1.42.0 A summary from the build.log: CFLAGS = -Wall -Wno-format-y2k -pthread -O2 -march=pentium4 -mmmx -msse -msse2 -pipe -fno-strict-aliasing -ggdb -fPIC CXXFLAGS = -Wall -Wno-format-y2k -pthread -O2 -march=pentium4 -mmmx -msse -msse2 -pipe -fno-strict-aliasing -ggdb -fPIC CPPFLAGS = -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fpermissive -D_MT -D_REENTRANT -D_THREAD_SAFE LDFLAGS = -pthread -Wl,-O1 -O LIBRARIES: build as dynamic by default FEATURES: MT DLL DLL_BUILD unix WinMain Linux PACKAGES: enabled: Z BZ2 LZO2 LZO PCRE GNUTLS OPENSSL MySQL BerkeleyDB PYTHON PYTHON25 Boost.Spirit OpenGL GLUT ICU EXPAT SABLOT LIBXML LIBXSLT SQLITE SQLITE3 JPEG PNG TIFF GIF XPM FreeType disabled: LocalZ LocalBZ2 LocalPCRE Sybase DBLib FreeTDS BerkeleyDB++ ODBC PYTHON23 PYTHON24 CPPUNIT Boost.Regex Boost.Test Boost.Test.Included Boost.Threads C-Toolkit MESA FLTK wxWindows wxWidgets wx2.8 Fast-CGI LocalSSS LocalNCBILS LocalMSGMAIL2 SSSUTILS SSSDB SP ORBacus Xerces Xalan OECHEM UNGIF PROJECTS: enabled: serial objects bdb dbapi app ctools algo disabled: local_lbsm connext ncbi_crypt gui gbench # emerge -pv ncbi-tools++ These are the packages that would be merged, in order: [ebuild R ] sci-biology/ncbi-tools++-2009.05.15-r4 USE="sqlite" 0 kB ? Where is the test use flag? Hmm, ok, I see it is commented out in the ebuild. # $Header: /var/cvsroot/gentoo-x86/sci-biology/ncbi-tools++/ncbi-tools++-2009.05.15-r4.ebuild,v 1.1 2010/05/31 22:05:20 weaver Exp $
(In reply to comment #8) > I am not sure if the adjustments to LD_LIBRARY_PATH are implemented properly. > The file /etc/env.d/99ncbi-tools++ appears to be added but I am not sure if one > should be setting "LD_LIBRARY_PATH" in it. The other env.d files all set > "LDPATH" and then appear to run etc-update to update /etc/ld.so.conf. One > might want to check some of the other ebuilds, such as alsa, jdk, fltk, R, > etc. to see how their ebuilds setup additional library search directories. I can't comment on LDPATH. Google directs me to: http://blog.flameeyes.eu/2008/12/30/avoid-ldpath-pollution > As currently implemented I had to explicitly set LD_LIBRARY_PATH myself for > programs like blastp to run. $ unset LD_LIBRARY_PATH $ /usr/bin/blastp /usr/bin/blastp: error while loading shared libraries: libblastinput.so: cannot open shared object file: No such file or directory $ Right. The directory where to look for the libs can be specified during compile time. The "man ld" and "-rpath" is your friend. I believe somebody from toolchain can review this. I haven't bothered to re-try to build the ncbi-tools++ now again to see what arguments are passed to the linker that they do not specify the future library location. > Af far as I can say the /etc/env.d/99ncbi-tools++ now zaps my LD_RUN_PATH and sets it only to "/usr/lib/ncbi-tools++". I am quite sure there should be LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/ncbi-tools++ Moreover, in my ~/.bash_profile I append some values to $LD_LIBRARY_PATH but they get overwritten by the single value from /etc/env.d/99ncbi-tools++ file. :(
If you don't mind me not reading all the comments on the bug, I can give a basic idea regarding how to handle library paths here: - env.d files *should never use LD_LIBRARY_PATH* as that's an environment variable that is left to the user and some software; - if you need to add a sub-directory with some libraries to the *global* library search path, use LDPATH; - if the libraries are internal, and thus used only by the binaries shipping with that package, use -W,-rpath,/usr/lib/${PN} (or whatever) during link/build time.
(In reply to comment #12) > - if the libraries are internal, and thus used only by the binaries shipping > with that package, use -W,-rpath,/usr/lib/${PN} (or whatever) during link/build > time. Thanks, I think the last is sufficient here and actually, in comment #10 I posted what kicked in my case: LDFLAGS = -pthread -Wl,-O1 -O Would you please also glance over comment #9 here? checking whether /usr/lib/distcc/bin/gcc supports -Wl,-E... yes /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../crt1.o: In function `_start': /var/tmp/portage/sys-libs/glibc-2.11.2/work/glibc-2.11.2/csu/../sysdeps/i386/elf/start.S:115: undefined reference to `main' collect2: ld returned 1 exit status Is that my DISTCC machine (amd64) with cross-dev has out of sync glibc or gcc or is that a local problem on the actual host machine (~x86)? As I wrote, on the host I even recompiled glibc and gcc with no effect. So either to do something with cross-dev or update glibc/gcc on DISTCC machine? Or else? ;-)
It looks like a distcc problem itself, it's building locally so it's not a remote box problem; but without config.log I can't say much more.
Created attachment 235215 [details] config.log Re-tested again and once src_compile() started I interrupted the process. I do not see anything related in the config.log, though. :( >>> Emerging (1 of 1) sci-biology/ncbi-tools++-2009.05.15-r4 * ncbi_cxx--May_15_2009.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: sci-biology/ncbi-tools++-2009.05.15-r4 * REPO: gentoo * USE: elibc_glibc kernel_linux sqlite userland_GNU x86 >>> Unpacking source... >>> Unpacking ncbi_cxx--May_15_2009.tar.gz to /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r4/work >>> Source unpacked in /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r4/work >>> Preparing source in /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r4/work/ncbi_cxx--May_15_2009 ... * Applying ncbi-tools++-2009.05.15-gcc44.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/sci-biology/ncbi-tools++-2009.05.15-r4/work/ncbi_cxx--May_15_2009 ... configure: creating cache config.cache checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes adjusted C compiler: /usr/lib/distcc/bin/gcc adjusted C++ compiler: /usr/lib/distcc/bin/g++ checking whether /usr/lib/distcc/bin/gcc supports -Wl,-E... yes /usr/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../crt1.o: In function `_start': /var/tmp/portage/sys-libs/glibc-2.11.2/work/glibc-2.11.2/csu/../sysdeps/i386/elf/start.S:115: undefined reference to `main' collect2: ld returned 1 exit status distcc[11804] ERROR: compile (null) on localhost failed configure: WARNING: Unable to find static libstdc++ requested by --with-bin-release. checking whether ln -s works... yes
+*ncbi-tools++-2010.06.15-r1 (04 May 2011) + + 04 May 2011; Justin Lecher <jlec@gentoo.org> + -ncbi-tools++-2009.05.15-r6.ebuild, ncbi-tools++-2010.06.15.ebuild, + +ncbi-tools++-2010.06.15-r1.ebuild, + +files/ncbi-tools++-2010.06.15-asneeded.patch, + +files/ncbi-tools++-2010.06.15-asneeded-ng.patch: + Fix for asneeded, #297193; removed old, #312921 +
