Am 2017-11-13 13:23, schrieb wf...@niif.hu:
I'm packaging a program which wants to dlopen() some library.  It finds
this library via pkg-config (PKG_CHECK_MODULES).  How to best determine
the filename to use in the dlopen() call?  It should work cross-distro,
for cross-compilation and whatnot.  Is it always safe to use the SONAME
as the filename?

The SONAME is the right thing to do here, as that is what's encoded in
the DT_NEEDED field by the linker.

I'm currently considering something like

ld -shared -o dummy.so $(my_LIBS)
objdump -p dummy.so | fgrep NEEDED

That might work, but I'm not sure that's very stable.

I've created the following example code that works for me with libpng:

cmake_minimum_required(VERSION 3.0 FATAL_ERROR)

find_library(PNG_LIBRARY_FILE NAMES png)
  execute_process(COMMAND objdump -p "${PNG_LIBRARY_FILE}"
    string(REGEX MATCH "\n[ \t]*SONAME[ \t]+([^ \t\r\n]*)"
           DUMMY "${PNG_CONTENTS}")
    if (DUMMY)
      message(STATUS "Got libpng soname: ${PNG_SONAME}")
message(FATAL_ERROR "Could not extract SONAME from ${PNG_LIBRARY_FILE}")
message(FATAL_ERROR "Could not run objdump -p on ${PNG_LIBRARY_FILE}")
  message(FATAL_ERROR "Could not find -lpng")


 - This assumes that objdump -p actually works. This is basically only
   true if you use the GNU toolchain on ELF systems. If you have another
   platform then you need to call different things:

     - On Mac OS X you need to do otool -D $LIBRARY and then parse that
       (it will give you back something like (notice the newline!)


       The base name of the second line of that output is what you're
       looking for for dlopen().

     - On other UNIX platforms I don't really know.

     - On Windows with the MinGW toolchain, when you have an import
       library (*.dll.a MinGW style or *.lib Microsoft style) then you
       may use dlltool -I $IMPORTLIB to extract the DLL name from
       that. However, MinGW does support linking directly against DLLs
       in some cases (when they were also compiled with MinGW, for
       example, and fulfill some additional criteria), and it may be
       the case that your linker finds the DLL directly if no import
       library is found, in which case dlltool -I will fail, but you
       can just use the basename of the DLL.

       Note that objdump -p does work on MinGW on Windows, but doesn't
       give you a SONAME. (It does mention the DLL name multiple times,
       but I'm not sure that's easy to parse.)

     - On Windows with MSVC I have no idea how to get the DLL name
       from an import library (*.lib), but there's definitely going
       to be a tool you'll be able to use.

     - No idea on yet other operating systems.

 - I'm hacked this together and am not sure this is the sanest way of
   parsing this in CMake... YMMV.

 - CMake might only find a static library depending on how your search
   path is set up (*.a on UNIX systems including Mac OS X, as well as
   on MinGW, but *.lib on Windows system with MSVC). On Windows the
   fact that import libraries and static libraries share the same
   extension actually makes it quite difficult to handle this case

 - If you do manage to write some relatively generic code, I would
   urge you to contribute that to CMake as a macro, so that other
   people could also profit from it.


Reply via email to