Are we actually going to publicize a logo contest or are we going to be doing it all here? I think it should be the former, and I think we should get most of the logo announcements and commentary off this list so it can return to its regularly scheduled programming. But first I guess someone has to volunteer to manage the thing at least (make up the announcement, settle voting procedure, etc.) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Hello, I would like to report 3 issues with the program_options library, 2 of which seem critical to me: 1) The class boost::program_options::value_semantic is a polymorphic class (has virtual functions), but has a non-virtual destructor. Thus, according to the Standard, Section 5.3.5, Clause 3, calling delete for a pointer to an object of static type value_semantic, where the dynamic type is a derived class, results in undefined behaviour. Not only is value_semantic meant to be used in a standard object-oriented way, but also the program_options library itself uses it in this way, and thus it seems to me, that it is basically impossible to use this library without running into undefined behaviour (which must definitely be avoided). Perhaps the following crash, when using program_options in a trivial way, is already caused by this error. 2) Consider the following program "Error_program_options" #include <boost/program_options.hpp> int main() { boost::program_options::options_description d("Options"); } I compiled it (using g++, version 3.4.3) via
g++ -g Error_program_options.cpp -lboost_program_options-gcc
I got the warning /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_program_options-gcc.so, may conflict with libstdc++.so.6 (see point 3), but this doesn't seem to be of importance here. Running this program causes a segmentation fault:
./a.out Segmentation fault (core dumped)
Examining the core dump shows, that the program crashed inside a member function for a safe-pointer helper class:
gdb a.out core GNU gdb 5.3.92 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... Core was generated by `./a.out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libboost_program_options-gcc-1_32.so.1.32.0...done. Loaded symbols for /usr/local/lib/libboost_program_options-gcc-1_32.so.1.32.0 Reading symbols from /usr/local/lib/libstdc++.so.6...done. Loaded symbols for /usr/local/lib/libstdc++.so.6 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /usr/local/lib/libgcc_s.so.1...done. Loaded symbols for /usr/local/lib/libgcc_s.so.1 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /usr/lib/libstdc++.so.5...done. Loaded symbols for /usr/lib/libstdc++.so.5 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x0804923a in boost::detail::sp_counted_base::release() (this=0x838dffff) at shared_count.hpp:142 142 long new_use_count = --use_count_;
Thus it could be, that the problem reported unter 1) causes the crash here (on the other hand, actually for the above trivial program no object of type value_semantic seems to be created, but unfortunately I don't have the time to investigate this further). 3) I'm using g++ version 3.4.3, and I compiled Boost with this compiler, but to whatever library from Boost I link, I get warning messages like the above; another example
g++ calender.o -lboost_date_time-gcc /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6
What's the problem here?! (Linking in general seems in Boost not so easy, and thus it would be good to have a bit more documentation on this. For example in program_options I couldn't find any hint how to compile it.) Hope someone can shed light on these issues (as I said, for all what I can see, there seems to be a serious problem with program_options). Oliver
You are 'stealing threads' (ask google, in case you don't know that term), just so you know. However... On Saturday 04 December 2004 17:59, Oliver Kullmann wrote:
3) I'm using g++ version 3.4.3, and I compiled Boost with this compiler, but to whatever library from Boost I link, I get warning messages like the above; another example
g++ calender.o -lboost_date_time-gcc
/usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_date_time-gcc. so, may conflict with libstdc++.so.6
I seriously doubt that you used the same compiler. Above warning suggests that you used an older version of the stdlib (and compiler), which can lead to all kinds of subtle problems. Recompile that lib first and try again. About the problem of not having a virtual dtor: it is not necessary. The general rule is to have either a public virtual one or a non-public non-virtual one. No, I did not inspect the code in question, so won't comment on that. Another thing is that when using shared_ptr<>, they still manage to call the right dtor, you can even store objects safely in a shared_ptr<void>! Uli
Ulrich Eckhardt wrote:
You are 'stealing threads' (ask google, in case you don't know that term), just so you know. However...
As long as you're pointing that out, I think it also makes sense to change the subject line so others aren't led astray. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Sat, 4 Dec 2004 16:59:15 +0000, Oliver Kullmann wrote
Hello,
I would like to report 3 issues with the program_options library, 2 of which seem critical to me:
I'll respond to the 3rd issue...
... snip 1st 2 issues...
3) I'm using g++ version 3.4.3, and I compiled Boost with this compiler, but to whatever library from Boost I link, I get warning messages like the above; another example
g++ calender.o -lboost_date_time-gcc /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux- gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6
Looks to me that there is a mismatch in the environment -- you are compiling boost with one version of libstdc++ and then linking against another.
What's the problem here?! (Linking in general seems in Boost not so easy, and thus it would be good to have a bit more documentation on this. For example in program_options I couldn't find any hint how to compile it.)
Hope someone can shed light on these issues (as I said, for all what I can see, there seems to be a serious problem with program_options).
Have you read this? http://www.boost.org/more/getting_started.html#Build_Install Jeff
Hi Jeff,
3) I'm using g++ version 3.4.3, and I compiled Boost with this compiler, but to whatever library from Boost I link, I get warning messages like the above; another example
g++ calender.o -lboost_date_time-gcc /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux- gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6
Looks to me that there is a mismatch in the environment -- you are compiling boost with one version of libstdc++ and then linking against another.
What's the problem here?! (Linking in general seems in Boost not so easy, and thus it would be good to have a bit more documentation on this. For example in program_options I couldn't find any hint how to compile it.)
Hope someone can shed light on these issues (as I said, for all what I can see, there seems to be a serious problem with program_options).
Have you read this?
http://www.boost.org/more/getting_started.html#Build_Install
yes, I read it, but the main question seems to me: What happens if Boost was already installed on the system? Is some form of "uninstall" necessary? (seems not to be the case?!) Could this be the problem here?! To be on the safe side, I've built Boost again, but exactly the same problem: Always the linker warnings, and every program crashes (so it had nothing to do with the program_options library; fortunately it always crashes immediately, so the problem is always visible). Below I've copied the relevant build commands and other information. Thanks for your help! Oliver ---------------------------------------------------------------------------------------- Compiler versions: kullmann@csltok:/usr/local/lib> g++ -v Lese Spezifikationen von /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Konfiguriert mit: /h/21/GemeinsameBasis/GCC/gcc-3.4.3/configure --enable-threads=posix --enable-languages=c,c++,f77,objc,java,ada --enable-shared Thread-Modell: posix gcc-Version 3.4.3 kullmann@csltok:/usr/local/lib> gcc -v Lese Spezifikationen von /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Konfiguriert mit: /h/21/GemeinsameBasis/GCC/gcc-3.4.3/configure --enable-threads=posix --enable-languages=c,c++,f77,objc,java,ada --enable-shared Thread-Modell: posix gcc-Version 3.4.3 ------------------------------- Building Boost: kullmann@csltok:~/C++> tar -xzf boost_1_32_0.tar.gz kullmann@csltok:~/C++/boost_1_32_0/tools/build/jam_src> ./build.sh kullmann@csltok:~/C++/boost_1_32_0> su csltok:/home/kullmann/C++/boost_1_32_0 # tools/build/jam_src/bin.linuxx86/bjam "-sTOOLS=gcc" install ------------------------------- As an example, the date_time link-libraries before the build: kullmann@csltok:/usr/local/lib> ls -l libboost_date_time-gcc* -rw-r--r-- 1 kullmann users 26592 2004-09-17 07:30 libboost_date_time-gcc-1_31.a lrwxrwxrwx 1 kullmann users 37 2004-09-17 07:41 libboost_date_time-gcc-1_31.so -> libboost_date_time-gcc-1_31.so.1.31.0 -rwxr-xr-x 1 kullmann users 19500 2004-09-17 07:30 libboost_date_time-gcc-1_31.so.1.31.0 -rw-r--r-- 2 root root 94536 2004-12-03 02:51 libboost_date_time-gcc-1_32.a lrwxrwxrwx 1 root root 37 2004-12-03 02:51 libboost_date_time-gcc-1_32.so -> libboost_date_time-gcc-1_32.so.1.32.0 -rwxr-xr-x 2 root root 57732 2004-12-03 02:51 libboost_date_time-gcc-1_32.so.1.32.0 -rw-r--r-- 2 root root 94536 2004-12-03 02:51 libboost_date_time-gcc.a -rw-r--r-- 1 kullmann users 198072 2004-09-17 07:30 libboost_date_time-gcc-d-1_31.a lrwxrwxrwx 1 kullmann users 39 2004-09-17 07:41 libboost_date_time-gcc-d-1_31.so -> libboost_date_time-gcc-d-1_31.so.1.31.0 -rwxr-xr-x 1 kullmann users 167296 2004-09-17 07:30 libboost_date_time-gcc-d-1_31.so.1.31.0 -rw-r--r-- 2 root root 437712 2004-12-03 02:51 libboost_date_time-gcc-d-1_32.a lrwxrwxrwx 1 root root 39 2004-12-03 02:51 libboost_date_time-gcc-d-1_32.so -> libboost_date_time-gcc-d-1_32.so.1.32.0 -rwxr-xr-x 2 root root 364163 2004-12-03 02:51 libboost_date_time-gcc-d-1_32.so.1.32.0 -rw-r--r-- 2 root root 437712 2004-12-03 02:51 libboost_date_time-gcc-d.a -rwxr-xr-x 2 root root 364163 2004-12-03 02:51 libboost_date_time-gcc-d.so -rw-r--r-- 1 kullmann users 26592 2004-09-17 07:30 libboost_date_time-gcc-mt-1_31.a lrwxrwxrwx 1 kullmann users 40 2004-09-17 07:41 libboost_date_time-gcc-mt-1_31.so -> libboost_date_time-gcc-mt-1_31.so.1.31.0 -rwxr-xr-x 1 kullmann users 19524 2004-09-17 07:30 libboost_date_time-gcc-mt-1_31.so.1.31.0 -rw-r--r-- 2 root root 94520 2004-12-03 02:51 libboost_date_time-gcc-mt-1_32.a lrwxrwxrwx 1 root root 40 2004-12-03 02:51 libboost_date_time-gcc-mt-1_32.so -> libboost_date_time-gcc-mt-1_32.so.1.32.0 -rwxr-xr-x 2 root root 58004 2004-12-03 02:51 libboost_date_time-gcc-mt-1_32.so.1.32.0 -rw-r--r-- 2 root root 94520 2004-12-03 02:51 libboost_date_time-gcc-mt.a -rw-r--r-- 1 kullmann users 201546 2004-09-17 07:30 libboost_date_time-gcc-mt-d-1_31.a lrwxrwxrwx 1 kullmann users 42 2004-09-17 07:41 libboost_date_time-gcc-mt-d-1_31.so -> libboost_date_time-gcc-mt-d-1_31.so.1.31.0 -rwxr-xr-x 1 kullmann users 169794 2004-09-17 07:30 libboost_date_time-gcc-mt-d-1_31.so.1.31.0 -rw-r--r-- 2 root root 441216 2004-12-03 02:51 libboost_date_time-gcc-mt-d-1_32.a lrwxrwxrwx 1 root root 42 2004-12-03 02:51 libboost_date_time-gcc-mt-d-1_32.so -> libboost_date_time-gcc-mt-d-1_32.so.1.32.0 -rwxr-xr-x 2 root root 370109 2004-12-03 02:51 libboost_date_time-gcc-mt-d-1_32.so.1.32.0 -rw-r--r-- 2 root root 441216 2004-12-03 02:51 libboost_date_time-gcc-mt-d.a -rwxr-xr-x 2 root root 370109 2004-12-03 02:51 libboost_date_time-gcc-mt-d.so -rwxr-xr-x 2 root root 58004 2004-12-03 02:51 libboost_date_time-gcc-mt.so -rwxr-xr-x 2 root root 57732 2004-12-03 02:51 libboost_date_time-gcc.so --------------------------------- And after the build: kullmann@csltok:/usr/local/lib> ls -l libboost_date_time-gcc* -rw-r--r-- 1 kullmann users 26592 2004-09-17 07:30 libboost_date_time-gcc-1_31.a lrwxrwxrwx 1 kullmann users 37 2004-09-17 07:41 libboost_date_time-gcc-1_31.so -> libboost_date_time-gcc-1_31.so.1.31.0 -rwxr-xr-x 1 kullmann users 19500 2004-09-17 07:30 libboost_date_time-gcc-1_31.so.1.31.0 -rw-r--r-- 2 root root 94536 2004-12-06 23:06 libboost_date_time-gcc-1_32.a lrwxrwxrwx 1 root root 37 2004-12-06 23:06 libboost_date_time-gcc-1_32.so -> libboost_date_time-gcc-1_32.so.1.32.0 -rwxr-xr-x 2 root root 57732 2004-12-06 23:06 libboost_date_time-gcc-1_32.so.1.32.0 -rw-r--r-- 2 root root 94536 2004-12-06 23:06 libboost_date_time-gcc.a -rw-r--r-- 1 kullmann users 198072 2004-09-17 07:30 libboost_date_time-gcc-d-1_31.a lrwxrwxrwx 1 kullmann users 39 2004-09-17 07:41 libboost_date_time-gcc-d-1_31.so -> libboost_date_time-gcc-d-1_31.so.1.31.0 -rwxr-xr-x 1 kullmann users 167296 2004-09-17 07:30 libboost_date_time-gcc-d-1_31.so.1.31.0 -rw-r--r-- 2 root root 437712 2004-12-06 23:06 libboost_date_time-gcc-d-1_32.a lrwxrwxrwx 1 root root 39 2004-12-06 23:06 libboost_date_time-gcc-d-1_32.so -> libboost_date_time-gcc-d-1_32.so.1.32.0 -rwxr-xr-x 2 root root 364163 2004-12-06 23:06 libboost_date_time-gcc-d-1_32.so.1.32.0 -rw-r--r-- 2 root root 437712 2004-12-06 23:06 libboost_date_time-gcc-d.a -rwxr-xr-x 2 root root 364163 2004-12-06 23:06 libboost_date_time-gcc-d.so -rw-r--r-- 1 kullmann users 26592 2004-09-17 07:30 libboost_date_time-gcc-mt-1_31.a lrwxrwxrwx 1 kullmann users 40 2004-09-17 07:41 libboost_date_time-gcc-mt-1_31.so -> libboost_date_time-gcc-mt-1_31.so.1.31.0 -rwxr-xr-x 1 kullmann users 19524 2004-09-17 07:30 libboost_date_time-gcc-mt-1_31.so.1.31.0 -rw-r--r-- 2 root root 94520 2004-12-06 23:06 libboost_date_time-gcc-mt-1_32.a lrwxrwxrwx 1 root root 40 2004-12-06 23:06 libboost_date_time-gcc-mt-1_32.so -> libboost_date_time-gcc-mt-1_32.so.1.32.0 -rwxr-xr-x 2 root root 58004 2004-12-06 23:06 libboost_date_time-gcc-mt-1_32.so.1.32.0 -rw-r--r-- 2 root root 94520 2004-12-06 23:06 libboost_date_time-gcc-mt.a -rw-r--r-- 1 kullmann users 201546 2004-09-17 07:30 libboost_date_time-gcc-mt-d-1_31.a lrwxrwxrwx 1 kullmann users 42 2004-09-17 07:41 libboost_date_time-gcc-mt-d-1_31.so -> libboost_date_time-gcc-mt-d-1_31.so.1.31.0 -rwxr-xr-x 1 kullmann users 169794 2004-09-17 07:30 libboost_date_time-gcc-mt-d-1_31.so.1.31.0 -rw-r--r-- 2 root root 441216 2004-12-06 23:06 libboost_date_time-gcc-mt-d-1_32.a lrwxrwxrwx 1 root root 42 2004-12-06 23:06 libboost_date_time-gcc-mt-d-1_32.so -> libboost_date_time-gcc-mt-d-1_32.so.1.32.0 -rwxr-xr-x 2 root root 370109 2004-12-06 23:06 libboost_date_time-gcc-mt-d-1_32.so.1.32.0 -rw-r--r-- 2 root root 441216 2004-12-06 23:06 libboost_date_time-gcc-mt-d.a -rwxr-xr-x 2 root root 370109 2004-12-06 23:06 libboost_date_time-gcc-mt-d.so -rwxr-xr-x 2 root root 58004 2004-12-06 23:06 libboost_date_time-gcc-mt.so -rwxr-xr-x 2 root root 57732 2004-12-06 23:06 libboost_date_time-gcc.so ---------------------------------- The linking warning: g++ -c -o TimeHandling_Applications_DaysDifference.o TimeHandling_Applications_DaysDifference.cpp g++ -o TimeHandling_Applications_DaysDifference TimeHandling_Applications_DaysDifference.o -lboost_date_time-gcc /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6 ----------------------------------- Crash not shown (doesn't seem to be informative).
On Tue, Dec 07, 2004 at 04:56:02PM +0000, Oliver Kullmann wrote:
Hi Jeff,
3) I'm using g++ version 3.4.3, and I compiled Boost with this compiler, but to whatever library from Boost I link, I get warning messages like the above; another example
g++ calender.o -lboost_date_time-gcc /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux- gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6
Looks to me that there is a mismatch in the environment -- you are compiling boost with one version of libstdc++ and then linking against another.
What's the problem here?! (Linking in general seems in Boost not so easy, and thus it would be good to have a bit more documentation on this. For example in program_options I couldn't find any hint how to compile it.)
Hope someone can shed light on these issues (as I said, for all what I can see, there seems to be a serious problem with program_options).
Have you read this?
http://www.boost.org/more/getting_started.html#Build_Install
yes, I read it, but the main question seems to me:
What happens if Boost was already installed on the system? Is some form of "uninstall" necessary? (seems not to be the case?!)
Could this be the problem here?!
To be on the safe side, I've built Boost again, but exactly the same problem: Always the linker warnings, and every program crashes (so it had nothing to do with the program_options library; fortunately it always crashes immediately, so the problem is always visible). Below I've copied the relevant build commands and other information. [snip] The linking warning:
g++ -c -o TimeHandling_Applications_DaysDifference.o TimeHandling_Applications_DaysDifference.cpp g++ -o TimeHandling_Applications_DaysDifference TimeHandling_Applications_DaysDifference.o -lboost_date_time-gcc /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6
The warning clearly says that libboost_date_time-gcc.so requires libstdc++.so.5 - that means you compiled Boost with GCC 3.3 Try running "ldd /usr/local/lib/libboost_date_time-gcc.so" and see which version of libstdc++ it requires (it will say libstdc++.so.5) Did you build Boost before upgrading your compiler? If so, when you re-ran "bjam install" it won't have rebuilt the libraries, it will just have copied the libraries you had already built (with GCC 3.3) into /usr/local/lib. If this is the case, you should delete the compiled binaries and rebuild. jon -- "I have had my results for a long time, but I do not yet know how I am to arrive at them." - Karl Friedrich Gauss
To be on the safe side, I've built Boost again, but exactly the same problem: Always the linker warnings, and every program crashes (so it had nothing to do with the program_options library; fortunately it always crashes immediately, so the problem is always visible). Below I've copied the relevant build commands and other information.
[snip]
The linking warning:
g++ -c -o TimeHandling_Applications_DaysDifference.o TimeHandling_Applications_DaysDifference.cpp g++ -o TimeHandling_Applications_DaysDifference TimeHandling_Applications_DaysDifference.o -lboost_date_time-gcc /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6
The warning clearly says that libboost_date_time-gcc.so requires libstdc++.so.5 - that means you compiled Boost with GCC 3.3
not necessarily --- it only means that when building libboost_date_time-gcc.so, it was *linked* to libstdc++.so.5, and that exactly seems to be the problem (see below).
Try running "ldd /usr/local/lib/libboost_date_time-gcc.so" and see which version of libstdc++ it requires (it will say libstdc++.so.5)
ldd /usr/local/lib/libboost_date_time-gcc.so libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4002e000) libm.so.6 => /lib/i686/libm.so.6 (0x400ee000) libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x40111000) libc.so.6 => /lib/i686/libc.so.6 (0x4011b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
Here you see that it links to libstdc++.so.5 in */usr/lib* !!
Did you build Boost before upgrading your compiler?
no;
If so, when you re-ran "bjam install" it won't have rebuilt the libraries, it will just have copied the libraries you had already built (with GCC 3.3) into /usr/local/lib. If this is the case, you should delete the compiled binaries and rebuild.
I always just delete the old Boost directories. To be safe, again(!) I've build gcc 3.4.3 and, then, after this, Boost, and (of course) nothing changes. The problem is as follows:
ls -l /usr/lib/libstdc++.so lrwxrwxrwx 1 root root 18 2004-02-11 21:37 /usr/lib/libstdc++.so -> libstdc++.so.5.0.5 ls -l /usr/local/lib/libstdc++.so lrwxrwxrwx 1 root root 18 2004-12-09 04:42 /usr/local/lib/libstdc++.so -> libstdc++.so.6.0.3
You see that the gcc installation put libstdc++ into /usr/local/lib, the default place. But Boost linked to /usr/lib/libstdc++.so, the old version. So it seems to me that the Boost build process is erroneous: gcc by default links first to libraries in /usr/local/lib, and then to libraries in /usr/lib (to the best of my knowledge). This is what one should also expect from the Boost build process, however, somehow it overrides the default and links (first) to /usr/lib. I'm using the only version of bjam parameters mentioned in the build instructions: bjam "-sTOOLS=gcc" install Obviously, to temporarily solve the problem, I could hide the lib's in /usr/lib, but there seems to me a problem with the Boost build process which should better be addressed. Oliver
Oliver Kullmann wrote:
Try running "ldd /usr/local/lib/libboost_date_time-gcc.so" and see which version of libstdc++ it requires (it will say libstdc++.so.5)
ldd /usr/local/lib/libboost_date_time-gcc.so libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4002e000) libm.so.6 => /lib/i686/libm.so.6 (0x400ee000) libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x40111000) libc.so.6 => /lib/i686/libc.so.6 (0x4011b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
Here you see that it links to libstdc++.so.5 in */usr/lib* !!
Sure, that's the standard location for libraries.
The problem is as follows:
ls -l /usr/lib/libstdc++.so lrwxrwxrwx 1 root root 18 2004-02-11 21:37 /usr/lib/libstdc++.so -> libstdc++.so.5.0.5 ls -l /usr/local/lib/libstdc++.so lrwxrwxrwx 1 root root 18 2004-12-09 04:42 /usr/local/lib/libstdc++.so -> libstdc++.so.6.0.3
You see that the gcc installation put libstdc++ into /usr/local/lib, the default place. But Boost linked to /usr/lib/libstdc++.so, the old version.
The "/usr/local/lib" is not default place for anything, AFAICT. All system-wide libraries installed in a regular way should go to /usr/lib.
So it seems to me that the Boost build process is erroneous:
gcc by default links first to libraries in /usr/local/lib, and then to libraries in /usr/lib (to the best of my knowledge).
If you're using gcc installed to /usr/local, then maybe you have to that the gcc tooset about this with: bjam -sTOOLS=gcc -sGCC_ROOT_DIRECTORY=/usr/local - Volodya
Vladimir Prus writes:
The "/usr/local/lib" is not default place for anything, AFAICT. All system-wide libraries installed in a regular way should go to /usr/lib.
/usr/local/lib actually _is_ the default place for gcc to put stuff if you just download a tarball, untar and "configure/make/make install", so it's not surprising to see this. It looks like the machine came with a "built in" gcc where everything was in /usr/lib/, then somebody upgraded gcc by just installing overtop from a build from a tarball. I'm curious: has the OP been able to do anything else with equally complicated linking, with this compiler installation? (build a shared object that links against libstdc++, then link against this shared object)
So it seems to me that the Boost build process is erroneous:
gcc by default links first to libraries in /usr/local/lib, and then to libraries in /usr/lib (to the best of my knowledge).
If you're using gcc installed to /usr/local, then maybe you have to that the gcc tooset about this with:
bjam -sTOOLS=gcc -sGCC_ROOT_DIRECTORY=/usr/local
I'm not 100% sure what the GCC_ROOT_DIRECTORY is for, but seems to me that if the gcc in question had been built with --enable-version-specific-runtime-libs specified, the problem could just go away... hope that helps, -t
On Thu, Dec 09, 2004 at 09:54:08AM +0000, Oliver Kullmann wrote:
If so, when you re-ran "bjam install" it won't have rebuilt the libraries, it will just have copied the libraries you had already built (with GCC 3.3) into /usr/local/lib. If this is the case, you should delete the compiled binaries and rebuild.
I always just delete the old Boost directories.
To be safe, again(!) I've build gcc 3.4.3 and, then, after this, Boost, and (of course) nothing changes.
The problem is as follows:
ls -l /usr/lib/libstdc++.so lrwxrwxrwx 1 root root 18 2004-02-11 21:37 /usr/lib/libstdc++.so -> libstdc++.so.5.0.5 ls -l /usr/local/lib/libstdc++.so lrwxrwxrwx 1 root root 18 2004-12-09 04:42 /usr/local/lib/libstdc++.so -> libstdc++.so.6.0.3
You see that the gcc installation put libstdc++ into /usr/local/lib, the default place. But Boost linked to /usr/lib/libstdc++.so, the old version.
So it seems to me that the Boost build process is erroneous:
gcc by default links first to libraries in /usr/local/lib, and then to libraries in /usr/lib (to the best of my knowledge).
This is what one should also expect from the Boost build process, however, somehow it overrides the default and links (first) to /usr/lib.
Why don't you log the calls to the compiler and the linker? (E.g., `bjam -d2 -sTOOLS=gcc install 2>&1 | tee boost-build.log') If the command line shows an explicit `-L /usr/lib' then there's certainly a problem. But I doubt it: I regularly build the Boost libraries (with the default build system) with gcc 3.4.2 installed in a non-default directory. (The system compiler is gcc 3.3.1 with libstdc++.so.5 in /usr/lib.) I never experienced the problems you describe. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
On Thu, Dec 09, 2004 at 09:54:08AM +0000, Oliver Kullmann wrote:
The linking warning:
g++ -c -o TimeHandling_Applications_DaysDifference.o TimeHandling_Applications_DaysDifference.cpp g++ -o TimeHandling_Applications_DaysDifference TimeHandling_Applications_DaysDifference.o -lboost_date_time-gcc /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_date_time-gcc.so, may conflict with libstdc++.so.6
The warning clearly says that libboost_date_time-gcc.so requires libstdc++.so.5 - that means you compiled Boost with GCC 3.3
not necessarily --- it only means that when building libboost_date_time-gcc.so, it was *linked* to libstdc++.so.5, and that exactly seems to be the problem (see below).
True - my mistake, sorry.
Try running "ldd /usr/local/lib/libboost_date_time-gcc.so" and see which version of libstdc++ it requires (it will say libstdc++.so.5)
ldd /usr/local/lib/libboost_date_time-gcc.so libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4002e000) libm.so.6 => /lib/i686/libm.so.6 (0x400ee000) libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x40111000) libc.so.6 => /lib/i686/libc.so.6 (0x4011b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
Here you see that it links to libstdc++.so.5 in */usr/lib* !!
Did you build Boost before upgrading your compiler?
no;
Oh :-)
If so, when you re-ran "bjam install" it won't have rebuilt the libraries, it will just have copied the libraries you had already built (with GCC 3.3) into /usr/local/lib. If this is the case, you should delete the compiled binaries and rebuild.
I always just delete the old Boost directories.
To be safe, again(!) I've build gcc 3.4.3 and, then, after this, Boost, and (of course) nothing changes.
The problem is as follows:
ls -l /usr/lib/libstdc++.so lrwxrwxrwx 1 root root 18 2004-02-11 21:37 /usr/lib/libstdc++.so -> libstdc++.so.5.0.5 ls -l /usr/local/lib/libstdc++.so lrwxrwxrwx 1 root root 18 2004-12-09 04:42 /usr/local/lib/libstdc++.so -> libstdc++.so.6.0.3
You see that the gcc installation put libstdc++ into /usr/local/lib, the default place. But Boost linked to /usr/lib/libstdc++.so, the old version.
So it seems to me that the Boost build process is erroneous:
gcc by default links first to libraries in /usr/local/lib, and then to libraries in /usr/lib (to the best of my knowledge).
You can see what directories are used by adding "-v" to the GCC command line. I think you're right that GCC will look in the directory it was installed to before any others, but any directories added with "-L" will come first. If Boost is passing -L/usr/lib then it would cause your problem - I'd be surprised if it is though.
This is what one should also expect from the Boost build process, however, somehow it overrides the default and links (first) to /usr/lib.
I'm using the only version of bjam parameters mentioned in the build instructions:
bjam "-sTOOLS=gcc" install
I think you could force the right directory to be the first like so: bjam "-sTOOLS=gcc" "-sGXX=g++ -L/usr/local/lib" install That would certainly be easier than hiding all the libs in /usr/lib You might also be able to use -sGCC_STDLIB_DIRECTORY=/usr/local/lib but AFAIK that should be found OK if /usr/local/bin/g++ is being used. Similarly, GCC_ROOT_DIRECTORY should be set correctly.
Obviously, to temporarily solve the problem, I could hide the lib's in /usr/lib, but there seems to me a problem with the Boost build process which should better be addressed.
Yes, if Boost is forcing /usr/lib into the search path that's a problem. But you might have a problem with your GCC installation(s) - I build Boost using experimental versions of GCC installed in ~/gcc/4.x/lib all the time and never get clashes with /usr/lib/libstdc++.* jon -- "We are all in the gutter, but some of us are looking at the stars." - Oscar Wilde
Hi Oliver,
Hello,
I would like to report 3 issues with the program_options library, 2 of which seem critical to me:
First of all, please don't ask questions by replying to unrelated messages, this causes inconvenience for reading.
1) The class boost::program_options::value_semantic is a polymorphic class (has virtual functions), but has a non-virtual destructor.
Excuse me, but here's the code that *I* see: class BOOST_PROGRAM_OPTIONS_DECL value_semantic { public: ............ virtual ~value_semantic() {} }; Now, you must be either looking at a different class, or at a pre-release version of the library (though I think dtor was virtual all the time), or overlooked this definition.
Perhaps the following crash, when using program_options in a trivial way, is already caused by this error.
2) Consider the following program "Error_program_options"
#include <boost/program_options.hpp> int main() { boost::program_options::options_description d("Options"); }
I compiled it (using g++, version 3.4.3) via
g++ -g Error_program_options.cpp -lboost_program_options-gcc
I got the warning
/usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_program_options-gcc.so, may conflict with libstdc++.so.6
(see point 3), but this doesn't seem to be of importance here.
Actually, this means that you've built program_options with g++ 3.3 and compile you program with g++ 3.4. The C++ standard library is not compatible in those versions, so anything can happen, including a crash. This example works for me, when g++ 3.3 is used for everything.
Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x0804923a in boost::detail::sp_counted_base::release() #(this=0x838dffff) at shared_count.hpp:142 142 long new_use_count = --use_count_;
Thus it could be, that the problem reported unter 1) causes the crash here (on the other hand, actually for the above trivial program no object of type value_semantic seems to be created, but unfortunately I don't have the time to investigate this further).
It seems likely that mixing code compiled with 3.3 and 3.4 is the reason for the crash. - Volodya
On Mon, Dec 06, 2004 at 10:29:23AM +0300, Vladimir Prus wrote:
Hi Oliver,
Hello,
I would like to report 3 issues with the program_options library, 2 of which seem critical to me:
First of all, please don't ask questions by replying to unrelated messages, this causes inconvenience for reading.
Hi, don't know what you mean here (I didn't reply to anything?!).
1) The class boost::program_options::value_semantic is a polymorphic class (has virtual functions), but has a non-virtual destructor.
Excuse me, but here's the code that *I* see:
class BOOST_PROGRAM_OPTIONS_DECL value_semantic { public: ............ virtual ~value_semantic() {} };
Now, you must be either looking at a different class, or at a pre-release version of the library (though I think dtor was virtual all the time), or overlooked this definition.
Good to hear; then the documentation is (fortunately) wrong (it actually has problems at many places): boost_1_32_0/doc/html/value_semantic.html class value_semantic { public: // construct/copy/destruct ~value_semantic();
Perhaps the following crash, when using program_options in a trivial way, is already caused by this error.
2) Consider the following program "Error_program_options"
#include <boost/program_options.hpp> int main() { boost::program_options::options_description d("Options"); }
I compiled it (using g++, version 3.4.3) via
g++ -g Error_program_options.cpp -lboost_program_options-gcc
I got the warning
/usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_program_options-gcc.so, may conflict with libstdc++.so.6
(see point 3), but this doesn't seem to be of importance here.
Actually, this means that you've built program_options with g++ 3.3 and compile you program with g++ 3.4. The C++ standard library is not compatible in those versions, so anything can happen, including a crash.
As I said, I did built Boost with g++ 3.4.3; so I think under certain circumstances the build doesn't work. (By the way, the previous version of g++ on that system was 3.4.2.) In any case, it seems that the Boost documentation does not contain at any place a detailed description how to link, and that seems to be something worth adding.
This example works for me, when g++ 3.3 is used for everything.
Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x0804923a in boost::detail::sp_counted_base::release() #(this=0x838dffff) at shared_count.hpp:142 142 long new_use_count = --use_count_;
Thus it could be, that the problem reported unter 1) causes the crash here (on the other hand, actually for the above trivial program no object of type value_semantic seems to be created, but unfortunately I don't have the time to investigate this further).
It seems likely that mixing code compiled with 3.3 and 3.4 is the reason for the crash.
should be; as I said, I did built Boost with 3.4.3, and that we get a crash seems to indicate to me, that at least in the documentation of Boost in general there should be paid more attention to linking issues. Oliver
On Monday 06 December 2004 11:41, Oliver Kullmann wrote:
On Mon, Dec 06, 2004 at 10:29:23AM +0300, Vladimir Prus wrote:
Hi Oliver,
Hello,
I would like to report 3 issues with the program_options library, 2 of which seem critical to me:
First of all, please don't ask questions by replying to unrelated messages, this causes inconvenience for reading.
Hi,
don't know what you mean here (I didn't reply to anything?!).
Your original email includes this header: In-Reply-To: <cosh04$rod$4@sea.gmane.org> which is only inserted when replying to message. If you say you just posted the message, I don't know what do think.
class BOOST_PROGRAM_OPTIONS_DECL value_semantic { public: ............ virtual ~value_semantic() {} };
Now, you must be either looking at a different class, or at a pre-release version of the library (though I think dtor was virtual all the time), or overlooked this definition.
Good to hear; then the documentation is (fortunately) wrong (it actually has problems at many places):
boost_1_32_0/doc/html/value_semantic.html
class value_semantic { public: // construct/copy/destruct ~value_semantic();
I raise the issue on boost-docs mailing list.
/usr/bin/ld: warning: libstdc++.so.5, needed by /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_program_op tions-gcc.so, may conflict with libstdc++.so.6
(see point 3), but this doesn't seem to be of importance here.
Actually, this means that you've built program_options with g++ 3.3 and compile you program with g++ 3.4. The C++ standard library is not compatible in those versions, so anything can happen, including a crash.
As I said, I did built Boost with g++ 3.4.3; so I think under certain circumstances the build doesn't work. (By the way, the previous version of g++ on that system was 3.4.2.)
Can you try removing: /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../libboost_program_options-gcc.so and rebuilding/reinstalling it? I'm pretty sure this warning is caused by compiler version mistmatch (though I never though it's 3.4.2 -> 3.4.3 mismatch that can cause it).
In any case, it seems that the Boost documentation does not contain at any place a detailed description how to link, and that seems to be something worth adding.
I don't think I'm the person to decide on that, but maybe if you can suggest what boost-specific information should be given, it can be done. - Volodya
David Abrahams writes:
Are we actually going to publicize a logo contest or are we going to be doing it all here? I think it should be the former,
Same here.
and I think we should get most of the logo announcements and commentary off this list so it can return to its regularly scheduled programming.
Much as I support the movement, yes, please.
But first I guess someone has to volunteer to manage the thing at least (make up the announcement, settle voting procedure, etc.)
Right. Any volunteers for the role of "Boost logo contest manager"? -- Aleksey Gurtovoy MetaCommunications Engineering
participants (9)
-
Aleksey Gurtovoy -
Christoph Ludwig -
David Abrahams -
Jeff Garland -
Jonathan Wakely -
Oliver Kullmann -
troy d. straszheim -
Ulrich Eckhardt -
Vladimir Prus