* On 2025 08 Apr 07:06 -0500, Simon Richter wrote: > 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.
Well... That was hiding in plain sight. This is sort of embarrassing as I've done a lot of work in that file and have been on a bit of a hiatus the past five years and missed that was added in. The former maintainer passed away about ten days ago and I'm stepping back in to help keep the project moving. You gave me a great pointer to investigate and I just simply missed that. I'll have to do some research to see what he was solving. > 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) That will be my recommendation when I discover the reason that section was put into 'configure.ac'/ > > > 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. Thanks very much for this excellent explanation, Simon. I've been somewhat involved in the Hamlib project for the past five years owing to another obligation I was given back then, but much less than in the years prior. I still performed the releases and managed the mailing list, etc. I have since become comfortable enough in that new role that it isn't claiming the attention it was back then so I have some time to step back into the Hamlib project. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
signature.asc
Description: PGP signature
