xfs
[Top] [All Lists]

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

To: <linux-xfs@xxxxxxxxxxx>, "Nathan Scott" <nathans@xxxxxxx>, "Vincent Bernat" <bernat@xxxxxxx>
Subject: --enable-shared=no gives linking errors Was: New tarball error
From: "Hundstad, Jeffrey E." <jeffrey.hundstad@xxxxxxxx>
Date: Tue, 19 Mar 2002 16:17:15 -0600
Sender: owner-linux-xfs@xxxxxxxxxxx
Thread-index: AcHPkhaIiz8w5npdSUmvt+wLkI3bbQ==
Thread-topic: --enable-shared=no gives linking errors Was: New tarball error
In http://marc.theaimsgroup.com/?l=linux-xfs&m=99780529714933&w=2 and 
http://marc.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 
instances 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 
simple 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 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.

BTW: I do have a working set of kernel-libraries-binaries now so there isn't 
any emergency for me.... but for newer members of the XFS community this may be 
a real sticking point.

-- 
Jeffrey Hundstad
P.S. I apologize for the mime-stupidity of this message.




<Prev in Thread] Current Thread [Next in Thread>