boost-1.32.0 does not create the libboost_<library>-gcc.so files (for example libboost_filesystem-gcc.so). I don't know if this is a new boost naming convention or a redhat one, but some autotooled programs (gigi.sourceforge.net) refuses to build without it. This could be solved by creating the symlinks : ln -sf /usr/lib/libboost_date_time.so /usr/lib/libboost_date_time-gcc.so ln -sf /usr/lib/libboost_filesystem.so /usr/lib/libboost_filesystem-gcc.so ln -sf /usr/lib/libboost_prg_exec_monitor.so \ /usr/lib/libboost_prg_exec_monitor-gcc.so ln -sf /usr/lib/libboost_program_options.so \ /usr/lib/libboost_program_options-gcc.so ln -sf /usr/lib/libboost_python.so \ /usr/lib/libboost_python-gcc.so ln -sf /usr/lib/libboost_regex.so \ /usr/lib/libboost_regex-gcc.so ln -sf /usr/lib/libboost_signals.so \ /usr/lib/libboost_signals-gcc.so ln -sf /usr/lib/libboost_test_exec_monitor.so \ /usr/lib/libboost_test_exec_monitor-gcc.so ln -sf /usr/lib/libboost_unit_test_framework.so \ /usr/lib/libboost__unit_test_framework-gcc.so Reproducible: Always Steps to Reproduce:
this one is tricky i might need to solve this with a local use flag the majority of users i have been in contact with preferd the names w/o the tool ie -gcc- or -icc- this is how i see the problem looking at your links, you talk about library name, so i guess i make sure i understand you first before i act on it sorry it took so long to respond, clear up if you meant the ommission of -gcc- or not and ill make sure you can choose whichever way you want it selected w/ or w/o the toolname
Just to make it clear, yes, the problem is the omission of the -gcc. But since this is a library that will be used to build other stuff (particularly with portage) I don't think it is a good idea to set an use flag for its name. Some libraries I use, like the naming with -gcc. I did some research and found out that not only redhat use this naming scheme as it is recommended by boost at (http://www.boost.org/more/getting_started.html#Build_Install) . Since boost does not provide custom autoconf macros nor pkg-config files it can be tricky to make autoconf discover the name of the libraries. I contacted the author of the gigi library and told him about the problem, he said that this is the new naming scheme for boost libraries since 1.32.0 and since the library does not compile with earlier versions he thinks he does not needs to check for the older library names. The problem with setting the naming with -gcc is that packages that expect the old naming scheme would not link with the new one. What I suggest, then, is to let boost install whatever name it wants and then make a symlink to the old naming scheme in order to mantain backward compatibility.
i will have to consider the links vs the old lib naming altogether ill try to get some feedback and get back to this soon
I have discovered a related problem with kde-base/kdeedu-3.3.2-r1, it fails compilation as it cannot find the boost library. Here are the important lines where it fails, /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lboost_python collect2: ld returned 1 exit status I have no symlink for this library, $ locate boost_python /usr/lib/libboost_python-gcc-mt-1_32.so.1.32.0 /usr/lib/libboost_python-gcc-1_32.a /usr/lib/libboost_python-gcc-mt-d-1_32.a /usr/lib/libboost_python-gcc-1_32.so.1.32.0 /usr/lib/libboost_python-gcc-d-1_32.a /usr/lib/libboost_python-gcc-d-1_32.so.1.32.0 /usr/lib/libboost_python-gcc-mt-d-1_32.so.1.32.0 /usr/lib/libboost_python-gcc-mt-1_32.a
This is still an issue with KDE 3.* kdeedu packages and USE=python. With boost-1.31 they compile successfully, but 1.32 produces compilation failure due to the lack of symlinks.
kdeedu-3.4_rc1 compiles fine with boost-1.32.0, it even needs this version on amd64
boost 1.32.0 will have the old --layout=system for the short libnames and will create symlinks for the -gcc- versions for all aps that need those ill keep you posted on when 1.32.0-r1 is available, i will revbump it to force an upgrade so everyone has a working version for all situations thanks for your feedback
minidelight ~ # g++ -o demo demo.cpp -lboost_serialization-gcc minidelight ~ # g++ -o demo demo.cpp -lboost_serialization minidelight ~ # ok comitting this ebuid now, it will receive further cleanups, but it is time to have one that works for everyone
ok, give it 35 minutes, sync, merge -r1 all should be fine
