#29394: in boost 1.46.1 program_options lib is unusable in macports --------------------------------------------------+------------------------- Reporter: christophe.prudhomme@… | Owner: adfernandes@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: boost1.46 program_options | Port: boost --------------------------------------------------+------------------------- Changes (by ryandesign@…): * owner: macports-tickets@… => adfernandes@… Old description:

the following simple program using boost.program_options crashes with the boost macports

#include <iostream>

#include <boost/program_options.hpp> namespace po = boost::program_options; int main(int ac, char** av) { using namespace std; //locale::global(locale("")); // Declare the supported options. po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("compression", po::value<int>(), "set compression level") ;

po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm);

if (vm.count("help")) { cout << desc << "\n"; return 1; }

if (vm.count("compression")) { cout << "Compression level was set to " << vm["compression"].as<int>() << ".\n"; } else { cout << "Compression level was not set.\n"; } }

the problem lies in printing the options_description structure

(gdb) r --help Starting program: /private/tmp/t --help Allowed options: t(40384) malloc: *** error for object 0x7fff70a22500: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted. 0x00007fff88cab5d6 in __kill () (gdb) bt #0 0x00007fff88cab5d6 in __kill () #1 0x00007fff88d4bcd6 in abort () #2 0x00007fff88c636b5 in free () #3 0x00000001001299d0 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow () #4 0x000000010012e13c in std::basic_streambuf<char, std::char_traits<char> >::xsputn () #5 0x00007fff84fcdae4 in std::__ostream_write<char, std::char_traits<char> > () #6 0x00007fff84fcbb98 in std::__ostream_insert<char, std::char_traits<char> > () #7 0x0000000100063b3d in boost::program_options::options_description::print () #8 0x00000001000640b7 in boost::program_options::operator<< () #9 0x00000001000016cf in main ()

New description: the following simple program using boost.program_options crashes with the boost macports {{{ #include <iostream> #include <boost/program_options.hpp> namespace po = boost::program_options; int main(int ac, char** av) { using namespace std; //locale::global(locale("")); // Declare the supported options. po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("compression", po::value<int>(), "set compression level") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm); if (vm.count("help")) { cout << desc << "\n"; return 1; } if (vm.count("compression")) { cout << "Compression level was set to " << vm["compression"].as<int>() << ".\n"; } else { cout << "Compression level was not set.\n"; } } }}} the problem lies in printing the options_description structure {{{ (gdb) r --help Starting program: /private/tmp/t --help Allowed options: t(40384) malloc: *** error for object 0x7fff70a22500: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT, Aborted. 0x00007fff88cab5d6 in __kill () (gdb) bt #0 0x00007fff88cab5d6 in __kill () #1 0x00007fff88d4bcd6 in abort () #2 0x00007fff88c636b5 in free () #3 0x00000001001299d0 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow () #4 0x000000010012e13c in std::basic_streambuf<char, std::char_traits<char> >::xsputn () #5 0x00007fff84fcdae4 in std::__ostream_write<char, std::char_traits<char> > () #6 0x00007fff84fcbb98 in std::__ostream_insert<char, std::char_traits<char> > () #7 0x0000000100063b3d in boost::program_options::options_description::print () #8 0x00000001000640b7 in boost::program_options::operator<< () #9 0x00000001000016cf in main () }}} -- -- Ticket URL: <https://trac.macports.org/ticket/29394#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS

#29394: in boost 1.46.1 program_options lib is unusable in macports --------------------------------------------------+------------------------- Reporter: christophe.prudhomme@… | Owner: adfernandes@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: boost1.46 program_options | Port: boost --------------------------------------------------+------------------------- Comment(by christophe.prudhomme@…): it seems that it is related to the compiler If I force using /usr/bin/g++ then ./t --help is fine If I use /opt/local/bin/g++ (g++-4.5 in fact) then I have the problem mentioned in this bug report If I use g++-mp-4.4 same issue Unfortunately I have to use g++-4.5 (or g++-4.4) for my own software because g++-4.2 does not support some of the std c++0x features I am using the latest version of snow leopard

hwprefs os_type Mac OS X 10.6.7 (10J869)

boost 1.46 is compiled with /usr/bin/g++ -- Ticket URL: <https://trac.macports.org/ticket/29394#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS

#29394: in boost 1.46.1 program_options lib is unusable in macports --------------------------------------------------+------------------------- Reporter: christophe.prudhomme@… | Owner: adfernandes@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: boost1.46 program_options | Port: boost --------------------------------------------------+------------------------- Comment(by adfernandes@…): Just tried it with `g++-mp-4.5` and had no problem. Your test-case compiles and runs fine for me. I do not have the MacPorts 4.3 or 4.4 compilers on my system, so cannot test them. Are you sure you're linking the dylib for boost? I've seen problems like this (mixing gcc versions) when dylibs (or so files on LInux) are not compiled properly. Exception-handling frames and stuff like that in particular gets messed up. Alternatively, try force-linking the static boost library. Do that as follows: {{{ g++ -I /opt/local/include /opt/local/lib/libboost_program_options.a t.cpp -o t }}} and do '''not''' add any `-L` or `-l` options, otherwise the dylib will silently be used! Verify that the static lib is being used by `otool -L t` and ensure that there are no links to the boost dylib. (Both static and dynamic linking work for me, with both the system and macports 4.5 compiler.) You can also try recompiling boost and seeing if the problem goes away. Also... `gcc45` was just updated, so maybe re-install it, too... (after a `sudo port update`, of course!) Does any of this help? -- Ticket URL: <https://trac.macports.org/ticket/29394#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS

#29394: in boost 1.46.1 program_options lib is unusable in macports --------------------------------------------------+------------------------- Reporter: christophe.prudhomme@… | Owner: adfernandes@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: boost1.46 program_options | Port: boost --------------------------------------------------+------------------------- Comment(by christophe.prudhomme@…): Interestingly here is something else: * with static lib it crashes whatever I do ( no arguments, --help, --compression=1...) the backtrace is the one in the previous message * with dylib it crashes only when I pass --help In the last case The problem is when the options_description data structure is getting passed std::cout here is the backtrace in that case {{{ (gdb) bt #0 0x00007fff88cab5d6 in __kill () #1 0x00007fff88d4bcd6 in abort () #2 0x00007fff88c636b5 in free () #3 0x0000000100114a83 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow () #4 0x00000001001191fc in std::basic_streambuf<char, std::char_traits<char> >::xsputn () #5 0x00007fff84fcdae4 in std::__ostream_write<char, std::char_traits<char> > () #6 0x00007fff84fcbb98 in std::__ostream_insert<char, std::char_traits<char> > () #7 0x000000010004eb3d in boost::program_options::options_description::print () #8 0x000000010004f0b7 in boost::program_options::operator<< () #9 0x0000000100001680 in main () }}} -- Ticket URL: <https://trac.macports.org/ticket/29394#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS

#29394: in boost 1.46.1 program_options lib is unusable in macports --------------------------------------------------+------------------------- Reporter: christophe.prudhomme@… | Owner: adfernandes@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: boost1.46 program_options | Port: boost --------------------------------------------------+------------------------- Comment(by christophe.prudhomme@…): Vladimir thanks for taking a look at this boost 1.46.1 is compiled with g++-4.2 installed on MacOsX while I compiled my codes with g++-4.5 (or 4.4) could it be some kind of incompatibility between 4.2 (boost program_options lib is compiled with that) and 4.5 (the executable is compiled with that) ? know also that if the code is compiled with gcc 4.2 then there is no crash at all. I tried what you suggest, -static didn't work though as crt0.o is missing. The .ii file is all right -- Ticket URL: <https://trac.macports.org/ticket/29394#comment:10> MacPorts <http://www.macports.org/> Ports system for Mac OS

#29394: in boost 1.46.1 program_options lib is unusable in macports --------------------------------------------------+------------------------- Reporter: christophe.prudhomme@… | Owner: adfernandes@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: boost1.46 program_options | Port: boost --------------------------------------------------+------------------------- Comment(by adfernandes@…): Given your description, I'd say that there is a compiler incompatibility somewhere, most likely due to optimization. Could be a bug - maybe or maybe not. I have hit hard-to-diagnose problems like this when mixing gcc versions before. That was my primary argument for making different compiler variants of the `pymol` port. If you absolutely need gcc-4.5, I would recommend that you try to install and build a local copy of boost using the gcc-4.5 compiler. If you follow the boost website directions it shouldn't be too difficult to specify a custom compiler in the jamfile... but beyond that, I think that this bug is out of scope, especially since I cannot reproduce it. -- Ticket URL: <https://trac.macports.org/ticket/29394#comment:12> MacPorts <http://www.macports.org/> Ports system for Mac OS