boost 1.45 is out

[kyle.tarplee@…]

boost 1.45.0 is now released. It would be awesome to have the boost port updated.

[adfernandes (Andrew Fernandes)]

This will take a while to get updated; they've changed the boost build system yet again, so I'll need to go over it carefully to get it to build.

One major change is now you must use the bjam builder that comes with boost as the boost-bjamport can no longer build boost. Grr.

It might be simpler than I think, but I wouldn't count on it. :-(

[kyle.tarplee@…]

Replying to adfernandes@…:

This will take a while to get updated; they've changed the boost build system yet again, so I'll need to go over it carefully to get it to build.

One major change is now you must use the bjam builder that comes with boost as the boost-bjamport can no longer build boost. Grr.

It might be simpler than I think, but I wouldn't count on it. :-(

Why not just do it the simple way. Just do this:

./bootstrap.sh ./bjam

In other words use the bjam that comes with the boost download.

[adfernandes (Andrew Fernandes)]

Heh. You'd think that would work. It doesn't because that procedure ignores the DESTROOT and does all sorts of other things. Boost has all sorts of bugs in how it finds python, ICU, and MPI... some of which may have been fixed, others not. For example, you can build the python module with a single-threaded boost, you'll just crash...

Basically, the boost build system was designed for people to build and run the library themselves and knows very little about how darwin dynamic linking works. Or at least that used to be the case. It is almost impossible to debug the build system too... and when you ask for help on the boost mailing list, you usually just get an answer that says "you must be doing something wrong".

[kyle.tarplee@…]

Replying to adfernandes@…:

Heh. You'd think that would work. It doesn't because that procedure ignores the DESTROOT and does all sorts of other things. Boost has all sorts of bugs in how it finds python, ICU, and MPI... some of which may have been fixed, others not. For example, you can build the python module with a single-threaded boost, you'll just crash...

Basically, the boost build system was designed for people to build and run the library themselves and knows very little about how darwin dynamic linking works. Or at least that used to be the case. It is almost impossible to debug the build system too... and when you ask for help on the boost mailing list, you usually just get an answer that says "you must be doing something wrong".

I'm sorry.

[kyle.tarplee@…]

with boost 1.44 and debugging in gdb I get the following warning:

warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_boost/work/boost_1_44_0/bin.v2/libs/iostreams/build/darwin-4.2.1/release/threading-multi/zlib.o" - no debug information available for "libs/iostreams/src/zlib.cpp"

To me this means that even with boost 1.44 we don't have it right. The debugging info in the dylib (for iostreams in this case) is incorrect. It points to non-existant files.

[adfernandes (Andrew Fernandes)]

Replying to kyle.tarplee@…:

I'm sorry.

Good heavens - don't apologize. I volunteered for this, and I knew what kind of pain I was in for. :-)

I use boost a lot myself... it's a fantastic library... but I really wish that boost transitioned to cmake or even (blech!) autotools simply because it makes packaging much, much easier. Things then "work as you expect". And... I don't have to learn an arcane build system like jam that - again, in comparison to cmake and autotools - nobody else uses. Point in fact, boost doesn't use boost-jam, because 1.45.0 won't build with the current boost-bjam. You need to use boost's internal bjam. Grr.

All this "custom build stuff" makes me grumpy, so sorry if I came across as if I was mad at you. I just need to get myself a strong alcoholic drink and get the new boost built. :-)

[adfernandes (Andrew Fernandes)]

To me this means that even with boost 1.44 we don't have it right. The debugging info in the dylib (for iostreams in this case) is incorrect. It points to non-existant files.

When you say "we"... are you one of the boost developers?

Also - good catch with the debugging stuff. I was actually thinking of removing the debug option from the MacPorts build simply because I didn't know who (or why) would be debugging boost's internal libraries. That and you get build conflict with python and mpi if you have debugging enabled.

Basically, my plan had been (and kind-of still is) to see if the current debug option works... and if it doesn't, just get rid of it. Anyone who wants a debuggable boost needs to build their own. Again - that might be the grumpiness talking.

(I already wasted an hour trying to figure out why the 1.44.0 Portfile wouldn't build 1.45.0, due to a really, really arcane bjam error. The online docs are all over the place, wrong, old, and inconsistent. I finally found it in an email thread where Vladmir P basically said "just use 'bootstrap.sh' which, while correct, makes the work of packagers like me really difficult. Hence my unreasonable grumpiness - for which I apologize again.)

[adfernandes (Andrew Fernandes)]

Committed in r73885.