[PATCH 1/1] udev/pkgconfig: fix exec_prefix to be generated from @exec_prefix@

[PATCH 1/1] udev/pkgconfig: fix exec_prefix to be generated from @exec_prefix@

[Inaky Perez-Gonzalez]

From: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>

Otherwise paths where the libraries are to be found are out of sync.

Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
---
 extras/volume_id/lib/libvolume_id.pc.in |    4 ++--
 udev/lib/libudev.pc.in                  |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/extras/volume_id/lib/libvolume_id.pc.in b/extras/volume_id/lib/libvolume_id.pc.in
index 5a1e1b7..b19cb52 100644
--- a/extras/volume_id/lib/libvolume_id.pc.in
+++ b/extras/volume_id/lib/libvolume_id.pc.in
@@ -1,6 +1,6 @@
 prefix=@prefix@
-exec_prefix=@prefix@
-libdir=@prefix@/@libdir_name@
+exec_prefix=@exec_prefix@
+libdir=@exec_prefix@/@libdir_name@
 includedir=@prefix@/include
 
 Name: libvolume_id
diff --git a/udev/lib/libudev.pc.in b/udev/lib/libudev.pc.in
index 38fc052..428062e 100644
--- a/udev/lib/libudev.pc.in
+++ b/udev/lib/libudev.pc.in
@@ -1,6 +1,6 @@
 prefix=@prefix@
-exec_prefix=@prefix@
-libdir=@prefix@/@libdir_name@
+exec_prefix=@exec_prefix@
+libdir=@exec_prefix@/@libdir_name@
 includedir=@prefix@/include
 
 Name: libudev
-- 
1.5.6.5

Re: [PATCH 1/1] udev/pkgconfig: fix exec_prefix to be generated from

[Kay Sievers]

On Thu, Jan 8, 2009 at 00:08, Inaky Perez-Gonzalez
<inaky@linux.intel.com> wrote:
> From: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
>
> Otherwise paths where the libraries are to be found are out of sync.

Pkgconfig usually points to the development symlink to the .so, not
the real .so, and that should be in prefix, not in exec_prefix. The
fact that the lib lives in the rootfs is hidden by the dynloader, and
not interesting to the user of the library. We did it like your patch
does in the past, but we got a patch to turn that exactly into the way
it is now.

Now we need to find out what to do. :) What exactly fails for you?

Thanks,
Kay

Re: [PATCH 1/1] udev/pkgconfig: fix exec_prefix to be generated

[Marcel Holtmann]

Hi Inaky,

> Otherwise paths where the libraries are to be found are out of sync.

did you check the autogen.sh of udev. With programs living in the /
directory (including their libraries) you have to do special things when
installing them. Here is what udev uses:

--prefix=/usr --exec-prefix= --sysconfdir=/etc --with-selinux

And with that a "make install" words just fine. I have been using it
since the last few month.

Regards

Marcel

RE: [PATCH 1/1] udev/pkgconfig: fix exec_prefix to be generated

[Perez-Gonzalez, Inaky]

>From: Marcel Holtmann [mailto:marcel@holtmann.org]
>
>Hi Inaky,
>
>> Otherwise paths where the libraries are to be found are out of sync.
>
>did you check the autogen.sh of udev. With programs living in the /
>directory (including their libraries) you have to do special things when
>installing them. Here is what udev uses:
>
>--prefix=/usr --exec-prefix= --sysconfdir=/etc --with-selinux
>
>And with that a "make install" words just fine. I have been using it
>since the last few month.

Yeah, all that works ok -- my concern is more the generation of the .pc
file, as they are based off @exec_dir@ and in the pc.in template files,
exec_prefix is taken to be @prefix@, when that could not be the case.

Am I missing anything here?

Re: [PATCH 1/1] udev/pkgconfig: fix exec_prefix to be generated from @exec_prefix@

[Inaky Perez-Gonzalez]

On Wednesday 07 January 2009, Kay Sievers wrote:
> On Thu, Jan 8, 2009 at 00:08, Inaky Perez-Gonzalez
>
> <inaky@linux.intel.com> wrote:
> > From: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
> >
> > Otherwise paths where the libraries are to be found are out of sync.
>
> Pkgconfig usually points to the development symlink to the .so, not
> the real .so, and that should be in prefix, not in exec_prefix. The
> fact that the lib lives in the rootfs is hidden by the dynloader, and
> not interesting to the user of the library. We did it like your patch
> does in the past, but we got a patch to turn that exactly into the way
> it is now.
>
> Now we need to find out what to do. :) What exactly fails for you?

Nothing yet -- it just looked odd/inconsistent to me, I've had similar 
issues in the past. 

If you want, just hold it and I'll try reverting it and see
if the app I have to build against that fails or works and let you
know.

-- 
Inaky

Re: [PATCH 1/1] udev/pkgconfig: fix exec_prefix to be generated from

[Kay Sievers]

On Thu, Jan 8, 2009 at 00:48, Perez-Gonzalez, Inaky
<inaky.perez-gonzalez@intel.com> wrote:
>>From: Marcel Holtmann [mailto:marcel@holtmann.org]
>>> Otherwise paths where the libraries are to be found are out of sync.
>>
>>did you check the autogen.sh of udev. With programs living in the /
>>directory (including their libraries) you have to do special things when
>>installing them. Here is what udev uses:
>>
>>--prefix=/usr --exec-prefix= --sysconfdir=/etc --with-selinux
>>
>>And with that a "make install" words just fine. I have been using it
>>since the last few month.
>
> Yeah, all that works ok -- my concern is more the generation of the .pc
> file, as they are based off @exec_dir@ and in the pc.in template files,
> exec_prefix is taken to be @prefix@, when that could not be the case.
>
> Am I missing anything here?

Udev uses exec_prefix to put the binaries in /sbin and the lib in
/lib{,64}, it can do that because it does not need to put any binary
files in /usr. Stuff installed in the rootfs is kind of special, there
is no general rule how to do that, and standard autotools do not help
anything regarding that problem. Every package has its own way to do
that.

In general, pkgconfig files should not expose the that a library is
installed in the rootfs, pkgconfig must always point to the
development symlink, which is usually installed with the devel
package, and lives in /usr, and is prefix here, not exec_prefix.

We could make exec_prefix show the "real" value, but then we would
need to fake the libdir value to point to /usr, which is the same type
of inconsistency you discovered with today's solution.

Thanks,
Kay

RE: [PATCH 1/1] udev/pkgconfig: fix exec_prefix to be generated

[Marcel Holtmann]

Hi Inaky,

> >> Otherwise paths where the libraries are to be found are out of sync.
> >
> >did you check the autogen.sh of udev. With programs living in the /
> >directory (including their libraries) you have to do special things when
> >installing them. Here is what udev uses:
> >
> >--prefix=/usr --exec-prefix= --sysconfdir=/etc --with-selinux
> >
> >And with that a "make install" words just fine. I have been using it
> >since the last few month.
> 
> Yeah, all that works ok -- my concern is more the generation of the .pc
> file, as they are based off @exec_dir@ and in the pc.in template files,
> exec_prefix is taken to be @prefix@, when that could not be the case.
> 
> Am I missing anything here?

these values are replace at runtime of configure and the end result
looks like this:

prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include

Name: libudev
Description: Library to access udev device information
Version: 136
Libs: -L${libdir} -ludev
Libs.private: 
Cflags: -I${includedir}

And that looks correct to me. What do you expect to happen?

Regards

Marcel

Re: [PATCH 1/1] udev/pkgconfig: fix exec_prefix to be generated from @exec_prefix@

[Inaky Perez-Gonzalez]

On Wednesday 07 January 2009, Kay Sievers wrote:
> On Thu, Jan 8, 2009 at 00:48, Perez-Gonzalez, Inaky
>
> <inaky.perez-gonzalez@intel.com> wrote:
> >>From: Marcel Holtmann [mailto:marcel@holtmann.org]
> >>
> >>> Otherwise paths where the libraries are to be found are out of sync.
> >>
> >>did you check the autogen.sh of udev. With programs living in the /
> >>directory (including their libraries) you have to do special things when
> >>installing them. Here is what udev uses:
> >>
> >>--prefix=/usr --exec-prefix= --sysconfdir=/etc --with-selinux
> >>
> >>And with that a "make install" words just fine. I have been using it
> >>since the last few month.
> >
> > Yeah, all that works ok -- my concern is more the generation of the .pc
> > file, as they are based off @exec_dir@ and in the pc.in template files,
> > exec_prefix is taken to be @prefix@, when that could not be the case.
> >
> > Am I missing anything here?
>
> Udev uses exec_prefix to put the binaries in /sbin and the lib in
> /lib{,64}, it can do that because it does not need to put any binary
> files in /usr. Stuff installed in the rootfs is kind of special, there
> is no general rule how to do that, and standard autotools do not help
> anything regarding that problem. Every package has its own way to do
> that.
>
> In general, pkgconfig files should not expose the that a library is
> installed in the rootfs, pkgconfig must always point to the
> development symlink, which is usually installed with the devel
> package, and lives in /usr, and is prefix here, not exec_prefix.
>
> We could make exec_prefix show the "real" value, but then we would
> need to fake the libdir value to point to /usr, which is the same type
> of inconsistency you discovered with today's solution.

Ah, ok, I see the point now -- I forgot that the bare .so can be 
placed anywhere.

Thank for the explanation

-- 
Inaky