I emerged dev-libs/boost-1.31.0_alpha1, successfully. But the shared object files and archives libboost_signals.{so,a} libboost_threads.{so,a} and libbost_python.{so,a} are missing. Reproducible: Always Steps to Reproduce: 1.emerge dev-libs/boost 2.find /usr/lib -iname 'libboost*' 3. Expected Results: /usr/lib/libboost_python.so /usr/lib/libboost_python.a /usr/lib/libboost_signals.so .... Portage 2.0.49-r20 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20031222-r0, 2.6.0) ================================================================= System uname: 2.6.0 i686 AMD Duron(tm) processor Gentoo Base System version 1.4.3.12 distcc 2.11.2 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon -mmmx -m3dnow -fomit-frame-pointer -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon -mmmx -m3dnow -fomit-frame-pointer -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.linux.no http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/myportage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aalib alsa apm arts avi berkdb cdr crypt cups directfb dvd encode esd foomaticdb gdbm gif gphoto2 gpm gstreamer gtk gtk2 imlib java jpeg kde ldap libg++ libwww mad mikmod mmx motif mpeg mysql ncurses oggvorbis opengl oss pam pdflib png postgres ppds python qt quicktime readline sasl scanner sdl slang spell ssl svga tcltk tcpd tetex truetype x86 xml2 xmms xv zlib"
There are two problems: 1) the ebuild looks for libraries to install in ${S}/libs, but that's just source code - the binaries are in ${S}/bin/boost/libs. 2) 8 copies of each library is built, with all different combination of {{static linking, dynamic linking}, {debug, release}, {multithreaded, singlethreaded}}. This is documented in more/getting_started.html in the tarball (not on the site, as far as I can see). You can give Jam (the build system) arguments that selects which of these are built. Only the desired (FSVO) one(s) should be built, renamed and merged.
Hi guys. Karl-Johan: thanks for some suggestions. I've prepared a new cvs snapshot and did a few fixes to the ebuild. I issues the _alpha2 ebuild, now in portage, please test. As for the preparing all the variations, I would rather get it fixed and tested first, then we can move on to improving the ebuild.. Any idea on when the release (1.31) is gonna be out? George
It installs OK, but building programs with it fails. Tests done with http://www.boost.org/libs/regex/example/snippets/regex_split_example_1.cpp and gcc version 3.3.2 20031022 (Gentoo Linux 3.3.2-r3, propolice) show: Compiles OK: $ g++ -o regex.o -c regex_split_example_1.cpp Linking fails: $ g++ -o regex -lboost_regex-gcc-1_31 regex.o regex.o(.text+0x2b0): In function `__tcf_0': : undefined reference to `boost::reg_expression<char, boost::regex_traits<char>, std::allocator<char> >::~reg_expression [in-charge]()' [... 50 lines of link failures, all of symbols that are present (according to "objdump --dynamic-syms | c++filt") in libboost_regex-gcc-1_31.so.1.31.0, later...] collect2: ld returned 1 exit status But if I make a symlink: libboost_regex.so -> libboost_regex-gcc-mt-1_31.so.1.31.0 linking succeeds: $ g++ -o regex -lboost_regex regex.o $ ./regex Enter text to split (or "quit" to exit): quit and produces an executable about which ldd thinks: $ ldd regex | grep boost libboost_regex-gcc-mt-1_31.so.1.31.0 => /usr/lib/libboost_regex-gcc-mt-1_31.so.1.31.0 (0x471eb000)
After reading the GCC manual more carefully, changing the linking order works both with and without the symlink: $ g++ -o regex regex.o -lboost_regex-gcc-1_31 [No errors] $ g++ -o regex regex.o -lboost_regex [No errors]
yea, gcc is sensitive to the order of argumens during linking, even in the same command line. However it would be nice indeed to have the symlinnks created during install. You may test the -r1 now ;). It installs the symlinks that were created during the build. Althought they also have all these long and sometimes cryptic names. It might be usefull to create some other simplified symlinks, but with the many files distributed all over the place I am not sure what kinds of simplified names to use, plus it should definitely be automated.. George
Doesn't work for me - the installed symlinks are broken: libboost_regex-gcc-d-1_31.so -> bin/boost/libs/regex/build/libboost_regex.so/gcc/debug/shared-linkable-true/libboost_regex-gcc-d-1_31.so As for shorter names, I'd first like to have symlinks with version numbers stripped from the library base names and then have the multithreaded release builds as defaults and everything else as special cases, so that we have: libboost_LIB.a -> libboost_LIB-gcc-mt.a libboost_LIB-gcc-mt.a -> libboost_LIB-gcc-mt-1_31.a libboost_LIB.so -> libboost_LIB-gcc-mt.so libboost_LIB-gcc-mt.so -> libboost_LIB-gcc-mt-1_31.so plus symlinks for *.so -> *.so.1.31.0 like we have now. This way, at least nothing will break if you link with just "-lboost_LIB", even if you might lose a small fraction of the speed of the single-threaded libraries. But those who need that can probably figure out how to type "-lboost_LIB-gcc" instead.
Thanks for testing. I masked the -r1 for now. Also I got some feedback via email and I am persuading that person to post his request for links here as well :). I'll now wait for the feedback and will most likely get back to this bug next week. Given no negative feedback on the binaries themselves I am thinking to mark _alpha2 stable (as 1.30 no loger works) and meanwhile work on -r1 on symlinks. George
Could you not use something like what qt does, and simply move the entire src tree into /usr or /usr/lib and set up an env.d file? You then _remove_ all files that you're _certain_ are not needed, to go on a diet. Of course, I could also be talking out of my ass here...
>Could you not use something like what qt does, and simply move the entire src >tree into /usr or /usr/lib and set up an env.d file? Well, we might, but I am afraid in this case this is not gonna be that usefull. Try looking at the source tree ;). Not only yo will have to add a ton of -L options when you will compile your stuff against libboost, but also it is far easier to install only necessary libs that to remove "extra cruft" for there is a lot of the latter. On another note, the modified -r1 that should install appropriate symlinks is upcoming :). George
Ok, the -r1 is done and unmasked (in package.mask). Please test. This revision should install the full set of appropriate symlinks without version and also default symlinks to gcc-mt version.. We might look into modifying what variant is chose with the useflags eventually, but lets first get this package fixed and into stable.. George
Tried the latest/greatest boost-1.31.0_alpha2-r1.ebuild. Everything seems to build and install correctly, including the symlinks. Tried my Boost Threads test program and all works well. Good job!
Release is out and in stable, closing the bug..
