[
https://issues.apache.org/jira/browse/XERCESC-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073671#comment-17073671
]
Roger Leigh commented on XERCESC-2176:
--------------------------------------
The CMake logic we have is buggy, and should only be applied to shared
libraries, not static. That aspect should be trivial to change.
The root cause of the problem is that we're trying to match the GNU libtool
versioning *exactly* for strict compatibility, and while CMake itself can
handle library VERSION and SONAME properties perfectly on all supported
platforms, the semantics and library names differ which would make the CMake
build of Xerces-C not be directly substitutable for the Autotools build.
libtool is pretty terrible, and it's SOVERSION versioning support is
nonsensical. Like many projects using libtool, Xerces-C is using libtool's
"-release" option to avoid the worst brokenness:
{noformat}
(libxerces_c_la_LDFLAGS = -release @INTERFACE_VERSION_D@)
{noformat}
which is a shorthand for "encode the release version into the library name as a
suffix", because the real SONAME versioning is so woeful. The behaviour
difference is this:
- libtool produces libxerces-c-3.2.so and a libxerces.so symlink. And also
libxerces-c.so.3 symlink (both useless and nonsensical since we never actually
set a SOVERSION)
- CMake (with VERSION property) produces libxerces-c.so.3.2 and a libxerces.so
symlink
What we're doing right now is making CMake generate "libxerces-c-3.2" as the
library name. But that makes CMake skip symlink generation because we've
avoided using any of the versioning options. So we're creating the symlink
manually. We don't bother with the libxerces-c.so.3 because it doesn't serve
any useful or meaningful purpose in the absence of proper SOVERSION usage.
> Incorrect symbolic links created for Linux static library and MacOS static
> and shared libraries
> -----------------------------------------------------------------------------------------------
>
> Key: XERCESC-2176
> URL: https://issues.apache.org/jira/browse/XERCESC-2176
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
> Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: Linux, MacOS
> Reporter: Brent Davis
> Assignee: Roger Leigh
> Priority: Minor
> Fix For: 3.2.3
>
>
> We build Xerces-C++ for both the Linux and MacOS platforms, with both static
> and shared libraries. There are arguably some dubiously named symbolic links
> created by src/CMakeLists.txt. The symlinks are always named
> 'libxerces-c.so' regardless or library type, or use of the .dylib extension
> on MacOS.
> ||Platform||Library Type||Symbolic Link||Comment||
> |{color:#de350b}Linux{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#00875a}
> {color}|{color:#00875a}shared{color}|{color:#00875a}libxerces-c.so ->
> libxerces-c-3.2.so{color}|{color:#00875a}good{color}|
> |{color:#de350b}MacOS{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#de350b}
> {color}|{color:#de350b}shared{color}|{color:#de350b}libxerces-c.so ->
> libxerces-c-3.2.dylib{color}|{color:#de350b}symbolic link should best be
> named libxerces-c.dylib{color}|
> Curiously, the Microsoft _vcpkg_ folks just recently ran into the Linux
> static library portion of this issue and elected to not create the symlink in
> that case. See [[xerces-c] produces strange files in
> installed/x64-linux/lib|[https://github.com/microsoft/vcpkg/issues/7490]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
