AIX: Filename-based shared library versioning for libgcc_s

On 11/11/2014 04:02 PM, David Edelsohn wrote:
> Michael,
> 
> Why does the configure change match with p*-*-aix... instead of power*
> or powerpc*?  Yes, it's unique and will match, but why make it as
> short as possible, which doesn't match other uses?

Actually I did have powerpc* initially, but gmp-6.0.0 config.guess'ed
power7-ibm-aix6.1.0.0 now. Then I've thought that one may use ppc as well,
but now I see this config.sub's to powerpc anyway, so power* is fine.
Patch updated.

> In your documentation, how are you distinguishing between Dynamic
> Linking and Runtime Linking?

I've tried to use the same naming scheme as in the "ld Command Reference"
and the "dlopen Subroutine" man pages.

Actually, there is
at linktime:
  Dynamic Linking: also known as Dynamic Mode or (more common)
   Shared Linking: record a shared object's name into the created binary

at runtime:
  Runtime Loading: load these shared objects at process startup
  Runtime Linking: resolve the symbols after loading shared objects
  Dynamic Loading: load shared objects by application logic with dlopen()

I'm unsure how to make this as clear as possible though.

Thanks!
/haubi/
> 
> Thanks, David
> 
> 
> On Mon, Nov 10, 2014 at 12:41 PM, Michael Haubenwallner
> <michael.haubenwallner@ssi-schaefer.com> wrote:
>>
>>
>> Am 2014-11-10 17:06, schrieb David Edelsohn:
>>> On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner
>>> <michael.haubenwallner@ssi-schaefer.com> wrote:
>>>>
>>>> Am 2014-11-07 20:52, schrieb David Edelsohn:
>>>>> First, please explicitly copy me on AIX or PowerPC patches sent to gcc-patches.
>>>>>
>>>>> I don't have a fundamental objection to including this option, but
>>>>> note that Richi, Honza and I have discovered that using AIX runtime
>>>>> linking option interacts badly with some GCC optimizations and can
>>>>> result in applications that hang in a loop.
>>>>
>>>> Feels like adding the "aix-soname" linking procedure becomes more important:
>>>>
>>>>> All code on AIX is position independent (PIC) by default.  Executables
>>>>> and shared libraries essentially are PIE.  Because of this, AIX does
>>>>> not provide separate "static" libraries and one can link statically
>>>>> with a shared library.
>>>>>
>>>>> Creating a library enabled for runtime linking with -G (-brtl), causes
>>>>> a lot of problems, including a newly recognized failure mode.  Without
>>>>> careful control over AIX symbol export, all global calls with use
>>>>> glink code (equivalent to ELF PLTs). This also creates a TOC entry for
>>>>> every global call, possibly overflowing the TOC.
>>>>
>>>> About to define "careful control over AIX symbol export":
>>>> The symbols listed in the import file are those found in the object files
>>>> only, not the ones created at linktime (like __GLOBAL*) or from the static
>>>> objects found in libc.a. While I do this in libtool from the beginning here,
>>>> I have had a helper script wrapping ld to support '--soname=' for non-libtool
>>>> packages, where creating the import file from the final shared object also
>>>> included static libc-provided symbols, which turned out as dependency pitfall.
>>>
>>> AIX added ELF-like visibility support to XCOFF, which would be
>>> preferred.  Except it was not added in a formal release, like AIX 8.1
>>> and apparently was back-ported to at least AIX 6.1, so its difficult
>>> to phase in the support. One would need to add a configure test for
>>> the feature and not all users are upgrading the system. So one cannot
>>> build and distribute "GCC for AIX 7.1" and know the feature is
>>> available in the system tools.  GCC builds would be incompatible and
>>> object files, libraries, executables created by GCC would be
>>> incompatible.  Basically, a mess.
>>
>> As I've seen the "weak" information on an older AIX 5.3 TL8 already:
>> Is this visibility support something different than what "nm -l" or "nm -P" shows?
>>
>>>> While I haven't focussed on nor explicitly tested, I do believe that this
>>>> also solves problems with global C++ constructor/destructor call orders.
>>>
>>> Why? There still is the problem of the AIX kernel runtime loader
>>> ordering dependent shared objects.
>>
>> Feels like I indeed haven't digged deep enough into that topic yet:
>> To be ignored here then.
>>
>>>>> But the main problem is GCC uses aliases and functions declared as
>>>>> weak to support some C++ features.
>>>>
>>>> This is another reason why I do force runtime linking for our application,
>>>> which uses these C++ features while its main target platform is Linux.
>>>
>>> You have not explained how this has any fix / benefit affecting the
>>> problem, other than separate shared and static libraries.  Forcing
>>> runtime linking seems irrelevant.  It was linking shared before and
>>> linking shared after your patch (with runtime linking) so the net
>>> effect is zero.
>>
>> My main reason here is to allow for *filename*-based sharedlib versioning,
>> which I haven't been able to achive without import files.
>> In-archive versioning is a pita from a package manager's point of view.
>>
>> For a second reason:
>> Due to its Linux-centric history (well, HP-UX and Solaris before), our
>> application architecture does rely on runtime linking in some corner cases.
>> This is why I force that for AIX in our development- and runtime-platform,
>> which is similar to /opt/freeware/, but based on Gentoo Prefix.
>>
>> For a third reason (maybe I don't have deep enough insight as well):
>> If I understand correctly, you switched to build libstdc++ without runtime
>> linking, because of problems when linking statically against the rtl-enabled
>> libstdc++, no? For this case, by incident "aix-soname" does prevent shared
>> objects built with runtime linking from being statically linked.
>>
>> For another reason: I can imaging to provide an rtl_enable'd libc.so as
>> well, to allow for easier use of memory debuggers that intercept the
>> malloc/free &co libc calls... But AFAICT these rely on every sharedlib
>> to be built with runtime linking enabled.
>>
>>> Again, runtime linking of all global symbols affects performance and
>>> bloats the TOC, making TOC overflow more likely.
>>
>> Well, I don't have need to care for performance that much. So do I force
>> -mminimal-toc as well, where the only reason I have seen so far to avoid
>> the -bbigtoc linker flag instead is that gdb has problems with that.
>>
>>> I don't have a fundamental objection to the patch, but you have not
>>> really responded to the potential problems and any motivation for this
>>> feature other than greater SVR4 emulation.  For better or worse, AIX
>>> is not SVR4.  Every library built with this option hurts performance
>>> on AIX and potentially causes mysterious TOC overflow errors, which
>>> confuse users unfamiliar with AIX and whose workarounds hurt
>>> performance even more.
>>
>> Looking more like SVR4 is nothing more than a nice side effect when doing
>> filename-based shlib-versioning this proposed way, not a reason by itself.
>>
>> Which potential problems do you think of? I fail to find more pointers...
>>
>> Thanks!
>> /haubi/

AIX: Filename-based shared library versioning for libgcc_s

Commit Message

Comments

Patch