On 01/03/14 13:23, Kacper Kopczyński wrote: > > Hello list, > > > > I've installed newest boost into /usr/local - it's a custom > installation and not via emerge/portage. > > > > Today, after upgrading system, I've found that I need to use > > > > emerge --update --newuse --deep --with-bdeps=y @world > > > > to rebuild some dependencies. > > > > In the process of recompiling I first noticed this strange thing: > > checking for Boost headers version >= 1.36.0... yes > > checking for Boost's header version... 1_55 > > > > Portage installed boost is 1.52, my custom installed one is 1.55. > > > > Then after a few seconds I saw this: > > x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"libixion\" > -DPACKAGE_TARNAME=\"libixion\" -DPACKAGE_VERSION=\"0.5.0\" > -DPACKAGE_STRING=\"libixion\ 0.5.0\" -DPACKAGE_BUGREPORT=\"\" > -DPACKAGE_URL=\"\" -DPACKAGE=\"libixion\" -DVERSION=\"0.5.0\" > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 > -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" > -DHAVE_STDLIB_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1 > -DHAVE_STDBOOL_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BOOST=1 > -DHAVE_BOOST_UNORDERED_MAP_HPP=1 -DHAVE_MDDS_RECTANGLE_SET_HPP=1 > -DHAVE_MDDS_MIXED_TYPE_MATRIX_HPP=1 > -DHAVE_MDDS_MULTI_TYPE_VECTOR_TRAIT_HPP=1 > -DHAVE_BOOST_SYSTEM_ERROR_CODE_HPP=1 -DHAVE_BOOST_THREAD_HPP=1 > -DHAVE_BOOST_PROGRAM_OPTIONS_HPP=1 -I. -I../include > -I../lib/libixion/libixion.la -D_REENTRANT -DMDDS_HASH_CONTAINER_BOOST > -D__IXION_BUILDING_DLL -g -Os -fvisibility=hidden -O2 -pipe > -march=native -c -o ixion_sorter-sort_input_parser.o `test -f > 'sort_input_parser.cpp' || echo './'`sort_input_parser.cpp > > /bin/sh ../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -O2 > -pipe -march=native -Wl,-O1 -Wl,--as-needed -o ixion-parser > ixion_parser-ixion_parser.o ixion_parser-model_parser.o > libixion/libixion-0.6.la -lboost_thread-mt -lboost_system-mt -pthread > -lboost_program_options-mt > > libtool: link: x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Wl,-O1 > -Wl,--as-needed -o .libs/ixion-parser ixion_parser-ixion_parser.o > ixion_parser-model_parser.o -pthread libixion/.libs/libixion-0.6.so > -lboost_thread-mt -lboost_system-mt -lboost_program_options-mt -pthread > > libixion/.libs/libixion-0.6.so: undefined reference to > `boost::thread::start_thread_noexcept()' > > libixion/.libs/libixion-0.6.so: undefined reference to > `boost::thread::join_noexcept()' > > collect2: error: ld returned 1 exit status > > make[2]: *** [ixion-parser] Error 1 > > make[2]: *** Waiting for unfinished jobs.... > > make[2]: Leaving directory > `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory > `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src' > > make: *** [all-recursive] Error 1 > > * ERROR: dev-libs/libixion-0.5.0::gentoo failed (compile phase): > > > > > > ...so it failed because it tried to use my custom boost... I think. > > > > To be sure that this is because of this I moved /usr/local/lib and > /usr/local/include to /root and another compilation of this library > went fine. > > After doing so I runned revdep-rebuild and it had to recompile > libkolabxml because it was linked to boost in /usr/local/lib. > > > > So here is my question: > > If libreoffice does need boost to compile, and I compiled libreoffice > after I installed boost to /usr/local, then why it was able to use > correct version of boost (from /usr not /usr/local)? > > > > Libreoffice is just an example - there are many other programs that > depend on boost, and the boost.thread library is very popular one. > > > > libkolabxml at version 1.0.1 > > libixion at version 0.5.0 > > > > Should I create a bug for these two libraries or this is expected > behaviour? > > > > -- > > Kacper Kopczyński >
There are multiple factors in play, some per package ./configure scripts add -I/usr/local/include so that headers are picked up from there by default, if compiler alone doesn't have that in it's default search path already. There are -L/usr/local/lib added by some, and /usr/local/lib in /etc/ld.so.conf What I'm really trying to say is that you can't install boost safely into /usr/local/lib and include, but you should put it in it's own directory outside of compilers or ld.so's scope, like for example, /home/username/boost, and then when you want something to use it, point the package to search it from there using package specific configure flags and environment variables like LD_LIBRARY_PATH, PKG_CONFIG_PATH, and so forth Bottom line is, It's not a bug you can file to Gentoo's bugzilla, it is expected behavior
