Shared libraries ought to contain the full path so that executables built
against them can find them at runtime.
eg,
$ otool -L libgcc_s.1.dylib
libgcc_s.1.dylib:
/opt/gcc-4.3.3/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.1.3)
However, there's no self-path in
$ otool -L libgnat.dylib
libgnat.dylib:
libgnat-4.3.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.1.3)
/opt/gcc-4.3.3/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
and no self-path or (because there's none in libgnat itself, I think) path to
libgnat in
$ otool -L libgnarl.dylib
libgnarl.dylib:
libgnarl-4.3.dylib (compatibility version 0.0.0, current version 0.0.0)
libgnat-4.3.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/gcc-4.3.3/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.1.3)
Same behaviour with both Apple's libtool and GNU libtool 2.2.
Interestingly gprbuild knows how to do this right when generating shared
libraries itself.
It's possible to fix the missing full paths using install_name_tool but this is
a bit user-unfriendly!
--
Summary: libgnat.dylib, libgnarl.dylib don't contain full paths
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon at pushface dot org
GCC build triplet: i386-apple-darwin9.6.0
GCC host triplet: i386-apple-darwin9.6.0
GCC target triplet: i386-apple-darwin9.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39336
