Hi,

I have a problem with the dmd git repository. I cannot compile de compiler for versions newer than v2.78.2.
I can build every version up until v2.78.2. When I try to build v2.78.3 I get following error message:

CC="c++" dmd -lib -of../generated/linux/release/64/lexer.a -m64 -J../generated/linux/release/64 -L-lstdc++ -version=MARS -fPIC -w -de dmd/console.d dmd/entity.d dmd/errors.d dmd/globals.d dmd/id.d dmd/identifier.d dmd/lexer.d dmd/tokens.d dmd/utf.d dmd/root/array.d dmd/root/ctfloat.d dmd/root/file.d dmd/root/filename.d dmd/root/outbuffer.d dmd/root/port.d dmd/root/rmem.d dmd/root/rootobject.d dmd/root/stringtable.d dmd/root/hash.d
dmd/entity.d(2387): Error: undefined identifier __equals in module object
make[1]: *** [../generated/linux/release/64/lexer.a] Error 1
rm optabgen.out
make[1]: Leaving directory `/ec/dev/server/euramis/u000/schlupa/D/dmd/src'
make: *** [all] Error 2
error: make failed

Does anyone have an idea what can be wrong? Is something missing somewhere?


PS: the machine this is built on is an old Linux RHEL 5 which config is stuck to what it was when it initially came out. I don't have sudo or root access on it and all tools and programs I need have to be built from source, either from packets or git repos. Installing ready made binaries does not work in general.
I know, it sucks but I cannot change the policies of our IT environment.

Well, what you need to do is bootstrapping as DMD is now written fully in D.

tl;dr: you need to set HOST_DMD after you build 2.078 for all future builds. However, as this is a very old release, chances that things don't work are pretty high.

You could also give the dmd-cxx branch a go. IIRC it doesn't pass the full DMD testsuite, but it might just be enough to build a newer DMD compiler.

Also, LDC and GDC have a better maintained C++ branch (LTS for LDC and e.g. official GCC 9.1 for GDC) which very likely might work better for you.

To build current DMD master you will need a dmd compiler with a frontend of 2.076 or higher (>= GDC 8), so it might require multiple hops to build the latest, greatest DMD from scratch.

On 15 May 2019 09:50:42 Patrick Schluter via Dlang-internal <dlang-internal@puremagic.com> wrote:

> Hi,
>
> I have a problem with the dmd git repository. I cannot compile de
> compiler for versions newer than v2.78.2.
> I can build every version up until v2.78.2. When I try to build
> v2.78.3 I get following error message:
>
> CC="c++" dmd -lib -of../generated/linux/release/64/lexer.a -m64
> -J../generated/linux/release/64 -L-lstdc++ -version=MARS -fPIC -w
> -de dmd/console.d dmd/entity.d dmd/errors.d dmd/globals.d
> dmd/id.d dmd/identifier.d dmd/lexer.d dmd/tokens.d dmd/utf.d
> dmd/root/array.d dmd/root/ctfloat.d dmd/root/file.d
> dmd/root/filename.d dmd/root/outbuffer.d dmd/root/port.d
> dmd/root/rmem.d dmd/root/rootobject.d dmd/root/stringtable.d
> dmd/root/hash.d
> dmd/entity.d(2387): Error: undefined identifier __equals in
> module object
> make[1]: *** [../generated/linux/release/64/lexer.a] Error 1
> rm optabgen.out
> make[1]: Leaving directory
> `/ec/dev/server/euramis/u000/schlupa/D/dmd/src'
> make: *** [all] Error 2
> error: make failed
>
> Does anyone have an idea what can be wrong? Is something missing
> somewhere?
>
>
> PS: the machine this is built on is an old Linux RHEL 5 which
> config is stuck to what it was when it initially came out. I
> don't have sudo or root access on it and all tools and programs I
> need have to be built from source, either from packets or git
> repos. Installing ready made binaries does not work in general.
> I know, it sucks but I cannot change the policies of our IT
> environment.

On 2019-05-15 09:46, Patrick Schluter wrote:
> Hi,
> 
> I have a problem with the dmd git repository. I cannot compile de compiler for versions newer than v2.78.2.
> I can build every version up until v2.78.2. When I try to build v2.78.3 I get following error message:
> 
> CC="c++" dmd -lib -of../generated/linux/release/64/lexer.a -m64 -J../generated/linux/release/64 -L-lstdc++ -version=MARS -fPIC -w -de dmd/console.d dmd/entity.d dmd/errors.d dmd/globals.d dmd/id.d dmd/identifier.d dmd/lexer.d dmd/tokens.d dmd/utf.d dmd/root/array.d dmd/root/ctfloat.d dmd/root/file.d dmd/root/filename.d dmd/root/outbuffer.d dmd/root/port.d dmd/root/rmem.d dmd/root/rootobject.d dmd/root/stringtable.d dmd/root/hash.d
> dmd/entity.d(2387): Error: undefined identifier __equals in module object
> make[1]: *** [../generated/linux/release/64/lexer.a] Error 1
> rm optabgen.out
> make[1]: Leaving directory `/ec/dev/server/euramis/u000/schlupa/D/dmd/src'
> make: *** [all] Error 2
> error: make failed
> 
> Does anyone have an idea what can be wrong? Is something missing somewhere?

As far as I know `__equals` is a function that the compiler lowers comparisons to. If I would guess I would say that your host compiler and its druntime doesn't match.

-- 
/Jacob Carlborg

On Wednesday, 15 May 2019 at 08:08:21 UTC, Sebastian Wilzbach wrote:
> Well, what you need to do is bootstrapping as DMD is now written fully in D.
>
> tl;dr: you need to set HOST_DMD after you build 2.078 for all future builds. However, as this is a very old release, chances that things don't work are pretty high.
>
> You could also give the dmd-cxx branch a go. IIRC it doesn't pass the full DMD testsuite, but it might just be enough to build a newer DMD compiler.
>
> Also, LDC and GDC have a better maintained C++ branch (LTS for LDC and e.g. official GCC 9.1 for GDC) which very likely might work better for you.
>
> To build current DMD master you will need a dmd compiler with a frontend of 2.076 or higher (>= GDC 8), so it might require multiple hops to build the latest, greatest DMD from scratch.
>
> On 15 May 2019 09:50:42 Patrick Schluter via Dlang-internal <dlang-internal@puremagic.com> wrote:
>
>> Hi,
>>
>> I have a problem with the dmd git repository. I cannot compile de
>> compiler for versions newer than v2.78.2.
>> I can build every version up until v2.78.2. When I try to build
>> v2.78.3 I get following error message:
>>
>> CC="c++" dmd -lib -of../generated/linux/release/64/lexer.a -m64
>> -J../generated/linux/release/64 -L-lstdc++ -version=MARS -fPIC -w
>> -de dmd/console.d dmd/entity.d dmd/errors.d dmd/globals.d
>> dmd/id.d dmd/identifier.d dmd/lexer.d dmd/tokens.d dmd/utf.d
>> dmd/root/array.d dmd/root/ctfloat.d dmd/root/file.d
>> dmd/root/filename.d dmd/root/outbuffer.d dmd/root/port.d
>> dmd/root/rmem.d dmd/root/rootobject.d dmd/root/stringtable.d
>> dmd/root/hash.d
>> dmd/entity.d(2387): Error: undefined identifier __equals in
>> module object
>> make[1]: *** [../generated/linux/release/64/lexer.a] Error 1
>> rm optabgen.out
>> make[1]: Leaving directory
>> `/ec/dev/server/euramis/u000/schlupa/D/dmd/src'
>> make: *** [all] Error 2
>> error: make failed
>>
>> Does anyone have an idea what can be wrong? Is something missing
>> somewhere?
>>
>>
>> PS: the machine this is built on is an old Linux RHEL 5 which
>> config is stuck to what it was when it initially came out. I
>> don't have sudo or root access on it and all tools and programs I
>> need have to be built from source, either from packets or git
>> repos. Installing ready made binaries does not work in general.
>> I know, it sucks but I cannot change the policies of our IT
>> environment.

Thank you.
I managed to get it to compile by starting from 0. I re-downloaded everything in a new directory and used the BOOTSTRAP=1 option and it managed to work. Apprently my proxy setting is ok now as that didn't work last time I had tried several months ago. So the binary dmd downloaded managed to compile everything as it should and all worked well now.
What I will test in anycase when I have time, is if I can reproduce my issue because I think it is somehow interesting.
You see, the downloaded dmd when bootstrapping is 2.79.1 which is a version ulterior to the one I was not able to build. What I think is that you can build dmd with its predecessor up until version 2.78.2.
Any version after that, even 2.78.3, fails to be built with an older version, and as Carl said below, it is probably not a dmd issue but a druntime problem.

In practice, I don't think it is problematic per se, as in most cases binary distributions and the BOOTSTRAPPING works as intended, but it is a little issue that can be annoying in cases of extreme no binary download policies like we have in our IT infrastructure.

As said, I will check that later.