dmd 2.098.0: version `GLIBC_2.14' not found (required by linux/bin64/dmd)

kdevel kdevel at
Wed Nov 10 00:11:33 UTC 2021

On Tuesday, 9 November 2021 at 00:22:35 UTC, jfondren wrote:
> On Monday, 8 November 2021 at 23:55:02 UTC, kdevel wrote:
>> In previous versions I used the linux32/dmd with the -m64 
>> switch in order to generate 64-bit code. But this does not 
>> work anymore:
>>    $ linux/bin32/dmd
>> linux/bin32/dmd: /lib/ version `GLIBC_2.28' not 
>> found (required by linux/bin32/dmd)
> dmd version v2.089.0 should work for you,

2.098.0 in 64 Bit works for me as well. I used patchelf to change 
the dynamic loader and the rpath to use a local build of a more 
modern glibc.


>> Is it possible to build the compiler and the tools with more 
>> "backward compatible" glibc version numers like 
>> memcpy at GLIBC_2.2.5 and fcntl at GLIBC_2.2.5? IIRC this is 
>> accomplished by using
>>    asm (".symver memcpy, memcpy at GLIBC_2.2.5");
>>    asm (".symver fcntl, fcntl at GLIBC_2.2.5");
>> in the source code.
> ... I'd hope that the version numbers aren't so meaningless 
> that dmd could get away with just lying about them and not have 
> horrible problems.
> I'd prefer that dmd work out of the box on old Linux systems 
> too, but you're probably past EOL in other big ways as well, 
> there. A stock CentOS6 system comes with a root privilege 
> escalation vuln in sudoedit

I am the only user on my machine and know the root password. In 
environments with multiple non-root-users setuid-programs like 
sudo are usually not executable by untrusted users.

If you take a look at SUSE's products [1] you will find that SUSE 
Linux Enterprise Server 11 long term support ends as late as on 
31 Mar 2022. Its glibc is based on GNU glibc 2.11.3.


More information about the Digitalmars-d-learn mailing list