boost: support building for a different SDK

[ryandesign (Ryan Carsten Schmidt)]

This report came in via James Gregurich on the mailing list:

I have macosx_deployment_target set to 10.6. The boost port file does not add in the sdkroot as it should. TO fix, modify the last line in the post-configure function to add in the isysroot entry...

fixed line:

write_jam "using darwin : : ${filter}${configure.cxx} -isysroot ${configure.sdkroot} ;"

[adfernandes (Andrew Fernandes)]

r89541

[adfernandes (Andrew Fernandes)]

Adding this patch causes incorrect options to be used by bjam. See #33115.

I didn't notice before because bjam does not throw a nonzero return status if, you know, whole libraries fail to build. Sorry.

This is now a boost bug and should be filed with them. I won't do that since I have filed many bugs before, all of which were ignored.

Reverted in r89555.

Cross-references: #31525 and #33115

[bayoubengal@…]

I invoked the following port command:

sudo port -v build boost +debug

Here is a compiler line from from that build...

"/Applications/Xcode.app/Contents/Developer/usr/bin/llvm-g++-4.2" "-isysroot" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -no-cpp-precomp -gdwarf-2 -fexceptions -arch x86_64 -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -I"." -c -o "bin.v2/libs/filesystem/build/darwin-4.2.1/debug/address-model-64/architecture-x86/link-static/v2/src/v2_operations.o" "libs/filesystem/v2/src/v2_operations.cpp"

which "incorrect options" do you content are being injected by bjam? The patch to add isysroot to the compiler invocation in the config file should not affect what bjam is injecting into the compiler invocations. It just adds an additional compiler option. Please explain why you think adding the isysroot option is going to cause the options listed in #33115 to be added? They certainly aren't added in my quick test.

[bayoubengal@…]

I let the entire build run and save the build log. Then, I searched for the work "unrecognized". There were no instances found. I cannot reproduce your claim that adding isysroot breaks the build.

[adfernandes (Andrew Fernandes)]

Well, I've repeated the experiment twice now: with the only change being in the isysroot setting as per r89555, I get the same behaviour as #33115.

I do not know why your build succeeds but my and that of the submitter for #33115 do not, but I've confirmed that both their and my builds use the correct darwin toolset.

If you google the errors shown in #33115 with regard to boost, you'll see that bjam has quite a history of incorrectly-setting compiler options, unfortunately.

I have tried debugging bjam build-scripts before, and I'm simply not smart enough I guess. To me, bjam remains completely incomprehensible (and for all practical purposes, undocumented), and I do not have the time to try and track this down, unfortunately. Heck, if previous experience is a guide, I wouldn't succeed anyway...

[bayoubengal@…]

Replying to adfernandes@…:

Well, I've repeated the experiment twice now: with the only change being in the isysroot setting as per r89555, I get the same behaviour as #33115.

I do not know why your build succeeds but my and that of the submitter for #33115 do not, but I've confirmed that both their and my builds use the correct darwin toolset.

If you google the errors shown in #33115 with regard to boost, you'll see that bjam has quite a history of incorrectly-setting compiler options, unfortunately.

I have tried debugging bjam build-scripts before, and I'm simply not smart enough I guess. To me, bjam remains completely incomprehensible (and for all practical purposes, undocumented), and I do not have the time to try and track this down, unfortunately. Heck, if previous experience is a guide, I wouldn't succeed anyway...

set up a copy of /opt such that it fails, then zip the directory up and send it to me by some convenient means. I'll troubleshoot it.

[bayoubengal@…]

Are you going to send me a failing /opt with isysroot in the boost port file so that I can see what's wrong with it?

[adfernandes (Andrew Fernandes)]

Uhh...I thought you were joking. No, I'm not going to zip up gigabytes and upload them anywhere.

I have attached a list of my installed ports, including my macports.conf and variants.conf, if those help.

It could even be that the use of the +debug flag resets the compiler flags to what they should be. bjam does things like that.

All I know is that, through my own testing, is that the correct jamfiles get used and (supposedly) the Darwin toolset is used. We're all using Mac OS 10.7.2 and Xcode 4.2.1 with LLVM-GCC-4.2.1.

[bayoubengal@…]

Replying to adfernandes@…:

Uhh...I thought you were joking. No, I'm not going to zip up gigabytes and upload them anywhere.

I have attached a list of my installed ports, including my macports.conf and variants.conf, if those help.

It could even be that the use of the +debug flag resets the compiler flags to what they should be. bjam does things like that.

All I know is that, through my own testing, is that the correct jamfiles get used and (supposedly) the Darwin toolset is used. We're all using Mac OS 10.7.2 and Xcode 4.2.1 with LLVM-GCC-4.2.1.

No. I'm not joking. I have considerable experience digging into the guts of macports and resolving problems. I've gotten boost to compile in macports for 3 different platforms and 5 OS versions. I'll look at your attachments and see if I see anything interesting.

the +debug option can certainly cause additional compiler options to be passed in, but in my test, it didn't pass in the ones you cited. So, it must be something else.

If you want to troubleshoot it yourself, you can do three things...

1) put a "puts" statement right before the line in question in the portfile and dump all the variables involved to the console so you can see what they are.

2) look at the resulting user-config.jam and see if the line in it is exactly as follows. I don't recall for sure, but I think the whitespace is also important.

using darwin : : g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk ;

NOTE: My developer directory is "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/" because I'm using Xcode 4.3. Yours may still be in /Developer.

3) put the do the build in verbose mode and see exactly what data is being passed to the compiler on the command line.

[bayoubengal@…]

Ok. the interesting thing I see is the variant options. +openmpi could affect compiler options for boost. I'd comment out those variants and see if the problem goes away. If it does, then add them back one at a time until it fails. If that happens, then you have narrowed down the problem.

[bayoubengal@…]

I just tested with +openmpi:

sudo port -v -f install  boost  +openmpi

here is a compiler line:

    "/Applications/Xcode.app/Contents/Developer/usr/bin/llvm-g++-4.2" "-isysroot" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk"  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -no-cpp-precomp -gdwarf-2 -fexceptions -arch x86_64 -Winvalid-pch -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED -DNDEBUG -I"bin.v2/libs/math/build/darwin-4.2.1/release/address-model-64/architecture-x86/link-static/../src/tr1" -I"." -I"libs/math/src/tr1" -c -o "bin.v2/libs/math/build/darwin-4.2.1/release/address-model-64/architecture-x86/link-static/assoc_laguerref.o" "libs/math/build/../src/tr1/assoc_laguerref.cpp"

It works as expected and the build successfully completes. The two options specified as unrecognized are not in the build log.

If I try to combine debug and mph, I get a macports error:

$ sudo port -v -f install  boost  +openmpi +debug
Password:
Warning: port definitions are more than two weeks old, consider using selfupdate
Error: boost: Variant openmpi conflicts with debug
Error: Unable to open port: Error evaluating variants

But it appears from the port file that this is the expected behavior. So, I don't think +openmpi is your problem.

[gavinandresen@…]

Count me as another vote in the "I need OSX 10.5 compatibility, and the suggested patch Works For Me" camp.

We're using a tweaked boost Portfile to compile the reference Bitcoin client (Bitcoin-Qt) to maintain compatibility with OSX 10.5 users.

[gavinandresen@…]

Cc Me!

[gavinandresen@…]

Cc Me!

[gavinandresen@…]

Cc Me!

[adfernandes (Andrew Fernandes)]

Okay - I think I tracked this down. Not what I thought; my configure.sdkroot was set but of null length, and this caused awfulness with bjam.

Can someone test the attached portfile patch and tell me if it fixes the isysroot problem? (Note, in the patch, the convoluted way that bjam expects extra compiler options...)

If it works for you I'll commit.

[gavinandresen@…]

Patch applied, works nicely for me. Thanks!

[adfernandes (Andrew Fernandes)]

r100303