bug #2607 building DMD against and older version of glibc [was: objdump src]

[Spacen Jasset]

dsimcha wrote:
> == Quote from Spacen Jasset (spacenjasset at yahoo.co.uk)'s article
>> Spacen Jasset wrote:
>>> I am trying to build dmd such that it will work on older versions of
>> ...stuff
>> Given that there will be a book out in the fairly near future, and
>> people may therefore want to run dmd on GNU/Linux. Perhaps bug #2607
>> would be useful to fix. That is; ensure that dmd will run on a
>> respectable set of GNU/linux versions easily. (and perhaps this applies
>> to FreeBSD too)
> 
> I'm forced to use Linux caveman edition (kernel 2.6.8 or something) on some of the
> computers I deal with for my research because my sysadmin refuses to upgrade.
> Before DMD came with buildable source this was problematic because I was
> constantly searching for one of the few nodes that DMD would run on.  However, now
> I don't see it as much of a problem, as it takes approximately 2 minutes to just
> compile from source.  Furthermore, I think I asked Walter about this back when it
> was still a problem and he said changing the glibc version would break people with
> a newer version.
Ok. glibc is forward compatible, on purpose. We build stuff for redhat 2 
at our workplace, which works on 5 (and ubuntu and suse) without any 
trouble. Drepper goes into a lot of detail here:
http://people.redhat.com/drepper/dsohowto.pdf

The problem Walter had was First with glibc, which was fixed by building 
on an older platform (there are other ways but this is easiest).

Then Second, with the older libc++ which was missing on the newer 
systems. The latter is fixed by either:

a) static link in only libc++ and libgcc
b) ship libc++ and change the link loader path with the -L options 
(requires a startup stub I think if you don't always use the same 
installation location i.e. /usr/local/dmd

Which is a very similar way you fix missing msvcr71.dll problems on windows.