Support CMake's BUILD_SHARED_LIBS flag

[orlitzky]

Currently both shared and static libraries are built via duplicate calls to add_library(), set_target_properties(), target_link_libraries(), etc. Typically only one of these is desired, and CMake provides a BUILD_SHARED_LIBS variable to control it.

We noticed this on Gentoo where BUILD_SHARED_LIBS=ON is passed by default, but static libraries were still installed.

This commit removes the explicit static libraries, and then removes the explicit "SHARED" from the remaining add_library(). The end result is that one type of library is installed, and it is controlled by the BUILD_SHARED_LIBS flag.

To build static libraries rather than shared ones, you would now use cmake -DBUILD_SHARED_LIBS=OFF .... A little more annoying if you want static libs, but it is the standard way of doing it.

[robertlipe]

Please investigate and correct the build failures so this can be considered or withdraw it back to draft status until you can do so.

[orlitzky]

The two linux failures look like missing -lm in the bundled argtable3:

2026-09-08T04:21:12.1926686Z /usr/bin/arm-linux-gnueabihf-ld.bfd: argtable3/src/libargtable3.so.0.0.0: undefined reference to `ceil'
2026-09-08T04:21:12.2053179Z collect2: error: ld returned 1 exit status
2026-09-08T04:21:12.2235923Z gmake[2]: *** [tools/blisp/CMakeFiles/blisp.dir/build.make:168: tools/blisp/blisp] Error 1

It looks like the build script is pulling argtable3 directly from git... I'm going to revert the change and force-push to see if this has anything to do with this PR.

[orlitzky]

More digging: the pkg-config file installed by argtable3 includes...

Libs: -L${libdir} -l@PROJECT_NAME@ -lm

which will get used when BLISP_USE_SYSTEM_LIBRARIES=ON because find_package(Argtable3) will pick it up. But when building the bundled copy, the -lm is not added.

[orlitzky]

The last push tries adding -lm manually when building the bundled argtable3. I think the standards require -lm to be supported by the compiler whether it does anything or not, so hopefully adding it does not cause any new problems.

[orlitzky]

Same error somehow. I added --verbose to the cmake --build commands on the CI so that we can see if -lm is being added at least.

[orlitzky]

When built with the bundled libs, the very last step should be to link blisp with an -lm:

$ cmake -DCMAKE_BUILD_TYPE=Release -DBLISP_BUILD_CLI=ON -DCOMPILE_TESTS=OFF -S . -B build
...
$ cmake --build build/ --verbose --clean-first
...
[100%] Linking C executable blisp
cd /home/mjo/src/blisp.git/build/tools/blisp && /usr/bin/cmake -E cmake_link_script CMakeFiles/blisp.dir/link.txt --verbose=1
/usr/bin/cc -O3 -pipe -mabi=lp64d -march=rv64gc -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -flto=auto -O3 -DNDEBUG -Wl,-O1 -Wl,--as-needed -Wl,--dependency-file=CMakeFiles/blisp.dir/link.d CMakeFiles/blisp.dir/src/main.c.o CMakeFiles/blisp.dir/src/cmd/write.c.o CMakeFiles/blisp.dir/src/util.c.o CMakeFiles/blisp.dir/src/common.c.o CMakeFiles/blisp.dir/src/cmd/iot.c.o -o blisp  -Wl,-rpath,/home/mjo/src/blisp.git/build/tools/blisp/argtable3/src:/home/mjo/src/blisp.git/build: -lm argtable3/src/libargtable3.so.0.0.0 ../../libblisp.so.0.0.5 src/file_parsers/libfile_parsers.a
gmake[2]: Leaving directory '/home/mjo/src/blisp.git/build'
[100%] Built target blisp

(it's easy to miss, but the -lm is there)

[orlitzky]

It's including the -lm, but doing it too soon:

2026-09-14T23:35:24.6653525Z /usr/bin/cc -Wl,--dependency-file=CMakeFiles/blisp.dir/link.d CMakeFiles/blisp.dir/src/main.c.o CMakeFiles/blisp.dir/src/cmd/write.c.o CMakeFiles/blisp.dir/src/util.c.o CMakeFiles/blisp.dir/src/common.c.o CMakeFiles/blisp.dir/src/cmd/iot.c.o -o blisp  -Wl,-rpath,/home/runner/work/blisp/blisp/build/tools/blisp/argtable3/src:/home/runner/work/blisp/blisp/build: -lm argtable3/src/libargtable3.so.0.0.0 ../../libblisp.so.0.0.5 src/file_parsers/libfile_parsers.a
2026-09-14T23:35:24.6658009Z gmake[2]: *** [tools/blisp/CMakeFiles/blisp.dir/build.make:168: tools/blisp/blisp] Error 1

Since the bundled argtable3/src/libargtable3.so.0.0.0 is what needs -lm, the -lm has to come after that. I appreciate your persistence but my enthusiasm for guessing is running out. We're only interested in using argtable3 from the system where it works nicely. I'll just keep the patch for now.