[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
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
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
- Until that, there is no way to build a clean 020 FreeMiNT kernel with GCC
Finally, I'm glad this problem appears now, this is the proof that MiNT
developers starts to do serious things with GCC 4.x.