Re: Creating GCC/libstdc++ toolchain to create most compatible binaries

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 6 May 2014 22:55, Jonas MÃller wrote:
> Dear GCC gurus,
> I have the following question: In my day to day job, we produce
> scientific software that is frequently used by others. Our programs
> are usually written in C++ and more often that not involve stuff like
> boost and such. One problem we commonly face with users of our
> software (which is always free software) is the involved build
> process, which can be somewhat daunting (boost.m4 and all its
> intricacies, anyone?) and most of our users are not versed in the way
> of deep ./configure hacking and mucking around with all sorts of
> CFLAGS and LDFLAGS and what have you not.

If you give them a good enough configure then they shouldn't need to
hack it or set make variables.

> Hence our desire to provide
> binaries that are most compatible for linux systems out there. To
> achieve this, I ideally have the following build setup in mind:
>
> - Use an ancient x86_64 glibc setup, something like glibc 2.3 should do the job

That's ridiculously ancient, and you miss out on things like
__cxa_atexit that are needed for a conforming C++ implementation.

> - Use the most ancient libstdc++ still yielding a libstdc++.so.6 (i.e.
> libstdc++ from GCC 3.4.0)
> - Use the most advanced GCC which is 4.9.0 currently (without its
> included libstdc++), to gain the most out of modern optimization
> techniques

It will almost certainly find loads of errors in the ancient libstdc++
code, because it was written to be compiled by G++ 3.4.0

> - Use the latest libraries (gmp, boost etc) and link these into the
> final binary statically
>
> Is this practically possible? I've tried using a CentOS 4.9 based
> system and started bootstrapping the toolchain but GCC 4.9 fails with
> --disable-libstdc++-v3 in the last step of comparing the stage2 and
> stage3 object files. Let me say pre-emptively here: I know the tricks
> with -Wl,-rpath,$ORIGIN and schlepping along GCC's provided
> libstdc++.so. In such a case, I might as well just -static-libstdc++.
> I'm really trying to create a binary that does not require any
> dragging along or statically linking to libstdc++.
>
> Are these ideas too far-fetched? Is libstdc++ too intertwined with GCC
> to rip it out from a different version and mix them

Ideally, no, but in practice, yes.

> (the code in
> question is C++98, so I guess the libstdc++ from GCC 3.4.0 should
> suffice)?

Well, if you don't mind all the bugs in that version that have been fixed since!

> I'm grateful any insights on how to produce the most universally
> compatible binaries for end users

If you bundle the Boost libs you need alongside your own code (at a
fixed relative path to your own code) then I would expect it to be
possible to provide a makefile that depends on nothing more than a
working 'g++' on the target system. That sounds easier than your
suggestion above.

Otherwise, just get a selection of different build machines (e.g. one
RHEL4, one ancient Debian stable, whatever else you need) and build a
binary for each, statically linking Boost and depending on the system
libstdc++.so. If someone wants to run on RHEL5 give them the RHEL4
binary, which should work fine with the newer libstdc++.so and libc.so
on their RHEL5 box.