udev 130 minor incongruity

udev 130 minor incongruity

[Kyle Sallee]

# ./configure --build=$BUILD --sysconfdir=/etc --prefix=/usr --exec-prefix=/
# make
# make install

# grep libdir= /usr/lib/pkgconfig/libudev.pc
libdir=/usr/lib


However,

# ls {,/usr}/lib*/libudev*
/lib/libudev.so.0      /lib.sav/libudev.so.0      /usr/lib/libudev.so
/lib/libudev.so.0.0.2


Therefore,

/usr/lib/pkgconfig/libudev.pc
/usr/lib/pkgconfig/libvolume_id.pc

appear to have incorrect libdir
However, the incongruity will probably not cause problems.

Thanks for creating and updating udev

Re: udev 130 minor incongruity

[Kay Sievers]

On Thu, Oct 16, 2008 at 12:18 AM, Kyle Sallee <kyle.sallee@gmail.com> wrote:
> # ./configure --build=$BUILD --sysconfdir=/etc --prefix=/usr --exec-prefix=/
> # make
> # make install
>
> # grep libdir= /usr/lib/pkgconfig/libudev.pc
> libdir=/usr/lib
>
> However,
>
> # ls {,/usr}/lib*/libudev*
> /lib/libudev.so.0      /lib.sav/libudev.so.0      /usr/lib/libudev.so
> /lib/libudev.so.0.0.2
>
> Therefore,
>
> /usr/lib/pkgconfig/libudev.pc
> /usr/lib/pkgconfig/libvolume_id.pc
>
> appear to have incorrect libdir>
> However, the incongruity will probably not cause problems.

It's correct, libdir= in pkgconfig files always needs to point to the
*.so file, which does _not_ have the version number appended.

The unversioned file (our symlink to the lib object in the root
filesystem) is not used at runtime, only for development. For that
reason it is placed in /usr, where the headers and development tools
are, and the pkgconfig file tells where it can be found.

That the dynamic linker finds the library object in the root
filesystem, does not matter for development, it's a fact that should
not be exposed.

Thanks,
Kay

Re: udev 130 minor incongruity

[David Zeuthen]

On Thu, 2008-10-16 at 08:16 +0200, Kay Sievers wrote:
> The unversioned file (our symlink to the lib object in the root
> filesystem) is not used at runtime, only for development. For that
> reason it is placed in /usr, where the headers and development tools
> are, and the pkgconfig file tells where it can be found.

Both glibc and glib2 does the same (at least on Fedora). The former
via ./configure (you need to set --slibdir=/lib there), the latter via
the Fedora spec file. FWIW, I want to teach glib2 about --slibdir too
since an increasing number of distros opt to ship the glib2 runtime
libraries in /lib instead of /usr/lib. Maybe udev could do something
similar, I don't know.

      David

Re: udev 130 minor incongruity

[Kay Sievers]

On Thu, Oct 16, 2008 at 4:42 PM, David Zeuthen <david@fubar.dk> wrote:
> On Thu, 2008-10-16 at 08:16 +0200, Kay Sievers wrote:
>> The unversioned file (our symlink to the lib object in the root
>> filesystem) is not used at runtime, only for development. For that
>> reason it is placed in /usr, where the headers and development tools
>> are, and the pkgconfig file tells where it can be found.
>
> Both glibc and glib2 does the same (at least on Fedora). The former
> via ./configure (you need to set --slibdir=/lib there), the latter via
> the Fedora spec file. FWIW, I want to teach glib2 about --slibdir too
> since an increasing number of distros opt to ship the glib2 runtime
> libraries in /lib instead of /usr/lib. Maybe udev could do something
> similar, I don't know.

You mean we should introduce a: --slibdir=/lib option, instead of
using --prefix=/usr --exec-prefix=""?

Kay

Re: udev 130 minor incongruity

[David Zeuthen]

On Thu, 2008-10-16 at 17:03 +0200, Kay Sievers wrote:
> You mean we should introduce a: --slibdir=/lib option, instead of
> using --prefix=/usr --exec-prefix=""?

Yeah, I think so. Wouldn't it be more logical? I guess, what I'm saying
is that it would be useful if no options was needed for configure for
the default use (building packages and hacking on an udev version that
overwrites package supplied files). So in that case you'd default
--slibdir to /lib, --sbindir to /sbin and --prefix to /usr. I don't
know, maybe it's fine as is.

      David

Re: udev 130 minor incongruity

[Kay Sievers]

On Thu, Oct 16, 2008 at 8:27 PM, David Zeuthen <david@fubar.dk> wrote:
> On Thu, 2008-10-16 at 17:03 +0200, Kay Sievers wrote:
>> You mean we should introduce a: --slibdir=/lib option, instead of
>> using --prefix=/usr --exec-prefix=""?
>
> Yeah, I think so. Wouldn't it be more logical?

He, the --exec-prefix="" thing works fine for udev, because it has no
binaries in /usr. :) That's not a generally useful approach for
others.

> I guess, what I'm saying
> is that it would be useful if no options was needed for configure for
> the default use (building packages and hacking on an udev version that
> overwrites package supplied files).

That we could do today already with setting the defaults to
--prefix=/usr and --exec-prefix=.

> So in that case you'd default
> --slibdir to /lib, --sbindir to /sbin and --prefix to /usr.

Sure, sounds fine to have a set of common options to support
installing stuff in the rootfs.

> I don't know, maybe it's fine as is.

Yeah, we will see. Would be nice to have a common way to do it. Let me
know how the glib stuff works out.

Other things with "no options needed" are: the multilib lib/lib64
problem, the split of development files in stuff for /usr and the
rootfs, support to compute relative symlinks from /usr/lib/libfoo.so
-> ../../lib/libfoo.so.0.0.0. All that would be nice, so we can just
install stuff from the source tree, without depending on spec file
scripts.

Kay

Re: udev 130 minor incongruity

[Dan Nicholson]

On Thu, Oct 16, 2008 at 5:00 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Oct 16, 2008 at 8:27 PM, David Zeuthen <david@fubar.dk> wrote:
>> On Thu, 2008-10-16 at 17:03 +0200, Kay Sievers wrote:
>>> You mean we should introduce a: --slibdir=/lib option, instead of
>>> using --prefix=/usr --exec-prefix=""?
>>
>> Yeah, I think so. Wouldn't it be more logical?
>
> He, the --exec-prefix="" thing works fine for udev, because it has no
> binaries in /usr. :) That's not a generally useful approach for
> others.
>
>> I guess, what I'm saying
>> is that it would be useful if no options was needed for configure for
>> the default use (building packages and hacking on an udev version that
>> overwrites package supplied files).
>
> That we could do today already with setting the defaults to
> --prefix=/usr and --exec-prefix=.

Just in case you're wondering how to detect this:

AC_PREFIX_DEFAULT([/usr])
test "$prefix" = NONE && test "$exec_prefix" = NONE && exec_prefix
Then if I said, --prefix=/just/testing, $exec_prefix will follow like
it normally would.

--
Dan

Re: udev 130 minor incongruity

[Kay Sievers]

On Fri, Oct 17, 2008 at 01:15, Dan Nicholson <dbn.lists@gmail.com> wrote:
> On Thu, Oct 16, 2008 at 5:00 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Thu, Oct 16, 2008 at 8:27 PM, David Zeuthen <david@fubar.dk> wrote:
>>> On Thu, 2008-10-16 at 17:03 +0200, Kay Sievers wrote:
>>>> You mean we should introduce a: --slibdir=/lib option, instead of
>>>> using --prefix=/usr --exec-prefix=""?
>>>
>>> Yeah, I think so. Wouldn't it be more logical?
>>
>> He, the --exec-prefix="" thing works fine for udev, because it has no
>> binaries in /usr. :) That's not a generally useful approach for
>> others.
>>
>>> I guess, what I'm saying
>>> is that it would be useful if no options was needed for configure for
>>> the default use (building packages and hacking on an udev version that
>>> overwrites package supplied files).
>>
>> That we could do today already with setting the defaults to
>> --prefix=/usr and --exec-prefix=.
>
> Just in case you're wondering how to detect this:
>
> AC_PREFIX_DEFAULT([/usr])
> test "$prefix" = NONE && test "$exec_prefix" = NONE && exec_prefix>
> Then if I said, --prefix=/just/testing, $exec_prefix will follow like
> it normally would.

Sounds good. I added that.

Thanks,
Kay