Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#22345 - [gcc-ada-multilib] missing 32-bit libraries, linking fails with gnatmake

Attached to Project: Community Packages
Opened by Brendan (decibelmute) - Friday, 07 January 2011, 00:28 GMT
Last edited by Florian Pritz (bluewind) - Saturday, 19 February 2011, 16:59 GMT
Task Type Bug Report
Category Packages: Multilib
Status Closed
Assigned To Florian Pritz (bluewind)
Jan Alexander Steffens (heftig)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
When attempting to compile any ADA program with "gnatmake -m32", the process fails at the linking phase with the message "/usr/bin/ld: cannot find -lgnat".

On further inspection, the package contains the files
"/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/32/adalib/libgnat.so", and
"/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/32/adalib/libgnat.so",
which are broken symlinks to "libgnat-4.5.so" and "libgnarl-4.5.so" respectively.
Similarly, the package appears to be missing the corresponding archives "libgnat.a" and "libgnarl.a" as well.


Additional info:
* version: gcc-ada-multilib 4.5.2-4
* 64-bit compilation works as expected


Steps to reproduce:
Attempt to compile any ADA program with the command "gnatmake -m32 [project_name]"

64-bit compilation (working):
$ gnatmake contest.adb
gcc -c contest.adb
gcc -c queuepkg2.adb
gcc -c stackpkg2.adb
gnatbind -x contest.ali
gnatlink contest.ali

32-bit compilation (broken):
$ gnatmake -m32 contest
gcc -c -m32 --RTS=32 contest.adb
gcc -c -m32 --RTS=32 queuepkg2.adb
gcc -c -m32 --RTS=32 stackpkg2.adb
gnatbind --RTS=32 -x contest.ali
gnatlink contest.ali -m32
/usr/bin/ld: cannot find -lgnat
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/bin/gcc
gnatmake: *** link failed.
This task depends upon

Closed by  Florian Pritz (bluewind)
Saturday, 19 February 2011, 16:59 GMT
Reason for closing:  Fixed
Comment by Brendan (decibelmute) - Monday, 10 January 2011, 04:26 GMT
The missing files, the 32-bit copies of libgnat-4.5.so, libgnarl-4.5.so, libgnat.a, and libgnarl.a, are all properly built when the package is hand compiled from ABS, but they are not properly installed into the package root when the package is created. After makepkg is run, the files are located in the directory:
src/gcc-build/gcc/ada/rts_32/
relative to the PKGBUILD.

Manually copying these libraries into /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/32/ and attempting to compile Ada programs with "gnatmake -m32" results in success, and the output of the "file" command shows that the binaries produced are, in fact, 32-bit.

The step in the PKGBUILD which is *intended* to copy these files into the package root is line 261,
make -j1 -C $CHOST/32/libada DESTDIR=${pkgdir} install-gnatlib
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/32/
Running this step by hand, it seems that a segmentation fault occurs while make attempts to copy these files.

The end result is a file heirarchy identical to the gcc-ada-multilib package given by the command
pacman -Ql gcc-ada-multilib

I've attached the output of the make command given above. Looking at this, it seems that this may in fact be a bug from upstream.
Comment by Jan Alexander Steffens (heftig) - Thursday, 13 January 2011, 23:12 GMT
It looks like it tries to execute the object file. This might indeed be a bug in the Makefile.
Comment by Jan Alexander Steffens (heftig) - Friday, 14 January 2011, 00:27 GMT
Try 4.5.2-4.1, I added a workaround to the package.
Comment by Jan Alexander Steffens (heftig) - Monday, 17 January 2011, 23:00 GMT
Whoops, I forgot to actually release it to the repository. Should be available now.
Comment by Brendan (decibelmute) - Tuesday, 18 January 2011, 08:47 GMT
Thanks for the fix, works like a charm now.
Just wondering though, should this possibly be submitted as a bug upstream?
Having looked at the new PKGBUILD, I can't really tell if this is a bug in the Makefile or if the make command is actually supposed to look like that, Makefiles are sort of a foreign language to me.

Loading...