| 1 |
> Drawback 1: |
| 2 |
> It is impossible to specify undefined symbols in an import file for the |
| 3 |
> shared object to allow for subsequent link steps keeping those symbols in the |
| 4 |
> created shared object or executables, to be resolved by runtime linking when |
| 5 |
> the executable is run. |
| 6 |
> But as shared libraries with unresolved symbols are broken "by design" anyway, |
| 7 |
> and real runtime dependency management isn't going to work with broken shared |
| 8 |
> libraries, this becomes a non-problem as more and more packages get this right. |
| 9 |
Does #! .. solve this? (from IBM pubs on the ld command) I'm not 100% clear when libraries with unresolved symbols are used. |
| 10 |
|
| 11 |
#! .. (Two dots) Use this name to list symbols that will be resolved by the run-time linker. Use this file name to create shared objects that will be used by programs making use of the run-time linker. If you use a module that imports symbols from .. in a program that was not linked with the rtllib option, symbols will be unresolved, and references to such symbols will result in undefined behavior. |
Archives