Which advantages does this design bring to the table?
- Header files are execline/*.h, it's logical to put static library
files in execline/*.a
- /lib and /usr/lib are places where the dynamic linker looks for
shared libraries. Despite sharing the name "library", static and shared
libraries are not at all the same kind of object, they're not used for
the same purpose (shared libraries are run-time, static libraries are
build-time), so they should not be put in the same places. It is a
design mistake of a linker to look for static libraries in /lib and
/usr/lib, and a historical mistake of FHS not to have specified a
different default place for static libraries.
- /usr/lib/foobar is traditionally used to host other files that are
related to the foobar package, such as unexported executable files
("libexec") or other read-only data. It is a naturally appropriate place
to put static libraries from the foobar package.
Using /usr/lib/foobar as the default place to put libfoobar.a was my
attempt to organize files more rationally than FHS does and ld
encourages, but unfortunately people don't read INSTALL files or
./configure --help carefully (:P) and they're surprised when things
deviate ever so slightly from the lemming herd of all the autoconf-using
software - you're neither the first one to have trouble with this, nor
the last one.
I guess it's my bad for pushing policy instead of sticking to
mechanism.
I'll change the default in future versions of skarnet.org packages.
Why do some versions can compile without changes and some can't?
It's not the case.
If you previously managed to build skarnet.org software without
specifying --libdir=/usr/lib or --with-lib=/usr/lib/foobar, then
chances are you already had an old version of libfoobar.a installed in
/usr/lib/foobar (and linked against it), or you specified
--disable-allstatic and linked against libfoobar.so (which is in /lib
or /usr/lib). In the latter case, your build is correct; but in the
former, it accidentally succeeded and you didn't use the version of
libfoobar that you were aiming for.
Which is, to me, a much bigger problem than hitting a build-time error.
I don't know how many incorrect builds have accidentally passed and are
currently running out there; this is reason enough to change the
default.
--
Laurent
