sourceforge.net

Scintilla / Bugs / #2184 place .so files in /usr/lib

  • ️Wed Jul 22 2020

Menu

#2184 place .so files in /usr/lib

Bug

closed-fixed

nobody

5

2020-07-22

2020-06-04

No

Affected version: 4.4.3 (but probably starting at 4.4.0)
Please install shared library (.so) files for the Linux version to /usr/lib or /usr/lib64 instead of /usr/bin. Most makefiles implement this with a variable LIBDIR. I can submit a patch if this is desired.

Discussion

  • Neil Hodgson

    I'm uncertain if this should be the default as it means there will be a global installation of the shared libraries with the potential of getting the wrong version. While aware of the arguments used to justify global shared library installations, I much prefer the Windows way of distributing private shared libraries with applications as it is more robust.

    Please send a patch.

     

    Last edit: Neil Hodgson 2020-06-04

  • B Stack

    You could probably put LIBDIR inside an ifdef linux or similar but I don't know the syntax for sure. But now it's an easy config option for packagers.

    • Neil Hodgson

      Scintilla is used by multiple projects, not just SciTE, so branding it with an rpath of $(prefix)/lib/scite in the Scintilla makefile seems strange. If Geany, for example, were to use this then $(prefix)/lib/geany would seem a better choice.

      Shouldn't the choice of rpath be left to the application?

      • Andreas Rönnquist

        What about $(prefix)/lib/scintilla/ ?

        • Neil Hodgson

          That might be OK except if multiple applications are using the same directory then there is the possibility of clashes such as overwriting with an older or customised .so.

          libscintilla.so doesn't load any other scintilla.org libraries. The connection between liblexilla.so and libscintilla.so is explicitly managed by SciTE. That allows, for example, using additional lexer shared libraries that follow the lexilla protocol by setting the lexilla.path property.

          Its unclear why the rpath of libscintilla.so needs to be set. SciTE loads libscintilla.so implicitly so SciTE needs to know where to load libscintilla.so thus SciTE can use an rpath and there is one set in its makefile. SciTE also loads liblexilla.so explicitly with dlopen.

          Perhaps the rpath in libscintilla.so communicates to the linker to add this to SciTE (or other applications) but then setting SciTE's rpath is superfluous.

  • Andreas Rönnquist

    You're right - it seems to work without setting the rpath for libscintilla.so. I have tested the attached patch some, and it seems to work fine for me (Please notice that it doesn't update where it installs the libraries yet, it just updates SciTE rpath and the LexillaSetDefaultDirectory path).

  • Neil Hodgson

    LexillaSetDefaultDirectory("/usr/lib/scintilla/") can make testing more difficult as it won't load a liblexilla.so next to the SciTE executable which would otherwise be enabled by the ${ORIGIN} rpath entry.

    With the library directory in an rpath, there doesn't appear to be a need for the explicit LexillaSetDefaultDirectory although the lexilla loading code has to be tweaked a little for an empty default directory. It then just does a dlopen of "liblexilla.so" which resolves using SciTE's rpath.

    Attached is a patch with these changes and with a 'libdir' set to $(prefix)/lib/scite. It doesn't include the addition of $(LDFLAGS) when linking but that seems to be a separate issue and adding $(LDFLAGS) seems fine to me.

  • Neil Hodgson

    • status: open --> open-fixed
  • Neil Hodgson

  • Neil Hodgson

    • status: open-fixed --> closed-fixed
  • Neil Hodgson


Log in to post a comment.