Bug 833 - ADA library would need a symlink to its standard name
Summary: ADA library would need a symlink to its standard name
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2011-04-15 19:20 CEST by Chris Denice
Modified: 2011-04-20 13:54 CEST (History)
1 user (show)

See Also:
Source RPM: gcc-4.5.2-3.mga1.src.rpm
CVE:
Status comment:


Attachments

Description Chris Denice 2011-04-15 19:20:20 CEST
Description of problem:

Hi there,
the provided ADA by library is

/usr/lib64/libgnat-4.5.so.1

and seems to miss a link to its standard name:

libgnat.so

Cheers,
Chris.

Reproducible: 

Steps to Reproduce:
Comment 1 Ahmad Samir 2011-04-16 02:58:31 CEST
What makes you think a link is missing? (building a package, running an app... etc).

FWIW, it's the other way around foo.so is a symlink to foo.so.MAJOR;
$ /usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/adalib
$ ls -l *gnat*so
lrwxrwxrwx 1 root root 37 Apr 15 22:20 libgnat-4.5.so -> ../../../../../lib64/libgnat-4.5.so.1*
lrwxrwxrwx 1 root root 14 Apr 15 22:20 libgnat.so -> libgnat-4.5.so*

/usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/adalib is in the gcc-gnat package
and /usr/lib64/libgnat-4.5.so.1 is in libgnat1.

Keywords: (none) => NEEDINFO

Comment 2 Chris Denice 2011-04-16 10:06:56 CEST
Yep, my sentence was not clear, this is what I meant by the symlink

.so -> -4.5.so

I was trying to compile a soft looking for libgnat.so in /usr/lib64 which is not there, only libgnat-4.5.so.1 is provided by the package libgnat1, and no symlink to it are created. I think they should no?

Now, you tell me I should rather use /usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/adalib/libgnat1.so which is indeed correctly linked to usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/adalib/libgnat-4.5.so 

Fair enough, but what is the purpose of the package libgnat1 then?

Cheers,
Chris.
Ahmad Samir 2011-04-19 08:05:17 CEST

CC: (none) => arnaud.patard

Comment 3 Arnaud Patard 2011-04-19 09:22:21 CEST
I guess you're mixing runtime and buildtime dependency. libgnat.so is the file used by gcc/gnat when building your program but then, once you have built it (say with gnat make <myfile>.adb), what's needed is something different:

$ ldd hello
        linux-vdso.so.1 =>  (0x00007fffe1bff000)
        libgnat-4.5.so.1 => /usr/lib64/libgnat-4.5.so.1 (0x00007fccb1329000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fccb1114000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fccb0da3000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fccb0b21000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fccb1839000)

(hello is a hello world in ada)

hello only needs libgnat-4.5.so.1 which is provided libgnat1. That's why libgnat1 is there. If one wants to package a ada program, the binary package will only require libgnat1 and not the full gcc/gnat stack.
Comment 4 Chris Denice 2011-04-19 10:10:30 CEST
Ok, thanks for the explanation, makes sense.

in fact my pb was not to use gnat/gcc to build a package, I was actually compiling plplot which indeed needs libgnat.so to be built. The pb is that libgnat.so is not in a standard location, so the compilation was failing for this. But I'll just have to specify the gcc directory you mention I guess. Maybe I was just looking for libgnat1-devel, which is in fact gcc itself.

Cheers,
Chris.
Comment 5 Arnaud Patard 2011-04-19 10:51:26 CEST
indeed. cmake failes to find the lib and I'm not seeing any patch in fedora for plplot. Fedora is putting the libgnat.so file in the same place as in Mageia. After a quick look, Fedora is providing a libgnat-4.6.so in /usr/lib and with a libgnat-4.5.so in Mageia symlink, cmake is happy.
So, you may be right, there may be some packaging issue in our gnat/libgnat. I'm looking at it. If you have a plplot src.rpm, can you please put it somewhere (if you have enough rights, in the svn would be nice as we don't have it) so that I can have a test case ?
Comment 6 Chris Denice 2011-04-19 15:22:49 CEST
Yes, that's why I was trying to compile it :) I am working on it. I finally succeeded to compile it by setting this option in cmake

-DGNAT_LIB=:FILEPATH=/usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/adalib/libgnat.so

but I suspect that's not nice because as soon as gcc changes, the spec file will fail. But maybe we have a macro for this? Sorry for the padawan TM question, I just got my first svn uploading teaching lesson this morning (my master is obr_seneca).

The install section suffers from similar pbs, a few ada plplot lib-devel files want to be installed in /usr/lib64/adalib while it looks like they should go
there: /usr/lib/gcc/x86_64-mageia-linux-gnu/4.5.2/adalib/; and the same for fortran devel files.

Actually, maybe a rpm macro would solve this?
Comment 7 Arnaud Patard 2011-04-20 10:00:09 CEST
As I said, there may be a packaging issue, so I've made some test gcc rpms which I hope would make plplot cmake happy. I've made the same behaviour as for RH so I guess it should be fine.

You'll find them at http://www.rtp-net.org/misc/mageia-gcc/ 

Can you remove your -DGNAT_LIB=* from your spec and test if with theses gcc-gnat/libgnat1 packages, you can build plplot rpm ?
Comment 8 Chris Denice 2011-04-20 12:03:48 CEST
Well done, the lib is indeed found by cmake:

<<
FOUND gnat library /usr/lib64/libgnat-4.5.so
>>

thanks!

Chris.
Comment 9 Arnaud Patard 2011-04-20 13:54:47 CEST
great. Fixed gcc has been submitted to the build system so I'm closing the bug.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.