Dear Waldek,

I'm copying the list here, because John Ries is working on the same compile. I have not made any progress in the last week. I spent some time marvelling at magnitude of the changes made by the GCC maintainers in the GCC generic trees code between GCC 4.3.5 and 4.9.4.

Attempting to compile GPC in GCC-4.3.5 with a GCC 4.9.4 host compiler, I reported:

...

I get 859 duplicate symbol errors like this while compiling gpc1 object:

duplicate symbol _default_binds_local_p_1 in: p/varasm.o libbackend.a(varasm.o)

They are all of the same form: libbackend.a(xxx.o) conflicts with p/xxx.o I remove libbackend.a from the step and get missing symbols.

To which you replied:

That seems to be incompatible behaviour of linker. 'libbackend.a' is a library and objects provided by GPC are supposed to effectively replace corresponding library objects. In other words linker is supposed to take object from command line and ignore corresponding object from 'libbackend.a'. On Linux with GNU linker it works as intended.

The default linker on MacOS is the clang linker. There is no binutils port of "as" or "ld" to MacOS. There's that old CTools "as" and "ld" available. I don't know how to force the build to use the CTools linker.

One possible workaround is to tell linker that libbackend.a is a library replacing 'libbackend.a' by something like '-L. -lbackend'. Another possiblity is to make unconditional modification to backend files and skip GPC versions.

I have spent a few hours looking at the configure and makefile scripts, trying various flags and options, but my experiments don't work, which has served to show me how little I understand. I edit a makefile and it will be re-written, because I edited the wrong file. My greatest achievement was to persuade the entire build to use the CTools "as", only to find that this assembler won't compile the 64-bit code generated by GCC 4+.

...

I remove the duplicating p/xxx.o files and the step works. I re-start the build, and it proceeds farther, until xgcc is compiling fibheap.c, which aborts with; ../../../gcc-4.3.5/libiberty/fibheap.c:258: error: ‘LONG_MIN’ undeclared (first use in this function). In that file there is a line: #define FIBHEAPKEY_MIN LONG_MIN

You asked:

So important question is which compilation works and which fails?

Consulting my notes above, the error occurs when xgcc is building fibheap.c.

Second, LONG_MIN comes from standard header "limits.h". So this looks like typical example of confusion with location of header files.

That would not surprize me. I have 99 copies of limits.h on my hard drive, between various versions of GCC that I have installed, and the SDKs.

Best, Kevan