Hi,
On 4/8/25 18:29, Nate Bargmann wrote:
Normally the result is reversed. My observation is that whenever
'--enable-static' is passed the shared libs are suppressed. The
architecture I am using is what Debian calls 'amd64' and other
distributions call 'x86_64-linux-gnu'.
Ah, configure.ac has the answer:
57 AS_IF([test "x$enable_static" = "xyes"], [
58 enable_shared=no
59 ])
60 AS_IF([test "x$enable_static" = "xyes" && test "x$enable_shared" =
"xyes"], [
61 AC_MSG_ERROR([Both --enable-static and --enable-shared cannot
be enabled at the same time.])
62 ])
So they (tried to) explicitly disallow that, but mess it up in the process.
What I would do is do two out-of-tree builds with different configurations:
mkdir -p build/static build/shared
(cd build/static && ../../configure --enable-static --disable-shared)
(cd build/shared && ../../configure --disable-static --enable-shared)
On many systems, both are built with -fPIC now, to allow use of static
libraries in position-independent executables, I'm not sure if libtool
handles this efficiently, but it mostly means longer build time.
Would this be related to why 'i386' and 'x86_64' architectures only
produce one or the other depending on the state of '--enable-static'?
i386 is more lenient than most other architectures -- they can build a
library from objects that weren't compiled with -fPIC. It will be
inefficient, but it will run. Pretty much all other architectures,
including x86_64, are strict about libraries being position-independent
code.
What has changed is that non-library code is now often *also* compiled
as position-independent code, and most distributions ship the compiler
with -fPIC enabled by default. It's possible that i386 gets an exception
here because before the PentiumII, the architecture is so
register-starved that PIC comes with a 5% performance penalty, and for
SDR applications, that is significant, but that is still me guessing.
I'm not that deep into library structure but just reading the libtool
docs makes me wonder if truly different object files are generated for
static versus shared.
Traditionally, it does: shared libraries get -fPIC, static libraries don't.
If you remove the AS_IF statements from configure.ac and rebuild the
configure script, then configure with "--enable-shared --enable-static",
it will build and install both shared and static libraries. On my
(x86_64) machine, the object files (e.g. src/sleep.o and
src/.libs/sleep.o) have the same contents, because -fPIC is now set by
default in the compiler, but these are indeed compiled twice.
My main goal is to provide a technically sound answer as to why both
cannot be built in a single compilation pass on common architectures.
I think only the hamlib maintainer(s) can answer that -- the code that
locks out compiling both at the same time is in the hamlib package, not
in libtool, and probably has a reason behind it because someone made an
effort to write it, but none that is immediately obvious.
I did a very minimal build though, so maybe one of the optional
components requires it -- and if a dependency of an optional component
only exists as a (non-PIC) static library then indeed it will not be
possible to link a shared library against it.
Simon
