Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

liblib60870 CMake OUTPUT_NAME #126

Open
ALTracer opened this issue Sep 21, 2022 · 0 comments
Open

liblib60870 CMake OUTPUT_NAME #126

ALTracer opened this issue Sep 21, 2022 · 0 comments

Comments

@ALTracer
Copy link

Summary

CMakeLists.txt disagree with static Makefiles on the library file name.

Makefile compiles a lib60870.a static archive and a lib60870.so dynamic shared library.
CMake creates incorrect liblib60870.a and liblib60870.so.2.3.1 with a symlink named liblib60870.so because of this line (for lib60870-shared cmake target):

OUTPUT_NAME lib60870

Affected

Everybody who was using cmake to build this library and/or link with it, e.g. applications with a dependency on this, and maybe Yocto-based embedded distros package maintainers. Static makefiles work fine.

Suggested changes

I suggest a couple changes to CMakeLists to follow Makefile behaviour.
I think this library was named libiec60870 once, then something was renamed iec60870->lib60870 in commit 6b70099 in 2018 for v2.0.0 release.
liblib60870 is confusing.

This change allows me to build CPack DEB packages for both Ubuntu 18.04 amd64 host "lib60870-C_2.3.1_x86_64.deb" and OpenSTLinux 3.0.0 armhf target (STM32MP157) "lib60870-C_2.3.1_cortexa7t2hf-neon-vfpv4-ostl.deb" with corresponding correct library names and architectures; also I can rely on the naming convention for dynamic linking in application development (compare -liec61850 and -l60870 to LDFLAGS="-llib60870"). Tested build with CMake 3.10.2, the examples launch, although they got linked statically.

The pkgconfig file added in #116 might need to get updated too, I didn't have to use it because a) the target doesn't have a native compiler; b) the host's build system doesn't rely on lib60870.pc (yet). But it would be nice to be able to find the library via CMake+PkgConfig in an upstream application, I did something like this against libiec61850.

If we reach a consensus on this breaking change, I might create a pull request for CI testing.

diff --git a/lib60870-C/src/CMakeLists.txt b/lib60870-C/src/CMakeLists.txt
index e66dd1b..b9dc601 100644
--- a/lib60870-C/src/CMakeLists.txt
+++ b/lib60870-C/src/CMakeLists.txt
@@ -115,7 +115,7 @@ endif( WIN32 )
 add_library (lib60870-shared SHARED ${library_SRCS} )
 
 set_target_properties(lib60870-shared PROPERTIES
-           OUTPUT_NAME lib60870
+           OUTPUT_NAME 60870
            SOVERSION "${LIB_VERSION_MAJOR}.${LIB_VERSION_MINOR}.${LIB_VERSION_PATCH}"
           WINDOWS_EXPORT_ALL_SYMBOLS true
 )
@@ -130,6 +130,10 @@ GENERATE_EXPORT_HEADER(lib60870-shared
 
 add_library (lib60870 STATIC ${library_SRCS})
 
+set_target_properties(lib60870 PROPERTIES
+           OUTPUT_NAME 60870
+)
+
 IF(UNIX)
   IF (CONFIG_SYSTEM_HAS_CLOCK_GETTIME)
      target_link_libraries (lib60870
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant