rexx can't open library: libdl.1.dylib

  • Alan Ackerman
    Alan Ackerman

    I have a problem in Regina 3.2, when running on Mac OS X 10.3 (or 10.2). After installing REXX in /user/local, and issuing;

    $ DYLD_LIBRARY_PATH=/usr/local/lib

    I get:

    $ rexx
    dyld: rexx can't open library: /usr/local/lib/libdl.1.dylib  (No such file or directory, errno = 2)
    Trace/BPT trap

    Checking with find, there is no "libdl.1.dylib" anywhere on my Mac.
    There is a "/usr/lib/libdl.dylib". Creating a symbolic link:

    sudo ln -s /usr/lib/libdl.dylib /usr/local/lib/libdl.1.dylib

    resolves the problem.

    I found an article on the Internet by Damien Gallop about a very similar problem. He thinks the problem is that a programmer somewhere callled for "libdl.1.dylib" -- a release-specific version -- instead of "libdl.dylib" -- which should  be a link to the latest version. The article is at <>.

    Of course, I don't know that Regina is doing this -- it may be a bug somewhere in the software included with MacOS X. I just recently installed Mac OS X 10.3, via Archive and Install, so I doubt it is because of anything I installed.

    Incidentally, the file "doc/regina/README.Unix" should be updated to include the line:

    Under Mac OS X (Darwin) this is DYLD_LIBRARY_PATH.

    • I've no idea of MAC OS, but what happens with
      instead? If this works either MAC OS just uses this
      variable only for searching dyn libs or the alternate
      mimic of MAC for finding dyn libs is broken.

      If you can't get it running drop me an email.

      Cheers, Florian

      • Alan Ackerman
        Alan Ackerman

        No difference. Initially, $DYLD_LIBRARY_PATH
        is null. I did get it to work, but only by creating libdl.1.dylib as a link to libdl.dylib. The question is, I think, why is Regina looking for libdl.1.dylib instead of libdl.dylib?

        What does "the alternate mimic of MAC for finding dyn libs is broken" mean?

        • Mark Hessling
          Mark Hessling


          The problem is the original makefile included with libdl.dylib, that I used for building Regina, builds libdl.1.dylib as the actual shared library, and creates a symbolic link to it.
          When Regina links to libdl.dylib, the linker actually embeds the "real" shared library name into the Regina executable (libdl.1.dylib).
          This is why what you are seeing happens.
          The workaround is as you suggested; adding a symbolic link.
          As the Apple distributed libdl.dylib on 10.2 appears to have a "real" name of libdl.dylib, future binary releases of Regina will be built to ensure that libdl.dylib is the actual name of the shared library to be loaded at runtime.
          Hopefully SourceForge will update one of its MAC servers from 10.1 or 10.2 to 10.3 soon.

          Cheers, Mark