FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Alt

 
 
LinkBack Thread Tools
 
Old 12-14-2010, 03:23 PM
Perry Smith
 
Default Adventures with Prefix on AIX 5.3

On Dec 14, 2010, at 2:20 AM, Michael Haubenwallner wrote:

> On 12/14/10 01:33, Perry Smith wrote:
>>> Drawback 1:
>>> It is impossible to specify undefined symbols in an import file for the
>>> shared object to allow for subsequent link steps keeping those symbols in the
>>> created shared object or executables, to be resolved by runtime linking when
>>> the executable is run.


Can you describe the original, base, issue? I'm wondering if there is some confusing between import files and export files. I think a specific example would help me to understand. This may not be worth the time since it sounds like from your comment that, over time, this issue should go away but I'm still curious.

Perry
 
Old 12-14-2010, 07:34 PM
Perry Smith
 
Default Adventures with Prefix on AIX 5.3

On Dec 14, 2010, at 2:22 AM, Michael Haubenwallner wrotenow with CC-ing list)

On 12/14/10 01:08, Perry Smith wrote:
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

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

3 *****/gsa/ausgsa/projects/r/ruby/lib libiconv.a *********libiconv.so.2 ******

and it still fails.

This is interesting - I've not recognized that LIBPATH overrides absolute path too.

I asked "the higher ups" about this and they asked "do you have another library that referenced libiconv that did not have an absolute path?" *So, I made a simpler test and sure enough, it does work. *So, I have "x" which looks like:
** * * * * * * * * * * ****Import File Strings***INDEX *PATH * * * * * * * * * * * * *BASE * * * * * * * *MEMBER * * * * * * *0 * * */gsa/ausgsa-p9/06/ruby/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.5.0:/gsa/ausgsa-p9/06/ruby/bin/../lib/gcc:/gsa/ausgsa-p9/06/ruby/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.5.0/../../..:/usr/lib:/lib * * * * * * * * * * * * * * * * * * * **1 * * * * * * * * * * * * * * * * * *libc.a * * * * * * *shr.o * * * * * * **2 * * */gsa/ausgsa/projects/r/ruby/lib libintl.a * * * * * libintl.so.8 * * * *
and libintl.so.8 that looks like:
** * * * * * * * * * * ****Import File Strings***INDEX *PATH * * * * * * * * * * * * *BASE * * * * * * * *MEMBER * * * * * * *0 * * */gsa/ausgsa/projects/r/ruby/lib:/gsa/ausgsa-p9/06/ruby/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.5.0:/gsa/ausgsa-p9/06/ruby/bin/../lib/gcc:/gsa/ausgsa-p9/06/ruby/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.5.0/../../..:/usr/lib:/lib * * * * * * * * * * * * * * * * * * * **1 * * * * * * * * * * * * * * * * * *libpthread.a * * * *shr_xpg5.o * * * * *2 * * * * * * * * * * * * * * * * * *libc.a * * * * * * *shr.o * * * * * * **3 * * */gsa/ausgsa/projects/r/ruby/lib libiconv.a * * * * *libiconv.so.2 * * **
and now I can do:
LIBPATH=/lib ./xhi 4609
x.c is:
#include <stdio.h>#include <libintl.h>
int main(int argc, char *argv[]){** *printf("hi %d
", libintl_version);}
I'm going to continue to explore and see if I can find all the libraries that reference libiconv, fix them, and then see if I can get gcc to work with LIBPATH set to /lib.
On the other topic of using import files, I've had some thoughts that I have not explored yet. *First, I didn't think until today but one import file can reference multiple shared objects. *The reason this is important to me is I believe that being able to do 32 and 64 bit applications is going to be very important to AIX users. *I'm not asking Portage to support it out of the box but I'm also hoping that Portage does not make it next to impossible to implement.
I need to play with this more but my current train of thought is to have one import file. *It could be like:
#! libfoo.X.a(libfoo_32.X.Y.so)# 32sym1sym2sym3
#! libfoo.X.a(libfoo_64.X.Y.so)# 64sym1sym2sym3
I have not experimented with any of that yet. *But if that works, then the B, B1, B2, and C options become plausible to me. *Likewise, if my experiments with absolute paths in the library files works, then it seems option A becomes plausible too.
 
Old 12-14-2010, 11:25 PM
Perry Smith
 
Default Adventures with Prefix on AIX 5.3

On Dec 14, 2010, at 2:22 AM, Michael Haubenwallner wrotenow with CC-ing list)

On 12/14/10 01:08, Perry Smith wrote:
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

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

3 *****/gsa/ausgsa/projects/r/ruby/lib libiconv.a *********libiconv.so.2 ******

and it still fails.

This is interesting - I've not recognized that LIBPATH overrides absolute path too.

So, I went back and relinked my gettext libraries so that all of the ones that reference iconv now use aboslute paths and it did solve my problem:
LIBPATH=/lib gcc -o x x.c /gsa/ausgsa/projects/r/ruby/lib/libintl.a
LIBPATH=/lib ./xhi 4609
Hence, the gcc I have would work when called from inside Java.
Also, the guy I'm talking to mentioned rtl_enable -s. *I've not used it but it seems like it might make life a lot easier.
You can play with it some but if you point it at a shared object, it creates a script, an import file, and an export file. *Together, they will recreate the shared object. *You can then edit the files, for example, adding absolute paths, if you want to change the header of the shared object file.
I am not familiar with portage at all but I've seen that it patches various things like the configure script, etc. *It might be easier / safer to leave the scripts alone (leave libtool do whatever it wants) and then use rtl_enable -s, edit the resulting files, and rebuild the shared object the way you want it.
Perry
 
Old 12-15-2010, 02:51 PM
Michael Haubenwallner
 
Default Adventures with Prefix on AIX 5.3

On 12/15/2010 01:25 AM, Perry Smith wrote:
>> This is interesting - I've not recognized that LIBPATH overrides absolute path too.
>
> So, I went back and relinked my gettext libraries so that all of the ones that reference
> iconv now use aboslute paths and it did solve my problem:

Makes me happy to know my memory hasn't failed on this

> Also, the guy I'm talking to mentioned rtl_enable -s.

Yes, I'm aware of rtl_enable - it is designed to enable runtime linking
for shared libraries that cannot be recreated from scratch, like /lib/libc.a.

> I am not familiar with portage at all but I've seen that it patches various things like the configure script, etc.
> It might be easier / safer to leave the scripts alone (leave libtool do whatever it wants) and then use rtl_enable -s,
> edit the resulting files, and rebuild the shared object the way you want it.

It is more efficient to enable runtime linking during creation of shared objects
already. Also, creating import/export files with wanted content firsthand is
easier than editing them later.

Using rtl_enable would still require patching libtool-related scripts,
to keep libtool uniformly handling all platform specifics - this is what
it is designed for.

So I don't see any fit for rtl_enable with any source-based package,
neither indirectly via libtool nor directly in the package's makefiles.

/haubi/
--
Michael Haubenwallner
Gentoo on a different level
 
Old 12-15-2010, 03:34 PM
Michael Haubenwallner
 
Default Adventures with Prefix on AIX 5.3

On 12/14/2010 05:23 PM, Perry Smith wrote:
>>>> Drawback 1:
>>>> It is impossible to specify undefined symbols in an import file for the
>>>> shared object to allow for subsequent link steps keeping those symbols in the
>>>> created shared object or executables, to be resolved by runtime linking when
>>>> the executable is run.
>
>
> Can you describe the original, base, issue? I'm wondering if there is some confusing between
> import files and export files. I think a specific example would help me to understand.
> This may not be worth the time since it sounds like from your comment that, over time,
> this issue should go away but I'm still curious.

Trying to create a sample from memory:

Sources:

$ cat a.c
int afunc(void) { return 0; }

$ cat b.c
extern int afunc(void);
int bfunc(void) { return afunc() + 1; }

(optional):
$ cat c.c
int cfunc(void) { return 2; }

$ cat main.c
extern int bfunc(void);
int main(void) { return bfunc(); }

Actions:

*) Create a shared object 'a':
from a.c,
with runtime linking enabled,
loaded at runtime as (something like) 'a0'.

*) Create a shared object 'b':
from b.c,
with runtime linking enabled,
/without/ linking against 'a' (results in 'afunc' being undefined),
loaded at runtime as (something like) 'b0'.

*) Create an executable 'exe':
from main.c,
linking against 'a' (without any version number),
linking against 'b' (without any version number),
at runtime loading 'a0' (with some version number),
at runtime loading 'b0' (with some version number).

The exakt names for linktime and runtime are less important - they just have to be different.
However, for linktime it should be something like 'liba.so'.

The important problem when creating 'exe' is:

How to automagically have 'b' tell the linker that it has an undefined symbol 'afunc',
so that the reference to 'a0' is added to 'exe'.

As far as I have seen, this problem is irrelevant to the LIBPATH problem.

/haubi/
--
Michael Haubenwallner
Gentoo on a different level
 
Old 12-15-2010, 09:39 PM
Perry Smith
 
Default Adventures with Prefix on AIX 5.3

I hope its ok to post an attachment to this list.

Attached is a sample tar file. Get inside "sample" and type make. I believe this satisfies all of the requirements but if it does not, please let me know.

There is a 5.3 APAR: IY95701 (and its sister APARs) is needed. That cost me half a day. Turns out, I don't need the -bautoload option but I used it as a stepping stone to get this final resolution.

The two tricks are b.imp and liba.imp. The rest is fairly normal I believe.

Perry

On Dec 15, 2010, at 10:34 AM, Michael Haubenwallner wrote:

>
> On 12/14/2010 05:23 PM, Perry Smith wrote:
>>>>> Drawback 1:
>>>>> It is impossible to specify undefined symbols in an import file for the
>>>>> shared object to allow for subsequent link steps keeping those symbols in the
>>>>> created shared object or executables, to be resolved by runtime linking when
>>>>> the executable is run.
>>
>>
>> Can you describe the original, base, issue? I'm wondering if there is some confusing between
>> import files and export files. I think a specific example would help me to understand.
>> This may not be worth the time since it sounds like from your comment that, over time,
>> this issue should go away but I'm still curious.
>
> Trying to create a sample from memory:
>
> Sources:
>
> $ cat a.c
> int afunc(void) { return 0; }
>
> $ cat b.c
> extern int afunc(void);
> int bfunc(void) { return afunc() + 1; }
>
> (optional):
> $ cat c.c
> int cfunc(void) { return 2; }
>
> $ cat main.c
> extern int bfunc(void);
> int main(void) { return bfunc(); }
>
> Actions:
>
> *) Create a shared object 'a':
> from a.c,
> with runtime linking enabled,
> loaded at runtime as (something like) 'a0'.
>
> *) Create a shared object 'b':
> from b.c,
> with runtime linking enabled,
> /without/ linking against 'a' (results in 'afunc' being undefined),
> loaded at runtime as (something like) 'b0'.
>
> *) Create an executable 'exe':
> from main.c,
> linking against 'a' (without any version number),
> linking against 'b' (without any version number),
> at runtime loading 'a0' (with some version number),
> at runtime loading 'b0' (with some version number).
>
> The exakt names for linktime and runtime are less important - they just have to be different.
> However, for linktime it should be something like 'liba.so'.
>
> The important problem when creating 'exe' is:
>
> How to automagically have 'b' tell the linker that it has an undefined symbol 'afunc',
> so that the reference to 'a0' is added to 'exe'.
>
> As far as I have seen, this problem is irrelevant to the LIBPATH problem.
>
> /haubi/
> --
> Michael Haubenwallner
> Gentoo on a different level
>
 
Old 12-16-2010, 03:42 PM
Michael Haubenwallner
 
Default Adventures with Prefix on AIX 5.3

On 12/15/2010 11:39 PM, Perry Smith wrote:
> I hope its ok to post an attachment to this list.

Should be ok, however there likely is some size limit.

> Attached is a sample tar file.
> Get inside "sample" and type make.
> I believe this satisfies all of the requirements but if it does not, please let me know.

In your sample it is 'a' telling the linker to keep 'a',
but it has to be 'b' telling the linker that 'afunc' is required,
without having 'b' to know it is 'a' providing 'afunc'.

There are more requirements I failed to remember their importance before:

*) liba.a, libb.a and libd.a have to be handled identically:
So there has to be libd.imp similar to liba.imp. libtool knows whether the
shared library just created is allowed to have undefined symbols or not,
so it can act differently for b eventually.

*) Before linking b.1.o there is noone to create b.imp:
Undefined symbols usually are not explicitly specified by package maintainers.
Using linker flag '-G' does help here to not need b.imp. It is recommended
to create runtime-linking-enabled shared objects anyway, but 'gcc -shared'
does not add it for backwards compatibility with non-rtl-enabled binaries.

*) Not using absolute path for libraries exposes the LIBPATH problem:
When using filenames without version numbers, recording absolute paths
in combination with versioned archive members could do instead. However,
this doesn't feel like the best solution, but Mac-OSX does something similar.

*) Creating statically linked executables doesn't work with import files:
It works to use '.so' as shared library extension with import files,
and keep '.a' to contain pure static objects.

*) Maybe more constraints I don't remember right now...

> There is a 5.3 APAR: IY95701 (and its sister APARs) is needed.

There might be more of them: http://gcc.gnu.org/install/specific.html#x-ibm-aix

Thank you!
/haubi/

> That cost me half a day.
> Turns out, I don't need the -bautoload option but I used it as a stepping stone to get this final resolution.
>
> The two tricks are b.imp and liba.imp. The rest is fairly normal I believe.
>
> Perry
>
> On Dec 15, 2010, at 10:34 AM, Michael Haubenwallner wrote:
>
>>
>> On 12/14/2010 05:23 PM, Perry Smith wrote:
>>>>>> Drawback 1:
>>>>>> It is impossible to specify undefined symbols in an import file for the
>>>>>> shared object to allow for subsequent link steps keeping those symbols in the
>>>>>> created shared object or executables, to be resolved by runtime linking when
>>>>>> the executable is run.
>>>
>>>
>>> Can you describe the original, base, issue? I'm wondering if there is some confusing between
>>> import files and export files. I think a specific example would help me to understand.
>>> This may not be worth the time since it sounds like from your comment that, over time,
>>> this issue should go away but I'm still curious.
>>
>> Trying to create a sample from memory:
>>
>> Sources:
>>
>> $ cat a.c
>> int afunc(void) { return 0; }
>>
>> $ cat b.c
>> extern int afunc(void);
>> int bfunc(void) { return afunc() + 1; }
>>
>> (optional):
>> $ cat c.c
>> int cfunc(void) { return 2; }
>>
>> $ cat main.c
>> extern int bfunc(void);
>> int main(void) { return bfunc(); }
>>
>> Actions:
>>
>> *) Create a shared object 'a':
>> from a.c,
>> with runtime linking enabled,
>> loaded at runtime as (something like) 'a0'.
>>
>> *) Create a shared object 'b':
>> from b.c,
>> with runtime linking enabled,
>> /without/ linking against 'a' (results in 'afunc' being undefined),
>> loaded at runtime as (something like) 'b0'.
>>
>> *) Create an executable 'exe':
>> from main.c,
>> linking against 'a' (without any version number),
>> linking against 'b' (without any version number),
>> at runtime loading 'a0' (with some version number),
>> at runtime loading 'b0' (with some version number).
>>
>> The exakt names for linktime and runtime are less important - they just have to be different.
>> However, for linktime it should be something like 'liba.so'.
>>
>> The important problem when creating 'exe' is:
>>
>> How to automagically have 'b' tell the linker that it has an undefined symbol 'afunc',
>> so that the reference to 'a0' is added to 'exe'.
>>
>> As far as I have seen, this problem is irrelevant to the LIBPATH problem.
>>
>> /haubi/
>> --
>> Michael Haubenwallner
>> Gentoo on a different level
>>

--
Michael Haubenwallner
Gentoo on a different level
 

Thread Tools




All times are GMT. The time now is 01:16 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org