Archived

This forum has been archived. Please start a new discussion on GitHub.

bad install_name on OS X(Darwin)

I noticed while trying out the "hello world" demo on OS X that I needed to set the DYLD_LIBRARY_PATH environment variable in order to get things working. On Darwin, this is somewhat bad form since the default path to various libraries can be set in the "install_name" at link time. As long as the location of the library at runtime is the same as at link time, then there is no need for DYLD_LIBRARY_PATH. (Even better would be for Ice to be built as a first-class Framework, but that would take some more work.)

Using the "otool -L" command on your libraries, I noticed that the install_name within the libraries have a weird "@exectuable_path" thingy on the front. Since the install name is supposed to be the path where libraries are first checked, these will never be found since there is no directory by that name. That then requires looking for things in DYLD_LIBRARY_PATH.

What I'd like to do is fix your makefiles so that the proper installname is set. I almost got that working by modifying the Make.rules.Darwin to set the installname to "${install_libdir}". This was working quite swimmingly setting the install name in the libraries to "/usr/local/Ice-2.1.2/lib/...". This would have allowed me to use the libraries without having to set the DYLD... variable. However, during the compile of something in the test folder, it bombed with linkage problems, so I obviously need to look at this some more.

If I can get this fixed are you interested in a patch? Or, is this something that can't be fixed due to additional requirements that I'm not aware of? Or, are you already working on a fix for another version?

Comments

  • benoit
    benoit Rennes, France
    The current install name is set to @executable_path/../lib/<libname>. With this install name, no matter where the Ice distribution is installed (and even if you move it), you don't need to set the DYLD_LIBRARY_PATH to run an executable from the distribution bin directory (slice2cpp, etc). We'll think about your suggestion to use ${install_libdir} instead.

    For the link errors, they are most likely caused by the change of the install name. When linking an executable, the linker also looks for dependencies of a given library where it's supposed to be installed. If it's not found it complains about unresolved symbols. I believe this can be fixed by adding the required library to the link command line with the -l option. We'll have a closer look at this for the next release.

    Benoit.
  • Hi Benoit,

    Thanks for the reply. It turns out that the only problem with the link errors for the test programs were related to a reference to a parsing function in libIceXML from libIceSSL. I added '-lIceXML' to the targets in the makefiles for the programs in test/IceSSL and they all compiled and linked just fine.

    I would like to lobby for the change in the install_name for these two reasons:

    1) With the install_name being the libraries' actual paths, rather than being relative to @executable_path, programs other than the utilities inside "bin" would also run and link without needing DYLD_LIBRARY_PATH being set.

    2) I'm not really sure that moving a library would be a common activity in a production situation, anyway. However, one could always change the install location using the "install_name_tool" afterwards.

    Regards,
    Joe