#33085: boost: support building for a different SDK --------------------------------------+------------------------------------- Reporter: ryandesign@… | Owner: adfernandes@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: | Keywords: haspatch Port: boost | --------------------------------------+------------------------------------- Changes (by adfernandes@…): * status: closed => reopened * resolution: fixed => Comment: 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 -- Ticket URL: <https://trac.macports.org/ticket/33085#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS

#33085: boost: support building for a different SDK --------------------------------------+------------------------------------- Reporter: ryandesign@… | Owner: adfernandes@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: wontfix | Keywords: haspatch Port: boost | --------------------------------------+------------------------------------- Comment(by 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. -- Ticket URL: <https://trac.macports.org/ticket/33085#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS

#33085: boost: support building for a different SDK --------------------------------------+------------------------------------- Reporter: ryandesign@… | Owner: adfernandes@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: wontfix | Keywords: haspatch Port: boost | --------------------------------------+------------------------------------- Comment(by 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... -- Ticket URL: <https://trac.macports.org/ticket/33085#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS

#33085: boost: support building for a different SDK --------------------------------------+------------------------------------- Reporter: ryandesign@… | Owner: adfernandes@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: wontfix | Keywords: haspatch Port: boost | --------------------------------------+------------------------------------- Comment(by 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? -- Ticket URL: <https://trac.macports.org/ticket/33085#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS

#33085: boost: support building for a different SDK --------------------------------------+------------------------------------- Reporter: ryandesign@… | Owner: adfernandes@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: wontfix | Keywords: haspatch Port: boost | --------------------------------------+------------------------------------- Comment(by bayoubengal@…): Replying to [comment:9 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. -- Ticket URL: <https://trac.macports.org/ticket/33085#comment:10> MacPorts <http://www.macports.org/> Ports system for Mac OS

#33085: boost: support building for a different SDK --------------------------------------+------------------------------------- Reporter: ryandesign@… | Owner: adfernandes@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: wontfix | Keywords: haspatch Port: boost | --------------------------------------+------------------------------------- Comment(by 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. -- Ticket URL: <https://trac.macports.org/ticket/33085#comment:12> MacPorts <http://www.macports.org/> Ports system for Mac OS

#33085: boost: support building for a different SDK ---------------------------+--------------------------- Reporter: ryandesign@… | Owner: adfernandes@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: wontfix | Keywords: haspatch Port: boost | ---------------------------+--------------------------- Comment (by adfernandes@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/33085#comment:17> MacPorts <http://www.macports.org/> Ports system for Mac OS

#33085: boost: support building for a different SDK ---------------------------+--------------------------- Reporter: ryandesign@… | Owner: adfernandes@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: | Keywords: haspatch Port: boost | ---------------------------+--------------------------- Changes (by adfernandes@…): * status: closed => reopened * resolution: wontfix => -- Ticket URL: <https://trac.macports.org/ticket/33085#comment:19> MacPorts <http://www.macports.org/> Ports system for Mac OS