[PATCH] FAT library support for libatomic, libgfortran, libgomp, libstdc++

[Iain Sandoe]

David Edelsohn <dje.gcc@gmail.com> wrote:

> On Wed, Jun 3, 2020 at 3:14 PM Iain Sandoe <idsandoe@googlemail.com> wrote:

>>> libstdc++-v3/
>>>       * Makefile.am (tmake_file): Build and install AIX-style FAT libraries.
>>>       * Makefile.in: Regenerate.
>>>       * configure.ac (tmake_file): Substitute.
>>>       * configure: Regenerate.
>>>       * configure.host (aix*): Define tmake_file.
>>>       * config/os/aix/t-aix: New file.
>>>       * empty.mk: New file.
>>
>> As a “proof of principle, quick hack” I used the following fragment for
>> libstdc++
>> on Darwin; this means that the same fragment would work for X86 and PPC
>> - and (in principle) would work for as many sub-archs as we elected to  
>> build.
>>
>> My only concern in the short-term is about dependencies; is it defined  
>> that
>> the MULTIBUILDTOP case cannot be active until all the deps are built?
>>
>> (the libgcc_s case for Darwin which is already FAT is more complex but  
>> does
>>  have rules for the components to be built first).
>

> On AIX I can start building the "FAT" libraries without actually
> relying upon them for more than the "native" objects.  So I slowly can
> create 32/64 bit compatible libraries and then enable the multilib
> configuration bits at the end to instruct GCC to look at the same
> directory level for both 32 bit and 64 bit objects.  I don't know if
> that is viable for Darwin.

probably, since the linker is happy to consume either - so long as the
search paths are there for the multi-lib style ld64 will use the first lib
it finds with a viable slice.

> And on AIX I cannot transition for some libraries and not others.  In
> other words, I can't switch C++ and Fortran, but not Objective-C and
> GCCGo.

That would seem unwise for Darwin too - even if it would work - it would
create confusion.
Iain