http://d.puremagic.com/issues/show_bug.cgi?id=2607

           Summary: Please consider building DMD agast and older version of
                    glibc
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: jason@spashett.com


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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2607





------- Comment #1 from braddr@puremagic.com  2009-01-26 03:59 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2607





------- Comment #2 from jason@spashett.com  2009-01-26 04:27 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2607



--- Comment #3 from Jason Spashett <jason@spashett.com> 2009-11-11 06:15:47 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------