Re: [MiNT] [PATCH] gcc, disable no-multilib directory if multilib switch given

[Alan Hourihane <alanh@fairlite.co.uk>]

On Sat, 2010-05-15 at 23:54 +0200, Vincent Rivière wrote:
> Alan Hourihane wrote:
> > I guess this is one reason why we've ended up with libraries spawning
> > the 16 suffix. Such as -lgem16 in the kernel Makefiles, and the recent
> > -lgcc16 linkage problems too.
> 
> Do you mean the patch is a good thing or not ?
> 

I'm a little torn. But presumably by doing this it will break the
FreeMiNT kernel because using -lgem16, as that library exists
in /usr/lib would be broken as we won't search there. We'd need to fix
FreeMiNT and the cflib/gemlib packages to no longer install libgem16.a
but mshort/libgem.a. I'm not sure what other packages would be affected,
but I guess it's just build fixes, and we'll be avoiding actual runtime
issues.

> And I wonder one thing: since mshort is a multilib, and Gentoo disable 
> multilib usage, you probably have problems for building EmuTOS and FreeMiNT, 
> right ?

I've recently enabled multilib in gentoo for GCC, but not yet updated
the "preview" release tarball. The problem is when building packages,
they are built only once for the target architecture. So we never get
the other libs unless we go fixing a lot of packages.

If we are more strict, then I'll actually turn multilib off again in
Gentoo and then I'll have separate tarballs for the different CPU
targets, which feels better, so go for it. This does mean though that
FreeMiNT kernel builds need a little fixing, so that it only builds one
kernel for the current target GCC has, but we'll have options for
multilib for those with GCC aware versions. We already have this setup
in mintlib.

Alan.