Re: [gentoo-alt] Adventures with Prefix on AIX 5.3

[Perry Smith]

On Dec 13, 2010, at 3:45 AM, Michael Haubenwallner wrote:

> On 12/11/2010 01:41 AM, Perry Smith wrote:
>>
>> For both passes, I do "out of tree" builds and build each library in 32 bit mode and again in 64 bit mode.
>> I then rename the 32 bit shared object to e.g. libmpfr32.so.1, the 64 bit object to libmpfr64.so.1, and then create an archive called libmpfr.a.
>
> A Library called 'libmpfr.a' without any version number in plain filename
> is calling for troubles[1].
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=213277#c11

I can recreate this doing:

LIBPATH=/lib gcc -o x x.c && ./x
exec(): 0509-036 Cannot load program gcc because of the following errors:
        0509-022 Cannot load module /gsa/ausgsa/projects/r/ruby/lib/libintl.a(libintl.so.8).
        0509-150   Dependent module /lib/libiconv.a(libiconv.so.2) could not be loaded.
        0509-152   Member libiconv.so.2 is not found in archive 
        0509-022 Cannot load module gcc.
        0509-150   Dependent module /gsa/ausgsa/projects/r/ruby/lib/libintl.a(libintl.so.8) could not be loaded.
        0509-022 Cannot load module .

I went back and rebuilt my libintl.a using absolute paths so the header looks like:

                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /gsa/ausgsa/projects/r/ruby/lib:/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1:/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/../../..:/usr/lib:/lib                                         
1                                    libc.a              shr.o               
2                                    libpthread.a        shr_xpg5.o          
3      /gsa/ausgsa/projects/r/ruby/lib libiconv.a          libiconv.so.2       

and it still fails.  Are you sure if you build with import files it is going to solve the problem?  Seems like it would not but I'm curious what you have in mind.

Note that this is only going to be an issue for libraries that collide with the same base name in /lib.  If I move /lib/libiconv.a out of the way, then the loader finds the correct libiconv.a.

The other question I have is if this is a show stopper for you?  I would argue that what Java is doing is impolite (at least).

Perry