Re: [MiNT] Native GCC built

The first field is the name of the multilib. It is also the name of the subdirectory where the libs live.

[...]

The first entry (single dot) is the default.
I guess you will get what you expect if you manage to change the gcc settings so the first line of -print-multi-lib is:
.;@m68000

[...]

If it works, that will cause absolutely no regression in the cross-compiler. That will just instruct gcc to use -m68000 when building the default libraries, which is exactly what you expect.

I've been thinking about this for a while, it isn't that simple. MiNT's way of doing multilib has been so far:

<prefix>/m68020-60 for -m68020-60

<prefix>/m68020-60/short for -m68020-60 -mshort

<prefix>/m5475 for -mcpu=5475

<prefix>/m5475/mshort for -mcpu=5475 -mshort

<prefix>/mshort for <everything else not mapped> -mshort

where <prefix> is either /usr/lib for user libraries or /usr/lib/gcc/<target>/version for gcc libraries. This isn't anything strange if you expect that your host is and always will be a plain m68000 machine, same as i386 has been for a long time the default for PCs (i.e. there wasn't any <prefix>/i386 directory)

However, as soon as x64 targets started to emerge, this wasn't the case anymore and Linux distributions have changed this: the default is now x64 which goes into <prefix> while i386 (if supported) goes into <prefix>/lib32 (for instance). But we didn't do this transition when 030, 060 or CF targets had appeared.

Tricks like trying to achieve ".;@m68000" don't make sense because gcc then tries to create a subdirectory "." and fails. Even if you work around this somehow, then you'd overwrite the libs in <prefix> and in the case you're running a FireBee gcc, incorrect gcc libraries would be linked in that case (although correct user libraries, like libc or libm from <prefix>/m5475, would be linked because mintlib installer put it there).

Now, the <prefix>/m68000 solution. Doesn't make sense either because then we'd end up in correct installation, true but with duplicated gcc libraries. For example, if the host compiler is 5475, <prefix>/5475 and <prefix> would contain the same libraries, if the host compiler is 68000, <prefix>/m68000 and <prefix> would contain the same libraries => waste of space and it looks trange. AFAIK, there's no way how to build multilibs only, without the default one. And even if it is possible, we would lose the ability to compile without a CPU switch.

IMO, the only correct solution to this problem is to do it as everywhere else:

1) If I want a m68000 host build, my multilibs are <prefix>/m68020-60 and <prefix>/m5475

2) If I want a m68020-60 host build, my multilibs are <prefix>/m68000 and <prefix>/m5475

3) If I want a m5475 host build, my multilibs are <prefix>/m68020-60 and <prefix>/m68000

Please note that in all cases, if you specify also "native" CFLAGS, like gcc -mcpu=5475 for 3), it will work because it will fall into "everything else", i.e. <prefix> and not looking for <prefix>/m5475.

There is no need to introduce new targets unless you want to be able to cross compile m68020-60 gcc on m5475 host for example what we can safely assume that we don't.

So, to make this working, it needs to be done:

1. Three different branches how to create multilib targets. Sounds hard but it is not. For example, x64 linux does following:

MULTILIB_OPTIONS = m64/m32

MULTILIB_DIRNAMES = 64 32

MULTILIB_OSDIRNAMES = ../lib64$(call if_multiarch,:x86_64-linux-gnu) \

$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:i386-linux-gnu)

i.e. it dynamically generates multilib directories based on detected host/target.

2. Remove any dependency on defined multilib structure from mintlib and lib projects, leaving only a CFLAGS friendly option of one installation (similar what Alan wants to achieve with the kernel build).

3. Profit :)

In this way, everybody will be happy, FB users can produce binaries for everyone, 060 users the same, 000 users the same. When I think about it, I don't know why we insisted to have the stable multilib structure so much, pml, mintlib and gemlib/cflib/gemma are the only projects which depend on this, all the others can be adapted with a proper ./configure --libdir option which can be specific for each (sparemint/gentoo/...) distribution.

--
MiKRO / Mystic Bytes
http://mikro.atari.org