Patched the lexer to not re-define RETURN.

[cxtal]

Hi!

The gcc-2.95.3 sources do not compile under gcc-4.4, the error given is the following:

In file included from m68k-amigaos-toolchain/sources/gcc-2.95.3/gcc/c-lex.c:31: m68k-amigaos-toolchain/sources/gcc-2.95.3/gcc/c-parse.h:64:error: redeclaration of enumerator 'RETURN' m68k-amigaos-toolchain/sources/gcc-2.95.3/gcc/rtl.def:503: note: previous definition of 'RETURN' was here

and stems from the fact that "RETURN" is defined twice from the files included by "c-lex.c":

• in "c-parse.h"
• from "rtl.h" and thereby "rtl.def"

which both contain a definition for "RETURN".

"c-lex.c" does not need "rtl.h" included (in fact, you can remove "rtl.h" entirely), however, to maintain the original source, I have created a patch that avoids the double-definition by inclusion of "rtl.h":

The patch is located at patches/gcc-2.95.3/gcc/c-lex.c.diff and refuses to include "rtl.h" in case it has already been defined by "c-parse.h":

ifndef RETURN

include "rtl.h"

endif

If useful, please commit. Thanks.

[cahirwpz]

Hi!

A female github'er tinkering with my toys? I did not expect that! You're welcome, of course :-)

Has the error been triggered by exactly following instructions from README file? If you dump build script output to log file - can you tell that GNU flex was build correctly? How come you build the toolchain with so outdated gcc ?

Note that I build GNU flex 2.5.4 before GCC compilation to shadow system's default flex. That is done specifically to avoid problems with newer and incompatible lexer versions.

While you've found a fix / workaround, I cannot yet tell that the root of problem lies actually in c-lex.c file. Perhaps that's an overlooked issue with compilation environment. Let's investigate that first.

Kind regards Krystian Bacławski

[cxtal]

Dear Krystian,

Yes. I was following the README file exactly and that is why I used Debian squeeze i686 to build it because it contains older tools (see below). I also saw that you specifically mentioned 32-bit versions of some tools, so I went for Debian i686 instead of AMD64.

There were other problems, for example, the compilation tools use the system bison which on squeeze is already at 2.4. This triggers some errors because apparently the new bison at 2.4 does not allow mid-rules and they have to be redefined:

http://compgroups.net/comp.compilers/bison-c-parse.y-1115.19-20-for-the-midrule-at/1986417

However, I downloaded bison 2.3 and recompiled from source, installed and the compilation went onward up to the mentioned error. I avoided that error with that patch - although, apparently, rtl.h can be excluded entirely without problem.

The flex in debian squeeze is at 2.5.35.

Kind regards, Eva

[cahirwpz]

Ooops. I think I mixed up some facts. Build script compiles several tools - including GNU bison 1.35, but not GNU flex. I've changed that. Now flex 2.5.4 is built as well.

The idea is to prepare hermetic compilation environment - i.e. if we use tools provided by a distribution, we don't know if they are compatible. So... let's replace them with version we know to work well. Build process should never ever pick up bison and flex from distro; if it does, weird things may happen.

Please try to run build from scratch with most recent version of repository.

Kind regards, Krystian

[cxtal]

Dear Krystian,

Thank you for the update! I noticed what you were doing but for some reason the system bison is picked-up. So, I made some runs to give you some feedback:

Running on a recent Debian stable (Wheezy, not bleeding-edge) which is amd64 (but can, of course, create 32-bit binaries) and has GCC 4.7 does not work at all:

configure:4618: /usr/bin/gcc -std=gnu89 -m32 -V >&5 gcc: error: unrecognized command line option '-V' gcc: fatal error: no input files compilation terminated.

configure:4618: /usr/bin/gcc -std=gnu89 -m32 -qversion >&5 gcc: error: unrecognized command line option '-qversion' gcc: fatal error: no input files compilation terminated.

Next, I switched to Debian Squeeze i686 with GCC version 4.4. It is a virgin system - right now, it has just your toolkit on it and just the base system installed (VM). The problem is that the toolkit is somehow not picking up your bison and (I guess your flex?) and still uses the system tools. If I uninstall my bison from the system entirely, the compilation halts at:

/bin/sh /home/amiga/toolchain/m68k-amigaos-toolchain/sources/binutils-2.9.1/gas/../ylwrap "" /home/amiga/toolchain/m68k-amigaos-toolchain/sources/binutils-2.9.1/gas/config/m68k-parse.y y.tab.c m68k-parse.c -- /home/amiga/toolchain/m68k-amigaos-toolchain/sources/binutils-2.9.1/gas/../ylwrap: 70: /home/amiga/toolchain/m68k-amigaos-toolchain/sources/binutils-2.9.1/gas/config/m68k-parse.y: Permission denied make[1]: * [m68k-parse.c] Error 1 make[1]: Leaving directory `/home/amiga/toolchain/m68k-amigaos-toolchain/build/binutils-2.9.1/gas' make: * [all-gas] Error 2

On the other hand, if I install my self-compiled bison 2.3 (and without applying the patch in this pull request), the compilation goes further but halts at:

/home/amiga/toolchain/m68k-amigaos-toolchain/sources/gcc-2.95.3/gcc/c-parse.h:64: error: redeclaration of enumerator ‘RETURN’ /home/amiga/toolchain/m68k-amigaos-toolchain/sources/gcc-2.95.3/gcc/rtl.def:503: note: previous definition of ‘RETURN’ was here make[1]: * [c-lex.o] Error 1 make[1]: Leaving directory `/home/amiga/toolchain/m68k-amigaos-toolchain/build/gcc-2.95.3/gcc' make: * [all-gcc] Error 2

If I apply the patch in this pull-request, then the compilation succeeds.

What I did next, was to extract bison 1.35 from your toolkit and install it system-wide and re-ran the compilation and the compilation succeeds!

So, I am guessing that somehow the packages from your toolkit are not shadowing the system tools. This is a virgin system, so no system modifications whatsoever. I specifically installed this VM for your toolkit. :-) Please let me know if you need something else tested!

Between compilations, I ran:

./bootstrap.sh --prefix=/opt/m68k-amigaos clean

to clean up the build.

I dabbled a bit to see whether your toolkit produces the bison executable, but running:

find /home/amiga/toolchain/m68k-amigaos-toolchain -name bison

does not find any bison executable. Then I thought, perhaps your build system places it in /opt/m68k-amigaos so I tried to locate it there and I still did not find it.

Kind regards, Eva

[cahirwpz]

So, I am guessing that somehow the packages from your toolkit are not shadowing the system tools.

Ok. I think I know where's the problem. I had been reported and I thought I fixed it.

The problem is with compare_version function which requires python interpreter. This proved to be unreliable and needs to be rewritten as shell script.

[cahirwpz]

Hi Eva,

Please re-run build script with most recent changes. I think the issue is now solved for good.

Kind regards Krystian

[cxtal]

Dear Krystian,

You did it! Thanks! :+1: And thank you for the wonderful toolchain!

Kind regards, Eva