Re: [MiNT] Compiling FreeMiNT

[Vincent Rivière <vincent.riviere@freesbee.fr>]

Odd Skancke wrote:
> > However, since -mshort is on the command line, -lgcc instead of that
> > wrong -lgcc16 should do what is expected. I don't know why the makefiles
> > are wrong.
>
> That is my fault. But I had to do that because I could not find out how
> to make gcc 4.4.2 use mshort libs when -mshort is present. Possibly I've
> done something wrong compiling your m68k port, but here gcc does not
> enter mshort/m68020-60 lib directories when linking. Therefore I had to
> make a symlink and have it link against gcc16.
>
> If you know what I did wrong, I would be more than happy being told what :)

Of course I can answer, if you ask the question.
We must fix the issues cleanly instead of adding additional kludges.

First, here is how to know which multilib directories are supported by your 
compiler. The result is what I get with gcc 4.4.2 on Cygwin:
$ m68k-atari-mint-gcc -print-multi-lib
.;
m68020-60;@m68020-60
m5475;@mcpu=5475
mshort;@mshort

There is one line for each multilib variant.
On each line, there are 2 parts separated by ';'.
The first part is the subdirectory of lib where the libs for that variant 
are stored.
The second part is the command-line option to match, with '-' replaced with '@'.

In GCC 2.95.3 and my earlier GCC 4.x, there was an additional line:
m68020-60/mshort;@m68020@mshort

I have removed it because people complained about the time lost for 
compiling useless libraries. So the "-m68020-60 -mshort" multilibs are not 
available anymore on my current GCC 4.4.2.

This was a very bad idea because such multilibs are required to build the 
FreeMiNT kernel, but nobody noticed that.

So in my next GCC patch, I plan to add the following multilibs:
m68020-60/mshort;@m68020@mshort
m5475/mshort;@mcpu=5475@mshort

The last one being of course to build a FreMiNT kernel 100% ColdFire.

We may even add more multilibs, but I will start a new thread for that.

So in conclusion:
- The file libgcc.a for the target m68020-60/mshort has not been compiled 
with the latest GCC 4.x builds.
- If that file was built later, there would be no way to tell GCC to use it 
since the way GCC finds it is hardcoded into it, and it had been disabled.
- The right thing to do is to update the GCC patch and rebuild it with all 
the multilibs.
- Until that, there is no way to build a clean 020 FreeMiNT kernel with GCC 
4.4.2.

Finally, I'm glad this problem appears now, this is the proof that MiNT 
developers starts to do serious things with GCC 4.x.

--
Vincent Rivière