Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: build
    • Labels:
      None

      Description

      We build our binaries expecting to find libmesos.so on the shared library search path. In many environments /usr/local/lib is not on the shared library search path. That means users are required to update the search path for the system or launch the binaries with LD_LIBRARY_PATH. Statically linking the binaries would fix this problem. In addition, we might be able to pass -R as a libtool specific LDFLAGS that does the right thing. Either way, it would be nice to make it easy for a user who is installing to not have to use LD_LIBRARY_PATH or need the permissions to update the system search path.

        Issue Links

          Activity

          Hide
          Charles Reiss added a comment -

          The main impediment to statically linking is third_party.

          There are two cases:

          • for third_party libraries which are built as .la's, libtool would correct link our binaries if we linked libmesos.la as a static library. However, libtool would install a .a which does not include include the third_party libraries, and the third_party libraries would also not be installed. Libtool would specify the external .a's as a dependency of the installed .la, but, of course, this would not be possible for frameworks linking against mesos to satisfy.

          We could rely on installing these third_party libraries (possibly under a different libdir) or having them preinstalled and using the system version. Alternately, we could turn the third_party libtoolized libraries we link against into libtool convenience libraries (replacing libdir='$(libdir)' with libdir='' in the .la file) and libtool would probably know how to link them into an inclusive library on the platforms we care about. (Though it's possible that this would not work due to, e.g., object name conflicts.)

          • for third_party libraries which are built as .a's, libtool does not know how to correctly link these into a .a. We could probably manually generate a convenience library .la for these or rely on a preinstalled .a (which we could link with -L/install/dir -lfoo)
          Show
          Charles Reiss added a comment - The main impediment to statically linking is third_party. There are two cases: for third_party libraries which are built as .la's, libtool would correct link our binaries if we linked libmesos.la as a static library. However, libtool would install a .a which does not include include the third_party libraries, and the third_party libraries would also not be installed. Libtool would specify the external .a's as a dependency of the installed .la, but, of course, this would not be possible for frameworks linking against mesos to satisfy. We could rely on installing these third_party libraries (possibly under a different libdir) or having them preinstalled and using the system version. Alternately, we could turn the third_party libtoolized libraries we link against into libtool convenience libraries (replacing libdir='$(libdir)' with libdir='' in the .la file) and libtool would probably know how to link them into an inclusive library on the platforms we care about. (Though it's possible that this would not work due to, e.g., object name conflicts.) for third_party libraries which are built as .a's, libtool does not know how to correctly link these into a .a. We could probably manually generate a convenience library .la for these or rely on a preinstalled .a (which we could link with -L/install/dir -lfoo)

            People

            • Assignee:
              Unassigned
              Reporter:
              Benjamin Hindman
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development