libstdcxx: static c++ standard library (libstdc++.a) not built

[bach@…]

Hi there,

on a freshly installed OSX 10.8.2, newly installed MacPorts, doing

  sudo port install gcc47

does not automatically build the C++ standard library. I see

/opt/local/lib/libstdc++.6.dylib

but no

/opt/local/lib/libstdc++.a

and this leads to the impossibility to create statically linked binaries with g++.

How does it get built?

Best,

B.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, I thought about providing it, but that will lead to more bugs than it fixes.

What makes you think you need this?

[bach@…]

Replying to 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.

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).

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?

Best,

B.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to bach@…:

Replying to 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.

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]

[ecronin (Eric Cronin)]

Also be aware that if you are planning on using macports to get the static libraries for the other dependencies you listed they must all be compiled with gcc to avoid issues between the clang c++ stdlib and the gcc c++ stdlib. Some ports have +gccXY variants (mostly scientific ones that require a fortran compiler), but most do not. Boost in particular has no gcc variants and only builds with the system compiler. You might be able to get what you need by using configure.compiler everywhere, but it's definitely heading into uncharted territory and you'll need to double check that everyone is respecting it...

[bach@…]

I know, on my last OSX machine I had to compile everything from scratch myself (from gcc4.7 to BOOST and all the other libraries) to be able to produce a fully statically linked binary. And it was a big pain in the back to get right, I suppose I will need to do that again.

The alternative: are there tutorials on the web which show how to produce both statically linked binaries (on Linux et al) as well as OSX bundles (on Mac) with autoconf, automake & libtools? As I said: I am willing to give it a try