gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] libgfapi.so rpm location?


From: Kaleb S. KEITHLEY
Subject: Re: [Gluster-devel] libgfapi.so rpm location?
Date: Mon, 17 Feb 2014 17:20:44 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

On 02/17/2014 05:07 PM, Justin Clift wrote:
Hi Kaleb,

Just noticed a small weirdness with the GlusterFS rpms generated from
from git master head.

In glusterfs-api rpm:

  * /usr/lib64/libgfapi.so.6
  * /usr/lib64/libgfapi.so.6.0.0

In glusterfs-api-devel rpm:

  * /usr/lib64/libgfapi.so

They should all be in the glusterfs-api rpm shouldn't they?

Nope. This is ELF sharedlib juju.

At compile time the linker looks for libfoo.so. It reads the SO_NAME, which is libfoo.so.x (or libfoo.so.x.y.z), from libfoo.so (which is just a symlink to libfoo.so.x); Later, at run-time, the dyld loads libfoo.so.x.

RPM's packaging rules say that libfoo.so.x (and libfoo.so.x.y.z) belong in the foo.rpm, but the libfoo.so symlink belongs in the foo-devel.rpm.

IOW a run-time only install only needs libfoo.so.x or libfoo.so.x.y.z.

A developer who wants to link with the lib needs the -devel rpm with libfoo.so.

The purist packagers like this because it keeps the file system from being filled with lib*.so symlinks that aren't needed except by developers.

Debian/Ubuntu-style dpkg has similar rules for their -dev dpkgs.


If so, I can include the fix in my Glupy rename patch, as it's
already moving a few things around for the API rpms.

Regards and best wishes,

Justin Clift

--
Open Source and Standards @ Red Hat

twitter.com/realjustinclift


--

Kaleb



reply via email to

[Prev in Thread] Current Thread [Next in Thread]