Re: [MiNT] GCC 4.4.3

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

Jo Even Skarstein wrote:
> Same here. The mshort-libs used to have the "16"-prefix, but not
> anymore. Instead they are located in a directory called "mshort". I
> don't know why the linker doesn't find them

Once again, to be very clear.

First, where are stored the libraires ?

On a native system (GCC for MiNT), they are stored in /usr/lib.

On a cross-compiler, the standard place is /usr/m68k-atari-mint/lib. This is 
the case for my Ubuntu binaries, because I made standard deb packages easily 
upgradable and uninstallable.

On Cygwin, I put everything in a separate nonstandard directory, to ease 
uninstallation, since I have no uninstaller.
With my latest Cygwin patch for GCC 4.4.3, the libraries are in 
/opt/cross-mint/m68k-atari-mint/lib.
I my older builds, they were in /usr/local/cross-mint/m68k-atari-mint/lib.

GCC supports a finite set of multilibs (for each CPU variants) depending on 
how it has been configured at compile time. You can check like this:

$ m68k-atari-mint-gcc --print-multi-lib
.;
m68020-60;@m68020-60
m5475;@mcpu=5475
mshort;@mshort
m68020-60/mshort;@m68020-60@mshort
m5475/mshort;@mcpu=5475@mshort

This what I get with the latest GCC 4.4.3 patch.
On each line, there are 2 fields separated with the ';' character.
The first field is the multilib subdir, inside the lib directory.
The second field is the multilib option, with '-' replaced with '@'

For example, the 6h line means:
When I compile and link with the option "-mcpu=5475 -mshort", look at the 
libraries in the "m5475/mshort" subdir. Easy.

The big trap is that if the specific multilib is not found, the default one 
is used silently.
In my previous GCC patches, I had not included the m68020-60/mshort 
multilib, because I didn't know it was useful for FreeMiNT. So when you 
compile FreeMiNT for 020 with such the GCC 4.4.2 patch, the makefile uses as 
usual "-m68020-60 -mshort", but the compiler is not aware of these multilib 
options so it uses the 68000 mlong libgcc instead, which is extremely bad. 
That's why Ozk added the libgcc16 hack, which should absolutely be removed 
when everyone has GCC 4.4.3.

Beware of one other things: to get the right libraries version, you must 
absolutely use the CPU options everywhere, including when linking !

I repeat, mixing libraries build with different CPU options is very insane.
If you have some doubt, add the option -Wl,-t to the linker command line to 
see the absolute name of all the files and libraries linked in.

I hope there will be no more problems like this.

--
Vincent Rivière