#36719: gcc47: static c++ standard library (libstdc++.a) not built ---------------------+------------------------ Reporter: bach@… | Owner: jeremyhu@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: gcc47 | ---------------------+------------------------ Comment (by jeremyhu@…): Replying to [comment:4 bach@…]:
Replying to [comment:3 jeremyhu@…]:
What makes you think you need this?
I'm the author of a scientific command line software (http://sourceforge.net/projects/mira-assembler/) which is a royal pain to get all needed components for (because some are pretty recent and not installed everywhere), be it for compile time or for for run-time: gcc >= 4.6, BOOST >= 1.49, zlib >=1.27, google perftools and a couple of others.
Users are often biologists with minimal computer skills, often without installation / root rights on the corresponding machines which in turn might be old installations >=5 years lacking needed libraries. Being able to provide people with a single binary they can drop even into their home directory without messing with the system (or environment variables like DYLD_*, LD_*) turned out over the years to be the simplest solution with the least hurdles for them and the least amount of hand holding support by me.
Yeah, I can understand that, but it should be just as straight forward to give them a bundle.
Main development and run environments of the software is general Unix (Linux main, but also Solaris) and the build system is autotools + libtools. If there is a **simple** way on Mac to provide the software I am willing to try and adapt the build environment, but prime directive is that it needs to integrate with autotools/libtools and be easy for the user (as described above).
I don't see why that would be a problem here.
[[br]]
Yeah, I thought about providing it, but that will lead to more bugs than it fixes.
What kind of bugs would these be? I am aware of some ABI hickups in the 4.7 line (slist most notably) but would be interested to learn what other problems could arise.
Would switching back to gcc 4.6 help, is a static libstdc++ present there?
The main reason we did this was to unify the libstdc++ offered out of MacPorts to avoid conflicts when users mixed binaries built with different compilers. Previously, if you built an executable with code that was from gcc46 and gcc45, there would be issues as objects crossed between the C++ runtimes of those two compilers. Now, there is one C++ runtime shared by all the gcc4X compilers. It could be problematic if a library statically linked against libstdc++ and the executable using that library linked against a different/incompatible libstdc++. As you're doing this just for your end executable, that should be safe, but I worry about it being misused elsewhere. You can "fix" this issue for yourself by editing the gcc47 Portfile to not delete libstdc++.a in its post-destroot phase. ie change this: {{{ eval file delete [glob ${destroot}${prefix}/lib/*{a,py}] }}} to this: {{{ eval file delete [glob ${destroot}${prefix}/lib/*py] }}} -- Ticket URL: <https://trac.macports.org/ticket/36719#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS