Bug 2607 – Please consider building DMD agast and older version of glibc

DMD users have found that a recent version of glib is required to execute the comiler. For example, DMD will not execute on redhat linux 2 as it requires a newer glibc (Centos 2 does not need a license and is equivleant to redhat 2) By linking with an older glibc forward compatability is obtained. I suggest linking dmd against a version of glibc found in, for example centos 2 (redhat EL 2) which is the oldest version that Red Hat support, and seems a reasonable base requirement at this time.

rhel2.1, using glibc 2.2, was released in may 2002 and has been in emergency fix only mode since may 2005. rhel3, using glibc 2.3, was released oct 2003 and has been in emergency fix only mode since june 2007. rhel4, using glibc 2.3, was released feb 2005 and is in phase 2 (still somewhat supported). rhel5, using glibc 2.5, was released march 2007 and is still fully supported. debian seems to be supporting 2.3, 2.7, 2.8, and 2.9 for it's various stages of development. Ubuntu adds 2.6 in the middle of that list. sles 10 seems to be based on 2.4 I tried to gather data for fedora, but it was proving difficult to search for so I gave up. Someone else feel like digging up the data? For what it's worth, the most recent release of glibc is 2.9 (unless a newer one has come out while I wasn't watching). Based on the above, I'd personally be ok with 2.3 being the earliest supported version. That said, even my oldest personal boxes run 2.7. My oldest at work are rhel3 based, but those are all on the way out the door in favor of rhel5.

Is it a problem that glibc 2.2 is in emergency fix only? That presumably covers security fixes. People can use the latest version on their platforms. DMD will use the version of glibc on the platform its running, which is whatever the user decides to run it on. Perhaps 2.3 would be ok since redhat 2 support ends in 2010 (I think) I am not a big redhat user myself, but I only suggested redhat 2 since it's an "enterprise grade" system that other people may be using.

It can be made to work fairly easily like this. There are other options too. --- linux.mak.orig 2009-11-08 23:07:22.000000000 +0000 +++ linux.mak 2009-11-08 23:30:29.000000000 +0000 @@ -2,6 +2,7 @@ C=backend TK=tk ROOT=root +STATIC_LIBCPP=--static-libgcc -lm -Wl,-Bstatic,-lstdc++,-Bdynamic CC=g++ -m32 @@ -86,7 +87,7 @@ all: dmd dmd: id.o optabgen $(DMD_OBJS) - gcc -m32 -lstdc++ $(COV) $(DMD_OBJS) -o dmd + gcc -m32 $(COV) $(DMD_OBJS) -o dmd $(STATIC_LIBCPP) clean: rm -f $(DMD_OBJS) dmd optab.o id.o impcnvgen idgen id.c id.h \ Which works assuming you compile it on redhat 3 and then it is upward compatible (glibc wise). But objdump and the other tools also need similar treatment, but I can't seem to find their source.

Four year old issue about using an ever older library version.