Bug#687642: gnat-4.6: on armel armhf, gcc -shared reads libgnarl-4.6.a instead of .so
Package: gnat-4.6
Followup-For: Bug #687642
On amd64, /usr/lib/gcc/x86_64-linux-gnu/4.6/adalib/ contains
libgnarl.a
libgnarl.so -> ../../../../../x86_64-linux-gnu/libgnarl-4.6.so.1
On armhf, /usr/lib/gcc/arm-linux-gnueabi/4.6/adalib/ contains
libgnarl-4.6.a -> libgnarl.a
libgnarl.a
libgnarl.so -> ../../../../arm-linux-gnueabi/libgnarl-4.6.so.1
On both /usr/lib/TRIPLET/ contains
libgnarl-4.6.so -> libgnarl-4.6.so.1
libgnarl-4.6.so.1
libgnarl.so -> libgnarl-4.6.so.1
The loader searches for
libgnarl-4.6.so in -L/usr/lib/gcc/TRIPLET/4.6/adalib/ (failure)
libgnarl-4.6.a in -L/usr/lib/gcc/TRIPLET/4.6/adalib/ (success on armel)
libgnarl-4.6.so in /usr/lib/TRIPLET/ (success on amd64)
libgnarl-4.6.a in /usr/lib/TRIPLET/
Solutions:
- no libgnarl-4.6.a symlink (it works on other archs)
- else give the file directly instead of a -l option
"/usr/lib/$(DEB_HOST_MULTIARCH)/libgnarl-4.6.so"
- (hardly documented, maybe not portable) "-l:libgnarl4-6.so"
I checked the two last solutions on armel.
Maybe gnatmake should avoid any -L option at all and use the full path
for libgnat-4.6.so and libgnarl-4.6.so, to avoid this kind of bug in
the future.
The "-Bdynamic"/"-by"/"-call-dynamic" option has no effect because in
the directory where the decision is taken, there is no alternative.
This work-around is easy on the command line. When using projects,
affected packages may append ("-l:libgnarl4-6.so") to the
Library_Options attribute. Recent gnatmakes push all -l options after
the objects, so this is compatible with --as-needed.
Reply to: