Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-5753

XCode 7.3 can not link indirect dependencies that use @rpath

    Details

    • Story Points:
      4
    • Team:
      Architecture

      Description

      With XCode 7.3 on OS X we have difficulties resolving indirect dependencies when those dependencies are referenced using @rpath. This can be seen with Qserv:

      Linking shared object build/libqserv_common.dylib
      ld: file not found: @rpath/libboost_system.dylib for architecture x86_64
      clang: error: linker command failed with exit code 1 (use -v to see invocation)
      

      where libboost_system is being loaded via libboost_thread:

      $ otool -L $BOOST_DIR/lib/libboost_thread.dylib
      /Users/timj/work/lsstsw/stack/DarwinX86/boost/1.59.lsst5+fbf04ba888/lib/libboost_thread.dylib:
      	@rpath/libboost_thread.dylib (compatibility version 0.0.0, current version 0.0.0)
      	@rpath/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
      	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
      	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
      

      This problem is also found when doing a conda build of the stack because in conda all shared libraries are modified on creation to reference other libraries via the @rpath mechanism.

      This bug has been reported to Apple as rdr://25313838 and a Chromium bug report indicates that the fix is to simply ensure that -L directives include a trailing slash.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness Tim Jenness added a comment -

            but in lsstsw installs log4cxx.dylib does not have LC_RPATH set and has a full path to libapr etc. I am currently trying to explain why it works with lsstsw, not why it fails with conda. I'm pretty sure that this means log4cxx is ignoring any EUPS settings you may think you are using to specify the APR location (which might actually be the correct behavior for third party libraries to ensure you only ever get the version of liblog.dylib that you initially built).

            Show
            tjenness Tim Jenness added a comment - but in lsstsw installs log4cxx.dylib does not have LC_RPATH set and has a full path to libapr etc. I am currently trying to explain why it works with lsstsw , not why it fails with conda. I'm pretty sure that this means log4cxx is ignoring any EUPS settings you may think you are using to specify the APR location (which might actually be the correct behavior for third party libraries to ensure you only ever get the version of liblog.dylib that you initially built).
            Hide
            mjuric Mario Juric added a comment -

            > I am currently trying to explain why it works with lsstsw, not why it fails with conda.

            Ah, OK, got it.

            > but in lsstsw installs log4cxx.dylib does not have LC_RPATH set and has a full path to libapr etc.

            You're quite right! I looked at a few other libs and they all have full paths to some third-party libraries:

            [ElCapitanVM@Marios-Mac (master) ~/projects/lsstsw]$ otool -L stack/DarwinX86/afw/2.2016.10-8-g2cef314+4/lib/libafw.dylib
            stack/DarwinX86/afw/2.2016.10-8-g2cef314+4/lib/libafw.dylib:
            	libafw.dylib (compatibility version 0.0.0, current version 0.0.0)
            	libwcs.5.13.dylib (compatibility version 5.0.0, current version 5.13.0)
            	libcfitsio.2.dylib (compatibility version 2.0.0, current version 2.3.36)
            	/Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/gsl/1.16.lsst3/lib/libgsl.0.dylib (compatibility version 18.0.0, current version 18.0.0)
            	/Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/gsl/1.16.lsst3/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0)
            	/Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/minuit2/5.28.00.lsst2-1-gdae2fb7/lib/libMinuit2.0.dylib (compatibility version 1.0.0, current version 1.0.0)
            	/Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/fftw/3.3.4.lsst2/lib/libfftw3f.3.dylib (compatibility version 8.0.0, current version 8.4.0)
            	/Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/fftw/3.3.4.lsst2/lib/libfftw3.3.dylib (compatibility version 8.0.0, current version 8.4.0)
            	libdaf_persistence.dylib (compatibility version 0.0.0, current version 0.0.0)
            	@rpath/libboost_serialization.dylib (compatibility version 0.0.0, current version 0.0.0)
            	libmysqlclient.18.dylib (compatibility version 18.0.0, current version 18.0.0)
            	libpex_policy.dylib (compatibility version 0.0.0, current version 0.0.0)
            	libpex_logging.dylib (compatibility version 0.0.0, current version 0.0.0)
            	@rpath/libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
            	@rpath/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
            	libdaf_base.dylib (compatibility version 0.0.0, current version 0.0.0)
            	libutils.dylib (compatibility version 0.0.0, current version 0.0.0)
            	libpex_exceptions.dylib (compatibility version 0.0.0, current version 0.0.0)
            	libbase.dylib (compatibility version 0.0.0, current version 0.0.0)
            	@rpath/libboost_regex.dylib (compatibility version 0.0.0, current version 0.0.0)
            	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
            	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
            

            That's interesting – technically, it's a bug because it breaks EUPS' mix-and-match capability (i.e., I can't swap out GSL or FFTW with unsetup/setup), but we do that so rarely that nobody noticed. I think it could be fixed at the eupspkg level – Robert Lupton, do you think it's worth it?

            Show
            mjuric Mario Juric added a comment - > I am currently trying to explain why it works with lsstsw, not why it fails with conda. Ah, OK, got it. > but in lsstsw installs log4cxx.dylib does not have LC_RPATH set and has a full path to libapr etc. You're quite right! I looked at a few other libs and they all have full paths to some third-party libraries: [ElCapitanVM@Marios-Mac (master) ~/projects/lsstsw]$ otool -L stack/DarwinX86/afw/2.2016.10-8-g2cef314+4/lib/libafw.dylib stack/DarwinX86/afw/2.2016.10-8-g2cef314+4/lib/libafw.dylib: libafw.dylib (compatibility version 0.0.0, current version 0.0.0) libwcs.5.13.dylib (compatibility version 5.0.0, current version 5.13.0) libcfitsio.2.dylib (compatibility version 2.0.0, current version 2.3.36) /Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/gsl/1.16.lsst3/lib/libgsl.0.dylib (compatibility version 18.0.0, current version 18.0.0) /Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/gsl/1.16.lsst3/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/minuit2/5.28.00.lsst2-1-gdae2fb7/lib/libMinuit2.0.dylib (compatibility version 1.0.0, current version 1.0.0) /Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/fftw/3.3.4.lsst2/lib/libfftw3f.3.dylib (compatibility version 8.0.0, current version 8.4.0) /Users/ElCapitanVM/projects/lsstsw/stack/DarwinX86/fftw/3.3.4.lsst2/lib/libfftw3.3.dylib (compatibility version 8.0.0, current version 8.4.0) libdaf_persistence.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libboost_serialization.dylib (compatibility version 0.0.0, current version 0.0.0) libmysqlclient.18.dylib (compatibility version 18.0.0, current version 18.0.0) libpex_policy.dylib (compatibility version 0.0.0, current version 0.0.0) libpex_logging.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0) libdaf_base.dylib (compatibility version 0.0.0, current version 0.0.0) libutils.dylib (compatibility version 0.0.0, current version 0.0.0) libpex_exceptions.dylib (compatibility version 0.0.0, current version 0.0.0) libbase.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libboost_regex.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) That's interesting – technically, it's a bug because it breaks EUPS' mix-and-match capability (i.e., I can't swap out GSL or FFTW with unsetup/setup), but we do that so rarely that nobody noticed. I think it could be fixed at the eupspkg level – Robert Lupton , do you think it's worth it?
            Hide
            rhl Robert Lupton added a comment -

            You mean mix and match our code (which I do all the time), or low-level external libraries such as cfitsio?

            If the latter it's OK (especially as things like cfitsio explicitly make it impossible already). If the former no – we need to be able to switch out things like afw.

            Show
            rhl Robert Lupton added a comment - You mean mix and match our code (which I do all the time), or low-level external libraries such as cfitsio? If the latter it's OK (especially as things like cfitsio explicitly make it impossible already). If the former no – we need to be able to switch out things like afw.
            Hide
            mjuric Mario Juric added a comment -

            The latter. E.g., you can't switch out fftw or gsl right now (or any other third-party lib that encodes the full path into its install_name). I'm not sure we care (though if someone ever did, they'd be in for hours of headaches figuring out why 'setup -j .' for fftw doesn't make (say) afw pick up the override ...).

            PS: Not sure why cfitsio would make it impossible? They break the ABI between versions?

            Show
            mjuric Mario Juric added a comment - The latter. E.g., you can't switch out fftw or gsl right now (or any other third-party lib that encodes the full path into its install_name). I'm not sure we care (though if someone ever did, they'd be in for hours of headaches figuring out why 'setup -j .' for fftw doesn't make (say) afw pick up the override ...). PS: Not sure why cfitsio would make it impossible? They break the ABI between versions?
            Hide
            rhl Robert Lupton added a comment -

            Probably. They check a version number in the .so file — very bizarre. That's not their job.

            Show
            rhl Robert Lupton added a comment - Probably. They check a version number in the .so file — very bizarre. That's not their job.

              People

              • Assignee:
                tjenness Tim Jenness
                Reporter:
                tjenness Tim Jenness
                Reviewers:
                John Swinbank
                Watchers:
                John Swinbank, Mario Juric, Robert Lupton, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel