Have you run a debugger to see _why_ gethostbyname is failing? I see absolutely no reason for a statically linked binary to fail on any system, unless it is using network communication whose protocol has changed or a config file whose format has changed. Are you sure you aren't LD_PRELOADing anything? Jon On Sat, 19 Apr 2003, Peter Astrand wrote: > > I need to produce binaries that can run on at least RedHat Linux 7.3, 8.0 > and 9. The code we are building is a mixture of C and C++. Today, our > build environment looks like this: > > * RedHat 7.3 as base > * GCC 3.2.1, installed in /usr/local > * Binutils 2.13.2.1, installed in /usr/local > > Earlier, we only supported RHL 7.3 and 8. The binaries was statically > linked, to avoid problems with missing libstdc++.so.5 etc. But, if you > build static binaries on RHL 7.3, they won't run on RHL 9, it seems. For > example, all calls to gethostbyname() will make the program segfault. > We've also ran into some minor incompatibility problems (see below). > > So, my general question is: How can I generate binaries that will run on > RHL 7.3, 8 and 9? Which build environment is most suitable. Some people > have suggested that it's better to use the platforms own GCC, but for RHL > 7.3 this means GCC "2.96", which doesn't work for us, since a number of > C++ features are missing. > > To me, the most obvious platform is RHL 7.3, but for the case with > gethostbyname() and static link, RHL 9 seems like a better choice: It > looks like it can generate binaries that works on all required systems. > > > Details / more minor incompatibilites, when building with GCC 3.2.1 on RHL > 7.3: > > * Binaries require libc.so.6(GCC_3.0). This dependency is present on all > of 7.3/8/9, so it isn't really a problem, besides that it would be nice > if the program could work on, for example, RHL 7.1 as well. > > I've found two ways of getting rid of the libc.so.6(GCC_3.0) dependency: > > 1) Linking with libstdc++ dynamically > 2) Linking with the old GCC instead of GCC 3.2.1. > > > * Problem with: "Incorrectly built binary which accesses errno, h_errno or > _res directly. Needs to be fixed" > > As I understand it, it's important that all applications include > errno.h, rather than just assume that errno is an int. But even if my > apps do this, sometimes I get this problem. The problem seems to be that > even libc itself accesses errno directly. (My notes give a link to > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80016, but it gives > me 500 right now.) I've managed to solve this by just moving the "-lc" > options on the linker commandline, but I have no idea why this actually > solves the problem. > > > Are there any documentation on these problems? In the future, we would > like to support all LSB compliant platforms, but since RHL 7.3 only > supports LSB-1.2, and LSB-1.2 uses an old GCC, this seems like not an > option today. > > Comments? > > -- > Peter Åstrand www.thinlinc.com > Cendio Systems www.cendio.se > Teknikringen 3 Phone: +46-13-21 46 00 > 583 30 Linköping > > > > > _______________________________________________ > Redhat-devel-list mailing list > Redhat-devel-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/redhat-devel-list > _______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/redhat-devel-list
