Re: --enable-shared=no gives linking errors Was: New tarball error

[Dean Roehrich <roehrich@sgi.com>]

>From:  "Hundstad, Jeffrey E." <jeffrey.hundstad@mnsu.edu>
>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