View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003470CMakeCMakepublic2006-07-02 12:472008-09-22 11:10
ReporterMarc Espie 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003470: incorrect detection of shared libraries on OpenBSD
DescriptionThe cmake framework currently only allows for shared library ending in a fixed suffix.

This does not work at all on OpenBSD: we still use the old SunOS naming convention, and thus the shared libraries have names like:
libc.so.39.0

The kwsys framework does not appear to support this kind of thing.

I suggest using a course similar to what qt does: they've got a routine that can scan a directory for a regular expression. Using this routine, shared libraries will conform to lib<name>.so.\d+.\d+, and finding the correct library is then a matter of choosing the highest major/minor.

I can quite well fix that for OpenBSD proper, but an actual clean fix requires several changes deeper in cmake.

- provide kwsys routines to read directories/find regexps.
- provide a knob in FindLibrary to recognize SunOS-like shared libraries.
TagsNo tags attached.
Attached Files? file icon patch-Source_cmFindLibraryCommand_cxx [^] (2,266 bytes) 1969-12-31 19:00 [Show Content]

 Relationships

  Notes
(0004393)
Marc Espie (reporter)
2006-07-03 08:59

I've since found about ::Glob, and I'm using it.
The following patch lets cmake find OpenBSD shared
libs, provided CMAKE_OPENBSD_SHARED_LIBS is set to TRUE.
(0008434)
Alex Neundorf (developer)
2007-08-13 15:22

What about the patch ?

Instead if testing the variable CMAKE_OPENBSD_SHARED_LIBS, the CMAKE_SYSTEM_NAME variable could be tested for "OpenBSD" ?

Oh, there may be more issues, like e.g. the link directory ordering.

Alex
(0008435)
Brad King (manager)
2007-08-13 15:42

The patch needs a little tweaking but looks okay at a quick glance. I don't have time to integrate it now. Also until we have a volunteer to run an OpenBSD nightly dashboard we cannot claim full support anyway.

We should not test the platform name. This is a platform feature, so the platform file should configure a global property to indicate this kind of naming is used.

Fixing library directory ordering will require a change to cmOrderLinkDirectories::LibraryInDirectory which tests whether a given library might be found by the linker in a given directory.
(0013509)
Hannah Schroeter (reporter)
2008-09-18 10:26

This issue also affects me, with cmake 2.6.1 (locally compiled) on OpenBSD 4.4. This hinders me from running boost based tests, as the boost test library behaves differently, causing linking to *fail*, when one links the static library instead of the dynamic one.

By the way, I've been told that even on Linux, not *all* packages do provide foo.so -> foo.so.x (or foo.so.x.y) symlinks, at least I've been told by co-workers who run Linux that this issue isn't completely unknown to them.

If one could use target_link_libraries to "-L... -l..." I could work around the issue for this time, at least, but that fails too (cmake creates a dependency on -L...\ -l..., from whence ever it's got the backslash).
(0013510)
Brad King (manager)
2008-09-18 10:36

In CMake 2.6 you can always link to the exact file you want by passing the full path to it. The problem here is finding the shared library.

You can achieve "-L... -l..." by using the link_directories command and passing just the library name to target_link_libraries.
(0013511)
Hannah Schroeter (reporter)
2008-09-18 10:43

Ok.

A more difficult issue is this, though:

On OpenBSD the mysql client libraries are installed like this:

In /usr/local/lib/mysql are the libraries proper, libfoo.a and libfoo.so.x.y
In /usr/local/lib are links, but only libfoo.so.x.y -> mysql/libfoo.so.x.y. *No* links for libfoo.a. So how do I "find" the path /usr/local/lib (i.e. I want to configure it to use /usr/local/lib as directory and foo as name)? I'd have to "find" that a file libfoo.so.* exists in /usr/local/lib to identify that as the right directory to use for link_directories.
(0013538)
Brad King (manager)
2008-09-22 10:09

I've created (but not yet committed) a new implementation of find_library that uses the directory-listing/name-matching approach to find libraries. It builds a regular expression that matches library names with the same combinations of prefixes and suffixes previously enumerated explicitly. Among the files matching the regular expression, the one that would have appeared earliest in the old enumeration order is chosen. This reproduces the old find-library behavior.

Now I need to support the versioning for OpenBSD's naming convention. I can do this by adding the version components to the regular expression for that platform. However, I'd like to make sure that CMake will find the library that would be found by the linker. Can anyone point me to documentation of how ld compares version numbers and chooses a library? Is it just a component-wise integer comparison?
(0013541)
Brad King (manager)
2008-09-22 10:15

I found some documentation here:

  http://www.openbsd.org/porting/libraries.html [^]

but it does not indicate how "ld" selects among multiple versions in the same directory. It specifies selection only for "ld.so".
(0013542)
Brad King (manager)
2008-09-22 11:00

I've committed the find_library refactoring mentioned above:

/cvsroot/CMake/CMake/Source/cmFindLibraryCommand.cxx,v <-- Source/cmFindLibraryCommand.cxx
new revision: 1.61; previous revision: 1.60
(0013543)
Brad King (manager)
2008-09-22 11:10

I've committed changes that teach find_library to find OpenBSD-style shared libs:

/cvsroot/CMake/CMake/Modules/Platform/OpenBSD.cmake,v <-- Modules/Platform/OpenBSD.cmake
new revision: 1.7; previous revision: 1.6
/cvsroot/CMake/CMake/Source/cmFindLibraryCommand.cxx,v <-- Source/cmFindLibraryCommand.cxx
new revision: 1.62; previous revision: 1.61
/cvsroot/CMake/CMake/Source/cmake.cxx,v <-- Source/cmake.cxx
new revision: 1.396; previous revision: 1.395

I'm assuming the obvious component-wise integer version test is correct because the originally submitted patch uses it. If not, someone may re-open this bug.

 Issue History
Date Modified Username Field Change
2007-08-13 15:22 Alex Neundorf Note Added: 0008434
2007-08-13 15:42 Brad King Note Added: 0008435
2008-09-18 10:26 Hannah Schroeter Note Added: 0013509
2008-09-18 10:36 Brad King Note Added: 0013510
2008-09-18 10:43 Hannah Schroeter Note Added: 0013511
2008-09-22 10:09 Brad King Note Added: 0013538
2008-09-22 10:15 Brad King Note Added: 0013541
2008-09-22 11:00 Brad King Note Added: 0013542
2008-09-22 11:10 Brad King Note Added: 0013543
2008-09-22 11:10 Brad King Status assigned => closed
2008-09-22 11:10 Brad King Resolution open => fixed


Copyright © 2000 - 2018 MantisBT Team