You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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.
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):
lib60870/lib60870-C/src/CMakeLists.txt
Line 127 in 63481bd
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
toLDFLAGS="-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.
The text was updated successfully, but these errors were encountered: