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.
