Bug#687642: gnat-4.6: libgnarl-4.6.a should be rebuilt with -fPIC, libaws FBTFS
Package: gnat-4.6 Version: 4.6.4-1 Followup-For: Bug #687642 Control: retitle -1 gnat-4.6: on armel armhf, gcc -shared reads libgnarl-4.6.a instead of .so Hello. Here is a reproducer, tested on abel.debian.org (armel). The bug may present other symptoms: ld will complain about missing symbols, because .a does not embed the name of its own dependencies. #!/bin/sh cat tmp.ads EOF with Ada.Task_Identification; use Ada.Task_Identification; package Tmp is T : Task_Id := Current_Task; end Tmp; EOF gcc-4.6 -c -fPIC -I- -gnatA tmp.ads gcc-4.6 -shared -o libtmp.so.1 -L/usr/lib/gcc/arm-linux-gnueabi/4.6/adalib -Wl,-z,defs -Wl,-soname,libtmp.so.1 tmp.o -lgnarl-4.6 -lgnat-4.6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687642: gnat-4.6: libgnarl-4.6.a should be rebuilt with -fPIC, libaws FBTFS
Hi, (sorry for the delay, but for some reason I didn't receive this email) libgnarl-4.6.a is the *static* library, it should definitely not be compiled with -fPIC. The *shared* library, libgnarl-4.6.so, is already built with -fPIC. If you have time before I do, please investigate why gnatmake, invoked thus: gnatmake -j1 -fPIC -p -Pdebian/build_aws.gpr -Xkind=dynamic \ -Xsoname=libaws.so.2.10.2 tries to link the new shared library against the static version of libgnarl-4.6. If we're lucky, the problem is in build_aws.gpr; if we're unlucky, it is in gnatmake itself and only strikes on armhf because all other architectures are OK. I have a hunch that the latter is closer to the truth :/ This is what I get: # gnatmake -j1 -fPIC -p -Pdebian/build_aws.gpr -Xkind=dynamic -Xsoname=libaws.so.2.10.2 building dynamic library for project build_aws gcc-4.6 -shared -o /root/libaws-2.10.2/debian/tmp/dynamic//libaws.so.2.10.2 ... /root/libaws-2.10.2/debian/tmp/obj-dynamic/aws-services-directory.o ... /usr//bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/4.6/adalib//libgnarl-4.6.a(s-taprop.o): relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/arm-linux-gnueabihf/4.6/adalib//libgnarl-4.6.a: could not read symbols: Bad value collect2: ld returned 1 exit status gnatmake: gcc-4.6 execution error It still looks like a problem in libgnarl-4.6.a to me. armhf is built with Thumb2 which according to some more knowledgeable people than myself, has only 25 bits for largest relocation vs 27 bits in arm mode. Usually, this is not a problem but some packages do fail to build because of this. What works without -fPIC on most architectures, can potentially need -fPIC on armhf (and I've filed quite a few bugs about this myself. Regards Konstantinos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687642: gnat-4.6: libgnarl-4.6.a should be rebuilt with -fPIC, libaws FBTFS
Konstantinos Margaritis wrote: libgnarl-4.6.a is the *static* library, it should definitely not be compiled with -fPIC. The *shared* library, libgnarl-4.6.so, is already built with -fPIC. If you have time before I do, please investigate why gnatmake, invoked thus: gnatmake -j1 -fPIC -p -Pdebian/build_aws.gpr -Xkind=dynamic \ -Xsoname=libaws.so.2.10.2 tries to link the new shared library against the static version of libgnarl-4.6. If we're lucky, the problem is in build_aws.gpr; if we're unlucky, it is in gnatmake itself and only strikes on armhf because all other architectures are OK. I have a hunch that the latter is closer to the truth :/ This is what I get: # gnatmake -j1 -fPIC -p -Pdebian/build_aws.gpr -Xkind=dynamic -Xsoname=libaws.so.2.10.2 building dynamic library for project build_aws gcc-4.6 -shared -o /root/libaws-2.10.2/debian/tmp/dynamic//libaws.so.2.10.2 ... /root/libaws-2.10.2/debian/tmp/obj-dynamic/aws-services-directory.o ... /usr//bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/4.6/adalib//libgnarl-4.6.a(s-taprop.o): relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/arm-linux-gnueabihf/4.6/adalib//4.6.a: could not read symbols: Bad value collect2: ld returned 1 exit status gnatmake: gcc-4.6 execution error This confirms what I said: gnatmake (or gnatlink) is trying to link the *shared* libaws.so.2.10.2 against the *static* libgnarl-4.6.a, which is *wrong*. I don't know in which program this bug is in: either build_aws.gpr or gnatmake or gnatlink. It still looks like a problem in libgnarl-4.6.a to me. armhf is built with Thumb2 which according to some more knowledgeable people than myself, has only 25 bits for largest relocation vs 27 bits in arm mode. Usually, this is not a problem but some packages do fail to build because of this. What works without -fPIC on most architectures, can potentially need -fPIC on armhf (and I've filed quite a few bugs about this myself. No. As I said previously, it is necessary to link the *shared* libaws.so.2.10.2 against the *shared* libgnarl-4.6.so.1. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687642: gnat-4.6: libgnarl-4.6.a should be rebuilt with -fPIC, libaws FBTFS
Package: gnat-4.6 Version: 4.6.3-6 Severity: Important According to: https://buildd.debian.org/status/package.php?p=libawssuite=sid libaws FTBFS at linking phase due to libgnarl-4.6 not built with -fPIC. I am unsure what to change in the gnat-4.6 source to test that so I don't have a patch for that, but if you gave me some pointer as to what I should change, I'd gladly test and send a proper patch. Regards Konstantinos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687642: gnat-4.6: libgnarl-4.6.a should be rebuilt with -fPIC, libaws FBTFS
libgnarl-4.6.a is the *static* library, it should definitely not be compiled with -fPIC. The *shared* library, libgnarl-4.6.so, is already built with -fPIC. If you have time before I do, please investigate why gnatmake, invoked thus: gnatmake -j1 -fPIC -p -Pdebian/build_aws.gpr -Xkind=dynamic \ -Xsoname=libaws.so.2.10.2 tries to link the new shared library against the static version of libgnarl-4.6. If we're lucky, the problem is in build_aws.gpr; if we're unlucky, it is in gnatmake itself and only strikes on armhf because all other architectures are OK. I have a hunch that the latter is closer to the truth :/ Thanks for the bug report. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
