On Tue, Aug 26, 2025 at 05:02:25PM +0100, Gavin Smith wrote:
> I have put together some minimal test cases to show the problem.  Perhaps
> you could test them and confirm that the problem occurs, before reporting
> to the libtool developers?

I have no better mean to do that... In particular, the CI is not much
usable for such tests.

I had a look at (relatively) recent commits in libtool related to
OpenBSD, and it seems that there is something specific for this
platform, where rpath seem not to be used, instead ldconfig need to be
called to have libraries found.

This is what I understood by reading the description of the --no-finish
and --reorder-cache libtool options descriptions in  
https://www.gnu.org/software/libtool/manual/html_node/Invoking-libtool.html

However, I have not found more information on internet on that, nor
guidance on what to do on OpenBSD.  I may also have completly
misunderstood the situation.

> (Attachments renamed because otherwise they are blocked by my email provider.)
> 
> First is the source files in test-library-ok.tar.gz.  To build this,
> you need to change the file name of SHARED_LIB in prog.c to the file
> name that is used on a system (for example, ".libs/lib1.so.0.0.0" might
> become ".libs/lib1.so.0.0").
> 
> This runs fine on GNU/Linux (Linux Mint 21.2 Victoria) and the OpenBSD
> system where I tested it (OpenBSD 7.7), when after generating the
> build system ("autoreconf -vi", followed by configure and make), running
> "./prog" manages to load the shared library "lib1" and run the function
> inside it to print a message ("inside foo").
> 
> test-library-fail.tar.gz shows the problem with an extra layer of libraries.
> prog loads lib1, which depends on lib2.  This works on GNU/Linux, but not
> OpenBSD.  On GNU/Linux, RUNPATH is recorded in lib1:
> 
> $ readelf -a .libs/lib1.so.0.0.0 | grep RUNPATH
>  0x000000000000001d (RUNPATH)            Library runpath: 
> [/home/g/src/texinfo/libtool-test-case/.libs]
> 
> There is no such record on OpenBSD in .libs/lib1.so.0.0.  There the
> dlopen call to load lib1 fails with the error "Cannot load specified object".
> 

That's clear.

-- 
Pat

  • test... Bruno Haible via Bug reports for the GNU Texinfo documentation system
    • ... Patrice Dumas
      • ... Bruno Haible via Bug reports for the GNU Texinfo documentation system
        • ... Patrice Dumas
          • ... Gavin Smith
            • ... Patrice Dumas
              • ... Bruno Haible via Bug reports for the GNU Texinfo documentation system
                • ... Patrice Dumas
                • ... Eli Zaretskii
                • ... Patrice Dumas
                • ... Gavin Smith
                • ... Patrice Dumas
                • ... Patrice Dumas
                • ... Gavin Smith
          • ... Gavin Smith
            • ... Bruno Haible via Bug reports for the GNU Texinfo documentation system

Reply via email to