Building gcc from source

[sparhawk]

I'm trying to build gcc from SVN using msys2. I'm using the following configure:

../gcc-svn/configure --prefix=/opt/gcc-m68k-dev --target=m68k-elf --with-arch=m68k --with-cpu=m68000 --enable-languages=c,c++ --with-newlib --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --disable-threads --disable-nls --disable-libquadmath --with-gnu-as --with-gnu-ld --without-headers --build=$MSYSTEM_CHOST --host=$MSYSTEM_CHOST

But it always fails with:

checking for m68k-elf-gcc... /d/src/gcc/gcc-svn-msys/./gcc/xgcc -B/d/src/gcc/gcc-svn-msys/./gcc/ -B/opt/gcc-m68k-dev/m68k-elf/bin/ -B/opt/gcc-m68k-dev/m68k-elf/lib/ -isystem /opt/gcc-m68k-dev/m68k-elf/include -isystem /opt/gcc-m68k-dev/m68k-elf/sys-include
checking for suffix of object files... configure: error: in `/d/src/gcc/gcc-svn-msys/m68k-elf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details

I also tried removing the "--with-cpu" option, but that doesn't make a difference.


The problem is that it xgcc passes "-m..." to as which complains that it doesn't support that option.

/d/src/gcc/gcc-svn-msys/./gcc/xgcc -B/d/src/gcc/gcc-svn-msys/./gcc/ -B/opt/gcc-m68k-dev/m68k-elf/bin/ -B/opt/gcc-m68k-dev/m68k-elf/lib/ -isystem /opt/gcc-m68k-dev/m68k-elf/include -isystem /opt/gcc-m68k-dev/m68k-elf/sys-include /tmp/t.c
/d/src/gcc/gcc-svn-msys/./gcc/as: line 106: exec: -m: invalid option
exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]

Any ideas how what I'm doing wrong?

[bebbo]

Originally Posted by sparhawk

I'm trying to build gcc from SVN using msys2. I'm using the following configure:

../gcc-svn/configure --prefix=/opt/gcc-m68k-dev --target=m68k-elf --with-arch=m68k --with-cpu=m68000 --enable-languages=c,c++ --with-newlib --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --disable-threads --disable-nls --disable-libquadmath --with-gnu-as --with-gnu-ld --without-headers --build=$MSYSTEM_CHOST --host=$MSYSTEM_CHOST

But it always fails with:


...


[/CODE]Any ideas how what I'm doing wrong?

You are using a relative path. Never ever do that again when calling configure!

Plus your assembler does not match.

[robinsonb5]

Originally Posted by bebbo

You are using a relative path. Never ever do that again when calling configure!

I thought that was mandatory when compiling GCC?

[sparhawk]

Originally Posted by bebbo

You are using a relative path. Never ever do that again when calling configure!

Plus your assembler does not match.

I'm now rebuilding with an absolute path, but I rather think that this is not the problem. I was building under debian as well, and it worked.


What do you mean that my assembler doesn't match? Shouldn't the correct assembler be used by the build system?

[bebbo]

Originally Posted by sparhawk

I'm now rebuilding with an absolute path, but I rather think that this is not the problem. I was building under debian as well, and it worked.


What do you mean that my assembler doesn't match? Shouldn't the correct assembler be used by the build system?

the gcc is provided by binutils, gcc by gcc.
both are available in various versions.
you can't combine every version of binutils with every version of gcc, but you have to use a working combination.


so the version of your binutils is presumably not compatible to the used gcc version.

[sparhawk]

After compiling binutils it worked. Thanks. Now I get another configure error can not compute EOF. It's really hard to compile gcc...

[bebbo]

Originally Posted by sparhawk

After compiling binutils it worked. Thanks. Now I get another configure error can not compute EOF. It's really hard to compile gcc...

you know that there are pre-configured toolchains which do build binutils, gcc and even something more?


And if you'd only grab the recipes, it might be useful

[sparhawk]

Actually I wanted to take a a look at that CC0 vs MODE_CC issue, because m68k might go out of business if that is not fixed. So I figured that I should be able to compile gcc.

What toolchain can I use for that?

[bebbo]

Originally Posted by sparhawk

Actually I wanted to take a a look at that CC0 vs MODE_CC issue, because m68k might go out of business if that is not fixed.

Yes that's true. Plus there is a bounty on implementing it: https://www.bountysource.com/issues/...uture-releases



On the other side: one can still maintain it's own m68k branch...

Originally Posted by sparhawk

So I figured that I should be able to compile gcc.

What toolchain can I use for that?

You might use mine (amiga-gcc) but


* switch to the master branch after you build everything once by 'make all -j4' (or -j8 or ...). The easiest way to switch is to delete the gcc folder and clone it again, since it's a shallow clone (you can also unshallow it, but that's more complicated).



* modify the Makefile to build it for m68k-elf since there is no m68k-amigaos target in the master branch.


* create soft links where needed, so the m68k-amigaos-as, -ld, ... is used also as m68k-elf-as, -ls, ...



* make clean-gcc and then run make gcc.


Now you should be able to compile for the Amiga using gcc-10-elf.


For testing you may use *uae or vamos.


Good luck hunting.

[sparhawk]

Originally Posted by bebbo

Yes that's true. Plus there is a bounty on implementing it: https://www.bountysource.com/issues/...uture-releases

Yes. That's one motivation, though I guess that the maintainers will grab it much earlier then me, as it already reaches a level, which makes it interesting for them.



Still, it's an interesting project, and maybe they are not interested or have the time to do it (as is the current status). The official maintainers don't have enough time to do this port as there is no commerical incentive, so they would have to do it on their own, which is one reason why the bounty was prepared. I also donated to it, because I'm not sure if I can really complete this and I think in the long run, it may not be good to rot the m68k support away in gcc.

You might use mine (amiga-gcc) but

I was not sure if that would work, as gcc is now at 9.x and yours is currently at 6.5. If I manage to pull this off, would it make sense to backport it (if needed at all)?

Now you should be able to compile for the Amiga using gcc-10-elf.

I guess for this particular task, I don't think I need to be able to compile for Amiga specifically, as on the machine level this change is relevant for all m68k targets. I now successfully compiled gcc from source, even though I had to skip c++v3, but again, for this project it shouldn't matter anyway.
Still, I'm curious what changes you needed to apply, apart from the includes of course, to have a proper Amiga binary? After all, elf is not the native format, so you somehow must have replaced the linker to produce the proper hunk format.

Good luck hunting.

Thanks. We will see how far I get with this as it is only a hobby for me. At least it is interesting, and I already learned a lot about how gcc works and it may be useful for the community as well.