www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2607] New: Please consider building DMD agast and older version of glibc

reply d-bugmail puremagic.com writes:
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.


--
Jan 23 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2607






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.


--
Jan 26 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2607






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.


--
Jan 26 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2607




---
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: -------
Nov 11 2009