From: Arnd Bergmann > Sent: 03 May 2021 10:25 ... > One scenario that I've seen previously is where user space and > kernel are built together as a source based distribution (OE, buildroot, > openwrt, ...), and the compiler is picked to match the original sources > of the user space because that is best tested, but the same compiler > then gets used to build the kernel as well because that is the default > in the build environment. If you are building programs for release to customers who might be running then on old distributions then you need a system with the original userspace headers and almost certainly a similar vintage compiler. Never mind RHEL7 we have customers running RHEL6. (We've managed to get everyone off RHEL5.) So the build machine is running a 10+ year old distro. I did try to build on a newer system (only 5 years old) but the complete fubar of memcpy() makes it impossible to compile C programs that will run on an older libc. And don't even mention C++, the 'character traits' is just plain horrid - enough to make me want to remove every reference to CString from the small amount of C++ we have. To quote our makefile: # C++ is fighting back. # I'd like to be able to compile on a 'new' system and still be able to run # the binaries on RHEL 6 (2.6.32 kernel 2011 era libraries). # But even linking libstdc++ static still leaves # an undefined C++ symbol that the dynamic loader barfs on. # The static libstdc++ also references memcpy@GLIBC_2.14 - but that can be # 'solved' by adding an extra .so that defines the symbol (and calls memmove()). # I've also tried pulling a single .o out of libstc++.a. This might work if # the .o is small and self contained. # # For now we statically link libstc++ and continue to build on an old system. C++LDLIBS := -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic It would be nice to be able to build current kernels (for local use) on the 'new' system - but gcc is already too old. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
