[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Compiling FreeMiNT

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

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:

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:

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