On Thu, May 31, 2012 at 09:13:08PM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> 
> > libtool: link: `/usr/lib64/libudev.la' is not a valid libtool
> > archive
> 
> libtool is a (long) shell script generated with configure.  I found that 
> phrase in 10 different places.  Can you instrument it and see what is 
> causing it to reject the file?
> 
 I only found 9 in this version, and it was the fifth of those:

        # Check to see that this really is a libtool archive.
        echo "libtool: fifth test"
        func_lalib_unsafe_p "$lib" \
          || func_fatal_error "\`$lib' is not a valid libtool archive"

        func_dirname "$lib" "" "."
        ladir="$func_dirname_result"

 The function is:

# func_lalib_unsafe_p file
# True iff FILE is a libtool `.la' library or `.lo' object file.
# This function implements the same check as func_lalib_p without
# resorting to external programs.  To this end, it redirects stdin
# and
# closes it afterwards, without saving the original file descriptor.
# As a safety measure, use it only where a negative result would be
# fatal anyway.  Works if `file' does not exist.
func_lalib_unsafe_p ()
{
    lalib_p=no
    if test -f "$1" && test -r "$1" && exec 5<&0 <"$1"; then
        for lalib_p_l in 1 2 3 4
        do
            read lalib_p_line
            case "$lalib_p_line" in
                \#\ Generated\ by\ *$PACKAGE* ) lalib_p=yes; break;;
            esac
        done
        exec 0<&5 5<&-
    fi
    test "$lalib_p" = yes
}

 And your .la is missing the 'Generated'
root@ac4tv /usr/src/xorg-server-1.12.1$ grep Generated
/usr/lib/libudev.la 
root@ac4tv /usr/src/xorg-server-1.12.1$ 

 from udev-182 on the host:

ken@ac4tv ~ $grep Generated /usr/lib/libudev.la 
# Generated by libtool (GNU libtool) 2.4.2
ken@ac4tv ~ $

 It's the second line of the file:

root@ac4tv /home/ken #diff {,/mnt/lfs}/usr/lib/libudev.la
2c2
< # Generated by libtool (GNU libtool) 2.4.2
---
> # Custom file by LFS
8c8
< dlname='libudev.so.0'
---
> dlname='libudev.so.1'
11c11
< library_names='libudev.so.0.13.1 libudev.so.0 libudev.so'
---
> library_names='libudev.so.1.0.0 libudev.so.1 libudev.so'
26,28c26,28
< current=13
< age=13
< revision=1
---
> current=1
> age=0
> revision=0
41a42
>  

 Looks as if that 'Custom file by LFS' isn't permitted.

 The difference from Mesa is that Mesa used -ludev but this version
of xorg-server is using libtool for the heavy lifting.

 I've edited /usr/lib/libtool.la to start with the following:
# libudev.la - a libtool library file
# Generated by libtool
# Custom file by LFS

 That is good enough to get past that first problem (probably better
if Custom file was replaced by something to clarify it's not really
from libtool), but it then fails the same way that my attempt to use
the .so file (by hiding the .la) did:

/usr/lib/libudev.so: undefined reference to `mkdir_parents'
/usr/lib/libudev.so: undefined reference to `startswith'
collect2: error: ld returned 1 exit status

 The startswith library function seems to be part of the systemd
library infrastructure:

commit 33502ffe2eb7b56cdd018a4fb6830d7828519fad
Author: Kay Sievers <k...@vrfy.org>
Date:   Mon Apr 16 20:27:44 2012 +0200

    udev: use startswith() and streq()

  So probably more of the systemd libraries are needed to provide
these functions.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to