#35217: boost @1.50.0 Porfile does not pass configure.c{xx}flags to boost build ----------------------------------------+----------------------------------- Reporter: andrew.c.morrow@… | Owner: adfernandes@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Resolution: wontfix | Keywords: Port: boost | ----------------------------------------+----------------------------------- Changes (by adfernandes@…): * status: new => closed * resolution: => wontfix Comment: I agree, this sounds like a great suggestion. Unfortunately, the boost documentation lies... a lot. Disclaimer: I've done a lot of (non-MacPorts) work building `boost` for iOS, and it really is not fun at all. The main problem with adding compiler flags like you show is that it only sometimes works. If you look at the `darwin.jam` file (and if you can manage to read it, since virtually all of it is undocumented, untested, not-working, and so on) you'll see that the build system magically adds and removes compiler flags depending on what it thinks you want to do. It modifies the flags based on compiler, SDK, operating system, version, and so on. As far as I can tell, none of it is really tested except for what is explicitly stated on the boost documentation page. You'll note that as of `boost-1.50.0` you cannot use `apple-clang++-3.1` to build `boost`, even though clang-2.8 and later are technically supported. You know, I've actually looked a lot into this because of #35172. What I wanted to do was build boost with gcc-4.7 and link the gcc-runtime in statically. That would entail adding `-static-gcc` and `-static-c++` flags. However, the `boost` build system won't let you do that. I don't know why. It just has a snarky "man, that's a bad idea, so I won't let you do that" message in the jam file. (I suspect it has to do with [http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead this linux-ism], but do not know.) My feelings are that unless this provides a reasonable benefit to a reasonable subset of users, it risks too much breakage to do this. -- Ticket URL: <https://trac.macports.org/ticket/35217#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS