1 |
On 12/14/10 01:33, Perry Smith wrote: |
2 |
>> Drawback 1: |
3 |
>> It is impossible to specify undefined symbols in an import file for the |
4 |
>> shared object to allow for subsequent link steps keeping those symbols in the |
5 |
>> created shared object or executables, to be resolved by runtime linking when |
6 |
>> the executable is run. |
7 |
>> But as shared libraries with unresolved symbols are broken "by design" anyway, |
8 |
>> and real runtime dependency management isn't going to work with broken shared |
9 |
>> libraries, this becomes a non-problem as more and more packages get this right. |
10 |
> Does #! .. solve this? (from IBM pubs on the ld command) I'm not 100% clear when libraries with unresolved symbols are used. |
11 |
|
12 |
Unfortunately not. A shared object name ".." seems to not have any special meaning |
13 |
to the linker/binder, but the runtime loader only. |
14 |
The problem is that it is a shared object referencing symbols in "..", while the |
15 |
binary (executable or shared object) currently being linked does not need them, |
16 |
so the binder does not see those symbols as undefined. |
17 |
Import files are to inform the binder where to find symbols when they are needed, |
18 |
but they aren't needed by the current binary. |
19 |
It is even more complex: When one shared object references "..", the binder would |
20 |
have to add a reference to a second shared object, when the symbols used from ".." |
21 |
aren't available in some static object. |
22 |
|
23 |
So there is one indirection too much for import files here. |
24 |
|
25 |
> #! .. (Two dots) Use this name to list symbols that will be resolved by the run-time linker. |
26 |
> Use this file name to create shared objects that will be used by programs making use of the run-time linker. |
27 |
> If you use a module that imports symbols from .. in a program that was not linked with the rtllib option, |
28 |
> symbols will be unresolved, and references to such symbols will result in undefined behavior. |
29 |
|
30 |
I've stared at and tried this for weeks without success in my case... |
31 |
|
32 |
/haubi/ |
33 |
-- |
34 |
Michael Haubenwallner |
35 |
Gentoo on a different level |