| 1 |
On 12/15/2010 11:39 PM, Perry Smith wrote: |
| 2 |
> I hope its ok to post an attachment to this list. |
| 3 |
|
| 4 |
Should be ok, however there likely is some size limit. |
| 5 |
|
| 6 |
> Attached is a sample tar file. |
| 7 |
> Get inside "sample" and type make. |
| 8 |
> I believe this satisfies all of the requirements but if it does not, please let me know. |
| 9 |
|
| 10 |
In your sample it is 'a' telling the linker to keep 'a', |
| 11 |
but it has to be 'b' telling the linker that 'afunc' is required, |
| 12 |
without having 'b' to know it is 'a' providing 'afunc'. |
| 13 |
|
| 14 |
There are more requirements I failed to remember their importance before: |
| 15 |
|
| 16 |
*) liba.a, libb.a and libd.a have to be handled identically: |
| 17 |
So there has to be libd.imp similar to liba.imp. libtool knows whether the |
| 18 |
shared library just created is allowed to have undefined symbols or not, |
| 19 |
so it can act differently for b eventually. |
| 20 |
|
| 21 |
*) Before linking b.1.o there is noone to create b.imp: |
| 22 |
Undefined symbols usually are not explicitly specified by package maintainers. |
| 23 |
Using linker flag '-G' does help here to not need b.imp. It is recommended |
| 24 |
to create runtime-linking-enabled shared objects anyway, but 'gcc -shared' |
| 25 |
does not add it for backwards compatibility with non-rtl-enabled binaries. |
| 26 |
|
| 27 |
*) Not using absolute path for libraries exposes the LIBPATH problem: |
| 28 |
When using filenames without version numbers, recording absolute paths |
| 29 |
in combination with versioned archive members could do instead. However, |
| 30 |
this doesn't feel like the best solution, but Mac-OSX does something similar. |
| 31 |
|
| 32 |
*) Creating statically linked executables doesn't work with import files: |
| 33 |
It works to use '.so' as shared library extension with import files, |
| 34 |
and keep '.a' to contain pure static objects. |
| 35 |
|
| 36 |
*) Maybe more constraints I don't remember right now... |
| 37 |
|
| 38 |
> There is a 5.3 APAR: IY95701 (and its sister APARs) is needed. |
| 39 |
|
| 40 |
There might be more of them: http://gcc.gnu.org/install/specific.html#x-ibm-aix |
| 41 |
|
| 42 |
Thank you! |
| 43 |
/haubi/ |
| 44 |
|
| 45 |
> That cost me half a day. |
| 46 |
> Turns out, I don't need the -bautoload option but I used it as a stepping stone to get this final resolution. |
| 47 |
> |
| 48 |
> The two tricks are b.imp and liba.imp. The rest is fairly normal I believe. |
| 49 |
> |
| 50 |
> Perry |
| 51 |
> |
| 52 |
> On Dec 15, 2010, at 10:34 AM, Michael Haubenwallner wrote: |
| 53 |
> |
| 54 |
>> |
| 55 |
>> On 12/14/2010 05:23 PM, Perry Smith wrote: |
| 56 |
>>>>>> Drawback 1: |
| 57 |
>>>>>> It is impossible to specify undefined symbols in an import file for the |
| 58 |
>>>>>> shared object to allow for subsequent link steps keeping those symbols in the |
| 59 |
>>>>>> created shared object or executables, to be resolved by runtime linking when |
| 60 |
>>>>>> the executable is run. |
| 61 |
>>> |
| 62 |
>>> |
| 63 |
>>> Can you describe the original, base, issue? I'm wondering if there is some confusing between |
| 64 |
>>> import files and export files. I think a specific example would help me to understand. |
| 65 |
>>> This may not be worth the time since it sounds like from your comment that, over time, |
| 66 |
>>> this issue should go away but I'm still curious. |
| 67 |
>> |
| 68 |
>> Trying to create a sample from memory: |
| 69 |
>> |
| 70 |
>> Sources: |
| 71 |
>> |
| 72 |
>> $ cat a.c |
| 73 |
>> int afunc(void) { return 0; } |
| 74 |
>> |
| 75 |
>> $ cat b.c |
| 76 |
>> extern int afunc(void); |
| 77 |
>> int bfunc(void) { return afunc() + 1; } |
| 78 |
>> |
| 79 |
>> (optional): |
| 80 |
>> $ cat c.c |
| 81 |
>> int cfunc(void) { return 2; } |
| 82 |
>> |
| 83 |
>> $ cat main.c |
| 84 |
>> extern int bfunc(void); |
| 85 |
>> int main(void) { return bfunc(); } |
| 86 |
>> |
| 87 |
>> Actions: |
| 88 |
>> |
| 89 |
>> *) Create a shared object 'a': |
| 90 |
>> from a.c, |
| 91 |
>> with runtime linking enabled, |
| 92 |
>> loaded at runtime as (something like) 'a0'. |
| 93 |
>> |
| 94 |
>> *) Create a shared object 'b': |
| 95 |
>> from b.c, |
| 96 |
>> with runtime linking enabled, |
| 97 |
>> /without/ linking against 'a' (results in 'afunc' being undefined), |
| 98 |
>> loaded at runtime as (something like) 'b0'. |
| 99 |
>> |
| 100 |
>> *) Create an executable 'exe': |
| 101 |
>> from main.c, |
| 102 |
>> linking against 'a' (without any version number), |
| 103 |
>> linking against 'b' (without any version number), |
| 104 |
>> at runtime loading 'a0' (with some version number), |
| 105 |
>> at runtime loading 'b0' (with some version number). |
| 106 |
>> |
| 107 |
>> The exakt names for linktime and runtime are less important - they just have to be different. |
| 108 |
>> However, for linktime it should be something like 'liba.so'. |
| 109 |
>> |
| 110 |
>> The important problem when creating 'exe' is: |
| 111 |
>> |
| 112 |
>> How to automagically have 'b' tell the linker that it has an undefined symbol 'afunc', |
| 113 |
>> so that the reference to 'a0' is added to 'exe'. |
| 114 |
>> |
| 115 |
>> As far as I have seen, this problem is irrelevant to the LIBPATH problem. |
| 116 |
>> |
| 117 |
>> /haubi/ |
| 118 |
>> -- |
| 119 |
>> Michael Haubenwallner |
| 120 |
>> Gentoo on a different level |
| 121 |
>> |
| 122 |
|
| 123 |
-- |
| 124 |
Michael Haubenwallner |
| 125 |
Gentoo on a different level |
Archives