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