>From: "Hundstad, Jeffrey E." <jeffrey.hundstad@xxxxxxxx>
>In http://marc.theaimsgroup.com/?l=linux-xfs&m=99780529714933&w=2 and http://m
>arc.theaimsgroup.com/?l=linux-xfs&m=99784007628575&w=2 in Aug, 2001 there is a
> reference to a problem with linking when configuring with --enable-shared=no.
> This problem still exists.
>
>If I modify include/builddefs.in in acl, attr and xfsprogs to change all insta
>nces of "lai" to "la" the "make install-dev" works to installs the libraries.
> You still have to manually link all of the binaries. For example:
>
>gcc -o chacl chacl.o ../libacl/.libs/libacl.al /usr/lib/libattr.al
>
>It looks like the makefiles are a bit munged up... but it also looks like a si
>mple fix. If the ".al" files were ".a" files then the linker would be able to
> find them with "-l attr" like the makefile now reads.
The makefiles in the acl and attr dirs were changed recently to add the
install-lib goal, and this is missing a part (INSTALL_LTLIB is not defined in
static-only builds) for static-only builds. However, that's not surprising
because . . .
We also need to update the steps in the INSTALL_LTLIB_STATIC variable, to find
the libtool lib file (the text file). Libtool doesn't give us a .lai file for
static builds. Apparently we've never had this working.
I'm going to leave the first problem for Nathan, because he accepted the
install-lib patch :) and I figure the second can be cleaned up in the same
fix....ah, delegation.
To recap a libtool build, here's what you see. This is what you have to work
with:
static-only, you get:
libattr/libattr.la - libtool lib file (shell variables)
libattr/.libs/libattr.al - ar archive
libattr/.libs/libattr.la - symlink to the libtool lib file
And dynamic&static you get:
libattr/libattr.la - libtool lib file
libattr/.libs/libattr.a - ar archive
libattr/.libs/libattr.la - symlink to above libtool lib file
libattr/.libs/libattr.lai - copy of libtool lib file
libattr/.libs/libattr.so*
We probably keyed off the .lai suffix in builddefs.in because libtool was
doing that. I don't remember, and it's too painful to go back and try it.
We've never had a use for a static-only build, so it's not surprising we
overlooked this. The shared libs are the reason that we went with the libtool
build--we needed those. Then we couldn't use libtool for the install stage
because it doesn't have the concept of a runtime install versus a development
install (attr-<vers>.rpm vs. attr-devel-<vers>.rpm).
Personally, I think the libtool developers were on drugs.
>The reason I started down the statically linked road in the first place was
>because the "autoconf;./configure;make;make install;make install-dev" fails to
>produce binaries and libraries, and does produce errors. So as far as I can
>tell you have to munge the build in any case.
Well, you weren't accurate here. It does produce binaries and libraries--you
just overlooked the step to install the libraries. This, no doubt, is what
you saw, and what you should have included in your mail:
$ /usr/bin/attr
/usr/bin/attr: error while loading shared libraries:
libattr.so.1: cannot load shared object file: No such file or directory
Dean
|