I'm not sure if this is a Boost problem, or a build problem. But, I am unable to compile /usr/doc/boost-1.32.0/html/libs/serialization/example/demo.cpp without linker errors. Here's what happens: stu@storm tmp $ cd /tmp stu@storm tmp $ cp /usr/doc/boost-1.32.0/html/libs/serialization/example/demo.cpp . stu@storm tmp $ g++ -lboost_serialization -o demo demo.cpp /tmp/ccMHsszw.o(.gnu.linkonce.t._ZN5boost7archive6detail21save_non_pointer_typeINS0_13text_oarchiveE12bus_scheduleE4save7invokexERS3_RKS4_+0x1d): In function `boost::archive::detail::save_non_pointer_type<boost::archive::text_oarchive, bus_schedule>::save::invokex(boost::archive::text_oarchive&, bus_schedule const&)': : undefined reference to `boost::archive::detail::basic_oarchive::save_object(void const*, boost::archive::detail::basic_oserializer const&)' /tmp/ccMHsszw.o(.gnu.linkonce.t._ZN5boost13serialization25extended_type_info_typeidIK12bus_scheduleEC1Ev+0x22): [ Repeated for every class member in the library ] collect2: ld returned 1 exit status After this I took apart the library archive and tried compiling it using the object files directly. stu@storm tmp $ cp /usr/lib/libboost_serialization.a . stu@storm tmp $ ar vx libboost_serialization.a x - basic_archive.o x - basic_iarchive.o x - basic_oarchive.o x - basic_serializer_map.o x - basic_text_iprimitive.o x - basic_text_oprimitive.o x - basic_xml_archive.o x - binary_iarchive.o x - binary_oarchive.o x - extended_type_info.o x - extended_type_info_no_rtti.o x - extended_type_info_typeid.o x - polymorphic_iarchive.o x - polymorphic_oarchive.o x - text_iarchive.o x - text_oarchive.o x - void_cast.o x - xml_grammar.o x - xml_iarchive.o x - xml_oarchive.o stu@storm tmp $ g++ -o demo demo.cpp *.o There are a bunch of linker warnings, I assume because ranlib was run on the archive, but it produced a binary that runs and produces the correct output. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r4 i686) ================================================================= System uname: 2.6.10-gentoo-r4 i686 AMD Athlon(TM) MP 1900+ Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r2 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-mp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /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/terminfo /etc/env.d" CXXFLAGS="-march=athlon-mp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig candy ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://mirrors.tds.net/gentoo ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ http://mirror.datapipe.net/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X apache2 apm arts avi berkdb bitmap-fonts bootsplash bzlib cdr crypt curl curlwrappers encode f77 fam flac font-server foomaticdb fortran gdbm gif gpm gtk imagemagick imlib ipv6 jpeg kde libg++ libwww mad mikmod mime mmx motif mpeg ncurses nptl oggvorbis opengl oss pam pdflib perl png postgres procmail python qt quicktime readline rtc sdl slang smime spell sse ssl svga tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts x86 xml2 xmms xv xvid zlib"
could you attach demo.cpp? i would appreciate it Daniel
Created attachment 49083 [details] demo.cpp The file you requested. This file is distributed with the library...
missing you ran the included example was bad on my part i had it in my head it was some file i dont already have since there are known issues with boost serialization i need to find out if this is one of them or not, if not i need to see what in the install is going wrong
I'm getting very similar problems linking against boost while trying to compile monotone (http://www.venge.net/monotone). Prior to the gcc 3.3.5 upgrade that portage did for me the other day I was able to build monotone fine. I have re-emerged boost 1.31.0 having seen a comment somewhere about having everything compiled with 3.3.5 but that didn't seem to help. I don't think that this is related to boost serialization. and here's a few lines from my failed monotone build: g++ -I./lua -I./sqlite -DNDEBUG -DBOOST_DISABLE_THREADS -Wall -O2 -fno-strict-aliasing -o monotone lib3rdparty.a libplatform.a monotone-app_state.o monotone-commands.o monotone-diff_patch.o monotone-lua.o monotone-transforms.o monotone-update.o monotone-work.o monotone-cert.o monotone-database.o monotone-file_io.o monotone-keys.o monotone-manifest.o monotone-packet.o monotone-sanity.o monotone-vocab.o monotone-rcs_file.o monotone-xdelta.o monotone-ui.o monotone-schema_migration.o monotone-constants.o monotone-netsync.o monotone-netcmd.o monotone-merkle_tree.o monotone-basic_io.o monotone-mkstemp.o monotone-lcs.o monotone-rcs_import.o monotone-revision.o monotone-change_set.o monotone-mt_version.o monotone-monotone.o monotone-main.o -lpopt -ldl -lboost_regex -lboost_date_time -lboost_filesystem /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../../i686-pc-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN5boost2io6detail22parse_printf_directiveIcSt11char_traitsIcEN9__gnu_cxx17__normal_iteratorIPKcSsEENS0_16basic_outsstreamIcS4_EEEEbRT1_RKSC_PNS1_11format_itemIT_T0_EERT2_h' referenced in section `.rodata' of monotone-commands.o: defined in discarded section `.gnu.linkonce.t._ZN5boost2io6detail22parse_printf_directiveIcSt11char_traitsIcEN9__gnu_cxx17__normal_iteratorIPKcSsEENS0_16basic_outsstreamIcS4_EEEEbRT1_RKSC_PNS1_11format_itemIT_T0_EERT2_h' of monotone-commands.o note only -lboost_regex -lboost_date_time -lboost_filesystem are used.
thanks for trying to catch me on irc Derek, usually works so let me see if i understand you ok you used 1.32.0 *OK* with gcc-3.3.4 and since you upgraded to 3.3.5 you can *no longer* build things as you could with boost 1.32.0 and gcc-3.3.4? i need to make sure i understand what you meant to say correctly
derek, id like you to be in contact through this bug, added you to CC:
Clarification: I was able to use boost 1.31.0 with gcc 3.3.4 to compile monotone successfully. With boost 1.31.0 and gcc 3.3.5 I can no longer compile (link actually) monotone.
Come across this problem myself. This is with sys-devel/gcc-3.4.3.20050110, sys-libs/libstdc++-v3-3.3.4 and glibc sys-libs/glibc-2.3.4.20041102. Compiling thus: g++ -o demo -g demo.cpp -lboost_serialization produces the (now) usual whinges: /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/bin/ld: `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' referenced in section `.rodata' of /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_serialization.a(basic_iarchive.o): defined in discarded section `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' of /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_serialization.a(basic_iarchive.o) etc. However, noticed that there is a /usr/lib/libboost_serialization-d.a installed too. Compiling thus: g++ -o demo -g demo.cpp -lboost_serialization-d gives NO warnings and the demo appears to run correctly. What gives? What is the "-d" version of the library and is it okay to use it? As an aside, I notice that Fedora Core 3 comes with boost v1.32.0, gcc v3.4.2, libstdc++-v3 v3.4.2 and glibc v2.3.4. Their installation of the boost libraries are MISSING the "-d" variants. However, their installation also compiles the same demo.cpp without any warnings and works too. Any clues anyone?
Linking with the -d libs does not fix the problem (i.e. shut the linker up) for me. As to what the -d libs might be, I'd guess that perhaps they are debugging versions? They are *hugely* larger than their non-d versions though. -rw-r--r-- 1 root root 15292998 Feb 7 23:14 /usr/lib/libboost_serialization-d.a -rw-r--r-- 1 root root 15298088 Feb 7 23:14 /usr/lib/libboost_serialization-mt-d.a -rw-r--r-- 1 root root 984142 Feb 7 23:14 /usr/lib/libboost_serialization-mt.a -rw-r--r-- 1 root root 957334 Feb 7 23:14 /usr/lib/libboost_serialization.a i.e. 15MB verses 1MB for the serialization lib what do they look like on fc3?
-d usually means debug, like -mt usually is multithreaded, apologies that i dont have too much time currently to really tackle this full on im gonna see if i can ask someone why this does not happen with the debug libs
Okay, after fooling around with this for a while I think I know the problem--sort of. I suspect that the .a files for boost--all of boost, not just boost_serialization--are either not being built correctly or ranlib and/or ar is/are not working properly. And since boost_serialization is the only library in the bunch that only creates .a files exclusively, it goes unnoticed when using the other libraries. I'm not sure why they don't build a .so for boost_serialization, they build one for everything else... To test my theory I built /usr/doc/boost-1.32.0/html/libs/signals/example/no_function.cpp (which is example code for boost_signals, and it has both a .so and a .a) everything worked like a charm--it was linked to the .so. I then tried to compile it again using the -static flag, and it blew up with errors similar to the ones boost_serialization gets. Next, I took apart the boost_serialization library archive and I recompiled it into a shared library. After linking against the newly created library, /usr/doc/boost-1.32.0/html/libs/serialization/example/demo.cpp compiled and worked like it should.
Interesting... I'm linking against the following -lboost_regex -lboost_date_time -lboost_filesystem If I compile and link with -g the linker is happy and silent -- all of the ...linkonce... messages go away. Removing either the the boost .a libs or the boost .so libs doesn't seem to change the situation -- the linker is still very noisy. Removing the boost -d libs also doesn't seem to make a difference. The key for me seems to be compiling *my* code with -g. Having done this, it doesn't seem to matter which boost libs I link against or whether if have -g on the g++ link line or not. I wonder whether this is a boost problem *at all* or if it's really gcc/ld problem with c++ code. Note that this problem started for me after I upgraded to gcc 3.3.5. Everything was fine with gcc 3.3.4.
I tried the -g flag with the other static libraries in boost, and it seems to work, but it still doesn't have any effect on boost_serialization (it still dies a terrible death). I've tried just about everything I can think of to compile the demo program--various flags, using different variations of argument order for g++, etc.--and it just won't work. At this point, I'd just be happy if they built a .so file--I can get those to work. I'd do it myself, but Jam is a complete mystery to me...
what version of binutils is everyone using here? sys-devel/binutils: 2.15.90.0.3-r4 anyone with gcc-3.3.5 been able to go back to 3.3.4 and get boost to link ok again?
It seems sys-devel/binutils-2.15.92.0.2-r1 is the culprit. Based on Daniel's comment, I downgraded to gcc-3.3.4, recompiled boost, and it didn't work. Next I downgraded to sys-devel/binutils-2.15.90.0.1.1-r3, recompiled boost, and it did work. Then I upgraded back to gcc-3.3.5, recompiled boost, and it worked. So, something must be wrong with either ranlib and/or ar in sys-devel/binutils-2.15.92.0.2-r1.
binutils 2.15.92.0.2-r1 here... presumably it could also be ld or libbfd that's causing the problem (ar and ranlib aren't even used for .so's are they?)
Derek: Well, I guess it could be libbfd--since it's part of binutils and it's linked to by ar, ranlib, and ld. I never had any problems with the .so files, so I didn't even think of ld as a possibility--I didn't even think to ldd all three until you mentioned libbfd. Try downgrading to sys-devel/binutils-2.15.90.0.1.1-r3 (and recompiling boost), I'd be interested to see if that fixes the problem for you as well.
I've downgraded to sys-devel/binutils-2.15.90.0.1.1-r3 but have not recompiled boost. I simply re-linked my app and everything is fine (no linkonce errors reported). So it seems like the problem is with binutils.
can not confirm this here in a chroot with Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 on gcc-3.3.4 pretty virgin stage3 chroot
g++ -lboost_serialization -o demo demo.cpp does this one work for you Derek? Stuart? doesnt here
No, but this does: g++ -o demo demo.cpp -lboost_serialization For some reason g++ doesn't care where your -l flags are if you link to a shared library, but for static libraries it wants them at the end.
ach, nice :) ok this does work, but going back to previous binutils just to confirm -l last still === no go
stuart: putting -lboost_serialization last works with the .0.1.1-r3, hope this clears it up for you what i meant is i'll have to try this putting it last with newer version i had installed before, since all of those i tested with the way it was initially shown in the bug having -lboost_serialization in front
ok putting the lib last i can link it with .0.3, ill be recompiling boost wth that to give it a final test
ok, final test complete rebuilt with .0.3, and it compiled and linked i simply copied the given example up until Stuart mentioned g++ likes its libs at the end, using that line it does not matter if i use .0.1.1 or .0.3 of binutils if y'all could do me the favor trying that commandline on the binutils you were using before? binutils-2.15.92.0.2-r1 and or other versions? 2.15.90.0.1.1-r3 and 2.5.90.0.3-r4 both work for me
I tried 2.15.90.0.1.1-r3, 2.15.90.0.1.1-r4, 2.15.92.0.2-r1, and 2.15.92.0.2-r4. 2.15.92.0.2-r1 does not work at all. 2.15.90.0.1.1-r3 and 2.15.90.0.1.1-r4 work. 2.15.92.0.2-r4 works, but complains--at least for boost_serialization, the other boost libraries I tested didn't get any complaints at all (I tested boost_filesystem and boost_signals using the example code in /usr/doc/boost-1.32.0/html/libs/...). It griped like it was going to fail with linkonce errors when using boost_serialization and boost_serialization-mt, but produced a working executable in both cases. However, it didn't complain at all using boost_serialization-d and boost_serialization-mt-d. I didn't try the others, I only did the ones from 2.15.90.0.1.1-r3 (the previous stable/unmasked version) to 2.15.92.0.2-r4 that had either x86 or ~x86 in the KEYWORDS.
2.15.94.0.2.2 dont work either (our toolchain guy asked to try this one) :/ let's hope 1.33.0 comes out soon and that they build shared libs too then for serialization
So, I've been searching for further info on the problem we are seeing here, and I found a couple things listed on redhat's binutils and gcc-patches lists that seem to fit what we are encountering. Here are links: http://sources.redhat.com/ml/binutils/2004-08/msg00187.html http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00653.html The second one seems more on target. I'm not sure if the gcc patches that are mentioned in the second one were back-ported to the 3.3.x compiler.
so pretty much we should hope 1.33.0 comes out and has .a + .so for boost::serialization this would fix things and binutils could be fixed at their own pace if you sync you will notice a little cleaned up boost ebuild btw <sidenote> im now working on the infal step allowing the default libnames with -gcc- or the ones we use right now, not simultaneously, but seems from looks of it, people want it either one way or the other, so this fix should make everyone happy </sidenote>
well 1.33.0 is still a few months away after all, im trying to see if our problem rings a bell with anyone on the boost-user list, better yet building a shared version of all libs would be prefered as we dont seem to have issues with those ill keep you posted on this
apparently in current serialization builds shared libs, time permitting i will see to port this 1.32.0-r1 will be out there in 35 minutes, give it a whirl, all you get is cleanups and link to libname-gcc libname-gcc-d and so on, but since not all packages can just agree on one way, this should make it more solid yes id like you to be my first testers if everyone is happy 1.32.0 dies in favor of -r1 to only have one ~arch version i greatly appreciate all your feedback thus far
please test with gcc-3.4.3.20050110-r2 the problem should be gone now feedback appreciated
the bug is hereby closed, as gcc is fixed for this issue
