Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#2528 sfcCommon should add its libpath to system search path

Stability
closed-rejected
sfcb (1090)
5
2012-09-12
2012-09-05
Dave Heller
No

In SFCB 1.4, sfcCommon was split into a separate module (see 3177587), with sfcCommon libraries no longer installed into $libdir/sfcb but rather installed directly into $libdir. (Note libdir=$prefix/lib, so with the default prefix=/usr/local, libdir=/usr/local/lib).

If $libdir is not in the system library search path this can cause "libsfcUtil.so not found" errors at a number of points for SFCB. The first is during "make postinstall", where the sfcbmof and sfcbmofpp utilities hit this problem. It is also seen during SFCB startup, where the sfcbd binary will hit it. It is *not* seen at startup via the initscript, since the initscript sets LD_LIBRARY_PATH=/usr/local/lib.

One solution is to apply LD_LIBRARY_PATH fixes to the remaining points where the the break occurs (the "make postinstall", etc.). But at better solution seems to be for sfcCommon to add its libdir to the system library search path, by adding a file to /etc/ld.so.conf.d and then running ldconfig. The proposed patch does this during the sfcCommon "make install".

Note: the third solution, which was not considered, would be to update the RPATH tag in (SFCB's) binary ELF files to include the sfcCommon $libpath. This seems less flexible and would be an x86-only solution.

In sum, the proposed patch accomplishes three things:

1. sfcCommon should add it's own libpath to system search path.
2. sfcCommon 'make uninstall' should clean up $sfcCommonlibdir and $(includedir)/sfcCommon
3. sfcCommon should install libs in a subdirectory of $libdir, rather than directly into $libdir

Item 2 is not related to the bug but is just a bit of housekeeping.

Item 3 is not strictly required but seems a better/cleaner approach. The patch for item 1 can handle any sfcCommmon libpath, and this seemed the appropriate time to make the change.

However, item 3 results in a build break for SFCB, as the linker must be explicitly be told (i.e. via '-L') where to find the sfcCommon libraries. So, an additional patch to SFCB is required to implement 3.

This patch applies only to the SFCB 1.4 environment; it is not applicable to SFCB 1.3.

This patch has not yet been checked into git as we would like to allow some time for feedback.

Discussion

  • Klaus Kämpf
    Klaus Kämpf
    2012-09-07

    Uhm, these are the things which make a RPM packager's life a bit harder.

    Installing libraries into $libdir is a good thing and its a system configuration (not a per-package one) to include $libdir into the search path for ld.so
    -> No need to change ld.so.conf(.d)

    For testing, one should use LD_LIBRARY_PATH, i.e. "export LD_LIBRARY_PATH=/usr/local/lib". Again, no need to change ld.so.conf(.d)

     
  • Klaus Kämpf
    Klaus Kämpf
    2012-09-07

    Please remember that 64bit Linux distributions use /lib64 and /usr/lib64 for 64bit libraries and /lib, /usr/lib for 32bit-legacy libraries

     
  • Dave Heller
    Dave Heller
    2012-09-07

    Well, I should point out that the patches for 3565035, 3565036 are coded to install, and look for, the libs in path based on the install prefix. So assuming the RPM packaging does something similar, that would relieve the concern about /lib vs. /usr/lib vs. /usr/local/lib. As for the use of lib vs lib64 I assume the same is also basically true: that the packager would determine which is appropriate. But I do understand your point that moving the libs to a dedicated subdirectory adds little value.

    If I understand the essence your suggestion, it is that we should make no change, but rather recommend to the user they add $libdir to the system search path themselves, if it is not already? And continue to use LD_LIBRARY_PATH workarounds where necessary?

     
  • Dave Heller
    Dave Heller
    2012-09-12

    • status: open --> closed-rejected
     
  • Dave Heller
    Dave Heller
    2012-09-12

    Based on community feedback we have decided not to make the proposed changes in 3565035 and 3565036 at this time. sfcCommon will continue to install it's libraries into $libpath rather than than a subdir of $libpath. Users will have to ensure that $libpath is in the system library path, or set the LD_LIBRARY_PATH env variable as appropriate.

    Patch 3567083 was made to SFCB 1.4 to provide a clearer error message if libsfcUtil.so cannot be found during SFCB configure. Also, some documentation updates were made to the following:

    https://sourceforge.net/apps/mediawiki/sblim/index.php?title=SfcCommon
    https://sourceforge.net/apps/mediawiki/sblim/index.php?title=SfcbTheBook

    The discussion here raises the question of whether it is appropriate for /usr/local/lib to be included in the system search path. Some would argue yes, since /usr/local is so widely used by developers. Others would argue no, since excluding it creates some delineation between development and production applications. Some Linux distros include it by default while others do not. For SFCB, it will be the developer's responsibility to check and to modify their configuration as appropriate.