Spacen Jasset wrote:
> For us Linux DMD users a bug should be raised against dmd so that Walter will hopefully compile against an older glibc on future releases.

Yet when I do that the other half of the linux users have a problem.

Steven Schveighoffer wrote:
> "Spacen Jasset" wrote
>> Steven Schveighoffer wrote:
...chop


>> For us Linux DMD users a bug should be raised against dmd so that Walter will hopefully compile against an older glibc on future releases.
> 
> As long as it doesn't cause weird problems.  I have had weird stuff happen when you are running an older app against a newer lib (specifically, the program exited silently).
> 
Ok, fair enough. I've done it it a few times, and we have not had problems. Perhaps some sort of trial with DMD would be helpful.

> Plus, I think the OP essentially was looking to run programs that DMD compiled, not necessarily running DMD itself.
> 
> -Steve 

Ideally, we (as in someone) will want to do both of these things.

Walter Bright wrote:
> Spacen Jasset wrote:
>> For us Linux DMD users a bug should be raised against dmd so that Walter will hopefully compile against an older glibc on future releases.
> 
> Yet when I do that the other half of the linux users have a problem.

Do you know what problems they had Walter, I think this problem should be able to be ironed out somehow.

I believe that is is ok to statically link with the c++ libraries* and we do this at our workplace, otherwise the target users also have to have the correct c++ libraries installed.

The link flags I use for our builds are like this:

LINK_FLAGS=-Wl,-Bstatic,-lstdc++,-Bdynamic -static-libgcc

and are passed to gcc for the linking phase.

Would it be possible for you to generate a version of DMD built in this way for testing as well as how you do it currently?

If you have already done this and found no way to make it work then perhaps it's not worthwhile, but this really should work on Linux.

* - you don't get the "benefit" of bug fixes via the dynamic library updates.