bug-gnu-libiconv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnu-libiconv] libiconv-1.15


From: Michael Felt
Subject: Re: [bug-gnu-libiconv] libiconv-1.15
Date: Sun, 12 Feb 2017 23:46:03 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; rv:38.0) Gecko/20100101 Thunderbird/38.7.2



On 12-Feb-17 20:15, Bruno Haible wrote:
Michael Felt wrote:
Is there something like Homebrew/MacPorts/Fink/OpenPKG/OpenCSW for AIX?
Yes - the most popular would be perzl (http://www.perzl.org/aix/) and
bullfreeware (http://www.bullfreeware.com/).
IBM also has something called the AIX Toolbox. It was more or less idle,
due to legal concerns I suspect (the suit from SCO) but seems to be
'restarting' at:
http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html
Interesting. Thanks for the education.

There is a danger for packagers - as myself: the new archive gets the
shr*.o file of the packaging system and not necessarily one as new as
the system the pre-packaged version gets installed on.
Ah, I understand now. The issue is due to these "multi-arch" .o files.
Usually a binary package consists of a set files that can be installed.
But here we need to install a .o _into_ an existing .a file. Do you have
a recommendation to give how to accommodate this in the build system of
GNU packages in general?
More than just .o and .so "members" in an (ar)chive. There is also supporting programs, not yet updated to a new ABI aka version number (name) for the member. And, also in the case of AIX - the legacy name(s) for the shared member of an archive (shr.o and shr_64.o). Replacing the library (archive) must not break existing programs.

This is what your Makefile.in code does well - besides the new archive it also includes the legacy members from the existing archive. So something linked to libFOO.a(shr.o) continues to run, while new programs can link with libFOO.so.X, and should a newer version come - libFOO.a(shr.o), libFOO.a(libFOO.so.X) and the "newest ABI" as libFOO.a(libFOO.so.Y).

when the ABI is "just an update", then libFOO.so.X is just replaced.

FYI: I have run into all these situations as "aixtools", and have thought a lot about it and may gradually come to a solution for AIX, but I doubt it woud work for linux/sysv/solaris based .so models that expect ../lib for 32-bit and, I hope I have this right ../lib/lib64 for 64-bit support.

I'll try and organize my thoughts and comment later.

The thing to recall is that there will be applications that are not (yet) linked with the new/updated "members". And the easiest example is the multitude of applications dependent on openssl. How long to continue openssl.so.0.9.8, openssl.so.1.0.X and openssl.1.Y? All, one, or latest and previous?

In the GNU/Linux camp such an idea of "fat binaries" has come up as well
[1] but it was dropped soon [2].

RPM are constructed using a so-called .spec file. One of the sections of
the spec file is the %post (similar to %post in kickstart).
I don't think the upstream author of a package should provide these
.spec files, right?

Bruno

[1] https://icculus.org/fatelf/
[2] http://www.osnews.com/story/22446/Ryan_Gordon_Halts_FatELF_Project





reply via email to

[Prev in Thread] Current Thread [Next in Thread]