FS#72726 - [antlr4-runtime] Missing static library breaks CMake config file

Attached to Project: Community Packages
Opened by Tobias Markus (netcrusher) - Friday, 12 November 2021, 15:16 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:02 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Christian Hesse (eworm)
Konstantin Gizdov (kgizdov)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
The antlr4-runtime CMake build system defaults to building and installing both a static and a shared version of the runtime (targets antlr4-shared and antlr4-static in CMake). The exported CMake config files (antlr4-targets.cmake and antlr4-targets-release.cmake in /usr/lib/cmake/antlr4-runtime) also include the static target antlr4-static. However, makepkg automatically removes static libraries, resulting in a package that mentions the static version in the CMake config script while the static library does not actually exist in the final package.

This situation in turn breaks the CMake scripts since they check whether the exported targets are actually present. Example output:

CMake Error at /usr/lib64/cmake/antlr4-runtime/antlr4-targets.cmake:82 (message):
The imported target "antlr4_static" references the file

"/usr/lib/libantlr4-runtime.a"

but this file does not exist. Possible reasons include:

* The file was deleted, renamed, or moved to another location.

* An install or uninstall procedure did not complete successfully.

* The installation package was faulty and contained

"/usr/lib64/cmake/antlr4-runtime/antlr4-targets.cmake"

but not all the files it references.

Call Stack (most recent call first):
/usr/lib64/cmake/antlr4-runtime/antlr4-runtime-config.cmake:42 (include)
CMakeLists.txt:34 (find_package)


-- Configuring incomplete, errors occurred!

In this case, reason number 3 obviously applies.

I could also reproduce the cause of the issue by building the PKGBUILD locally and observing that CMake installs libantlr4-runtime.a to the pkg directory, but makepkg removes it.

Additional info:
* Package Version: antlr4-runtime 4.9.3

Steps to reproduce:
1. Install antlr4-runtime
2. Observe that /usr/lib/libantlr4-runtime.a does not exist:

$ ls /usr/lib/libantlr4-runtime.a
ls: cannot access '/usr/lib/libantlr4-runtime.a': No such file or directory

3. Observe that antlr4_static (/usr/lib/libantlr4-runtime.a) is mentioned in CMake target export files:

$ grep -rn antlr4_static /usr/lib/cmake/antlr4-runtime
/usr/lib/cmake/antlr4-runtime/antlr4-targets-release.cmake:19:# Import target "antlr4_static" for configuration "Release"
/usr/lib/cmake/antlr4-runtime/antlr4-targets-release.cmake:20:set_property(TARGET antlr4_static APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
/usr/lib/cmake/antlr4-runtime/antlr4-targets-release.cmake:21:set_target_properties(antlr4_static PROPERTIES
/usr/lib/cmake/antlr4-runtime/antlr4-targets-release.cmake:27:list(APPEND _IMPORT_CHECK_TARGETS antlr4_static )
/usr/lib/cmake/antlr4-runtime/antlr4-targets-release.cmake:28:list(APPEND _IMPORT_CHECK_FILES_FOR_antlr4_static "${_IMPORT_PREFIX}/lib/libantlr4-runtime.a" )
/usr/lib/cmake/antlr4-runtime/antlr4-targets.cmake:19:foreach(_expectedTarget antlr4_shared antlr4_static)
/usr/lib/cmake/antlr4-runtime/antlr4-targets.cmake:65:# Create imported target antlr4_static
/usr/lib/cmake/antlr4-runtime/antlr4-targets.cmake:66:add_library(antlr4_static STATIC IMPORTED)

4. Observe that "find_package(antlr4-runtime)" in CMake scripts fails (see example above)
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:02 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/antlr4-runtime/issues/ 1
Comment by Konstantin Gizdov (kgizdov) - Friday, 12 November 2021, 17:41 GMT
By default, I think makepkg removes static librarties. And it also seems like there is no simple way of not including it. I will push a package to include it until we decide how to handle at least to fix the repo package. @eworm, do you have a preference on what to do about this?
Comment by Konstantin Gizdov (kgizdov) - Friday, 12 November 2021, 17:42 GMT
community/antlr4-runtime 4.9.3-2 has the static lib in it now.
Comment by Christian Hesse (eworm) - Friday, 26 November 2021, 13:09 GMT
I vote for not including static libraries if possible. Static linking is a mess where no one knows what, when and why to rebuild.
So if it is possible easily let's drop the static library and adjust the cmake files accordingly.
Comment by Konstantin Gizdov (kgizdov) - Friday, 26 November 2021, 14:16 GMT
I've tried to pass a bunch of flags, but nothing has worked. We probably need to patch their CMake.
Comment by Konstantin Gizdov (kgizdov) - Monday, 14 March 2022, 15:02 GMT
From their extensive docs on the matter, I believe they see the static lib as a major component of the way they support and distribute the C++ runtime, so I think we should leave it in.
Comment by Daniel Jewell (danieljewell) - Tuesday, 06 September 2022, 22:58 GMT
While I do see Christian's (eworm)'s point about static libraries, I do have a couple of comments.

1. Linking a static binary (which comes with it's own downsides and issues) makes it so you _NEVER_ have to rebuild a binary because a shared library has changed. This is the approach taken by languages like Go and Rust. While the upside of this is that _all_ of the code needed to run a binary is present *inside* of that binary file (e.g. absolutely zero external binary dependencies) -- the downsides are pretty bad (in general, absolutely _huge_ binary sizes, a general inability to take advantage of the ability of SOs to be loaded into memory once and *shared*, etc.)

2. There are some *really good* use cases for static binaries ... if you want to compile something once and then have it work (1) pretty much forever (2) on as many systems as possible (this is _especially_ true in the Linux world where various distros have *wildly* different combinations of glibc, etc.), (3) without having to be in dependency/DLL/SO hell, and (4) not having to worry about recompiling or your program breaking if the distro updates/changes a library (Arch is a common example of this).... Then a static binary can be really good.

I will probably see about a thread/issue/task for makepkg -- but I can definitely say that not having the *option* to have the static library available is a major issue that probably breaks way more stuff than just this one. It also makes it kinda impossible to use Arch to compile a static binary for use elsewhere.

Edit: It appears that makepkg does allow for keeping static libs... from this https://bugs.archlinux.org/task/58150 -- just tested it with the xz official package (to get liblzma.a) and it worked!

options=("staticlibs")

Loading...