[adtools] Re: libstdc++-v3 Multilib Support

  • From: Sebastian Bauer <mail@xxxxxxxxxxxxxxxxxxx>
  • To: adtools@xxxxxxxxxxxxx
  • Date: Wed, 07 Jul 2010 23:58:53 +0200

Hi,

Trevor Scroggins <trevor.scroggins@xxxxxxxxx> schrieb:
> On Wed, Jul 7, 2010 at 1:52 AM, Sebastian Bauer
> <mail@xxxxxxxxxxxxxxxxxxx> wrote:
> > I'm currently experimenting a bit with multilib support myself (adding
> > mcrt=clib2 to the MULTILIBS define, in order to generate a newlib libgcc
> file
> > and a clib libgcc file). Then libgcc is also compiled with libgcc and
> > deposited into the specified directory.
> > The only problem so far is that that the libgcc compilation for clib2
aborts
> > as it cannot find the sys/param.h file. Therefore, it seems to miss the
fact
> > that this file is not available.
> 
> I've been looking at this as well, although I'm not sure multilib is
> the best way to go. Other platforms use separate toolchains, e.g.
> i686-linux and i686-linux-uclibc; however, they do provide support for
> linking with different C libraries, e.g. '-mglibc' and '-uclibc'. I'm
> not sure how that works.
> 
> I haven't had any problems building a clib2 cross-compiler under
> Cygwin or MSYS/MinGW, complete with multilib support in libgcc. I've
> uploaded a build/install log and DESTDIR and SDK directory listings to
> http://www.spookysoftware.com/home/amigaos/gcc/files if you want to
> take a look.

What I meant was to add 

MULTILIB_OPTIONS = mcrt=clib2
MULTILIB_DIRNAMES = clib2

and leaving all the other bits intact as they are in the SVN. That way newlib
and clib2 libs are generated in the same build (and hence the building is
simplified). The reason for the failing that I observed is that the (multilib)
configure of libiberty doesn't pass the -mcrt=clib2 flag to the compiler that
is used to determine the capabilities in configure (and thus the contents of
config.h). This could be a problem in the baseline, but I'm not sure. For
libstdc++, the flags are properly passed.

I can fix this easily in configure, but I have no clue where this really stems
from.

If you know another possibility how to compile the newlib and clib2 stuff in
one run, please let me know.

> > AFAIK the soft-float for newlib is not supported.
> 
> In what way? Because it's not included with the SDK? I tend to agree
> with that, but see below re: shared libraries.
> 
> >> (And newlib sources would be helpful as well. ;-) With the
> >> correct source in hand, binary incompatibilities in libstdc++.so
> >> shouldn't be a problem for cross-compilers. Or, is that even an issue?
> >
> > What do you mean by that? I would expect that the libstc++.so files are
> > compatible whether compiled native (which AFAIK is currently not possible)
> or
> > cross.
> 
> We want to link against the same bits distributed by Hyperion in the
> official SDK, right? If there's an adtools tag/snapshot that
> represents a specific SDK release, then we shouldn't have a problem.

Yes, it it is definitively helpful to tag the versions.

> I'm also not sure how clib2/newlib come into play. A cross-compiler
> will have clib2/lib/libstdc++.so, clib2/lib/soft-float/libstdc++.so,
> newlib/lib/libstdc++.so, and newlib/lib/soft-float/libstdc++.so. If we
> can link against any of those and run against the single
> SOBJS:libstdc++.so ->
> SDK:gcc/lib/gcc/ppc-amigaos/4.2.4/newlib/lib/libstdc++.so, it's not a
> problem.
> 
> The same reasoning applies to all shared libraries. If we only support
> ELF shared libraries built using newlib[/hard-float], the point is
> moot. I like the flexibility of multiple C libraries, but the current
> implementation is a bit confusing.

Yes, I think (but others may correct me) that currently only newlib/hard-float
is supported for shared objects. I don't know whether it is possible to
distinguish between different natures of shared objects (i.e., if a program is
linked against newlib it should use a newlib shared object, if it is linked
against clib, it uses the clib shared object).

Bye,
Sebastian


-- 
______________________________________________________________________________
Amiga Development tools ML - //www.freelists.org/list/adtools
Homepage...................: http://www.sourceforge.net/projects/adtools
Listserver help............: mailto:adtools-request@xxxxxxxxxxxxx?Subject=HELP

Other related posts: