#26466: finer control of boost -------------------------------+-------------------------------------------- Reporter: manphiz@… | Owner: adfernandes@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Keywords: haspatch | Port: boost -------------------------------+-------------------------------------------- Comment(by adfernandes@…): Hi, `manphiz` - I've been thinking a lot about this over the past couple of days, and here are my thoughts: * I've looked into it, and allowing static runtime linking on a Mac is really a bad idea unless developers know what they are doing. Shared vs. static c++ runtimes are important for exception-handling propagation over shared-object boundaries. I don't pretend to understand it, but in my tests of Apple's vs MacPorts' gcc variants, `-static-libgcc` and `-shared- libgcc` give different results in terms of linking. I'm not even sure how this affects the `c++` runtime, never mind the `c`-runtime. * Boost is really an infrastructure that a lot of ports depend on (see `port echo depends:boost`). These programs may be single or multithreaded, and may prefer shared or dynamic libraries. * Since MacPorts can't depend on a given variant, I'm inclined to leave all of boost there (single and multithreaded, static and dynamic). Boost doesn't release versions very often, so I'm inclined to leave the port the way it is. It sucks in terms of build times, but that's the way it is with infrastructure libraries. Is the finer control you desire simply a matter of build-times? -- Ticket URL: <https://trac.macports.org/ticket/26466#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS