#189 Consider linking the Adium plugin to @executable_path/../Frameworks/libpurple.framework/Versions/Current/libpurple instead

1.15.x
closed-fixed
Michael Lamb
None
Adium
5
2014-08-12
2013-04-02
xnyhps
No

Currently, SIPEAdiumPlugin comes explicitly linked to version 2.10.5r590f15aee045 of libpurple, 2.32.4 of libglib and 0.18.1.1 of libintl:

$ otool -L SIPEAdiumPlugin.AdiumLibpurplePlugin/Contents/MacOS/SIPEAdiumPlugin
SIPEAdiumPlugin.AdiumLibpurplePlugin/Contents/MacOS/SIPEAdiumPlugin:
...
    @executable_path/../Frameworks/libpurple.framework/Versions/2.10.5r590f15aee045/libpurple (compatibility version 11.0.0, current version 11.5.0)
    @executable_path/../Frameworks/libglib.framework/Versions/2.32.4/libglib (compatibility version 3201.0.0, current version 3201.4.0)
    @executable_path/../Frameworks/libintl.framework/Versions/0.18.1.1/libintl (compatibility version 10.0.0, current version 10.1.0)

Many Adium updates update libpurple for security issues and bugfixes, this makes the plugin not load anymore, leading to rather... impolite feedback like https://trac.adium.im/ticket/16363.

However, the libpurple API/ABI guidelines guarantee that a plugin linked to libpurple 2.x.y will continue to work for all newer 2.z.w releases.

So you could avoid this problem by linking to the newest version, every framework has a Versions/Current alias pointing to the latest version it includes, using for instance install_name_tool.

If you're too concerned about updates that break the plugin, we (the Adium team), could start adding intermediate version aliasses, like Versions/2.10/ and Versions/2/.

Please let me know what you think about this!

Related

Release Notes: 2013/04/pidgin-sipe-release-1151----bug-fixes-i

Discussion

  • Stefan Becker
    Stefan Becker
    2013-04-02

    • assigned_to: Michael Lamb
     
  • Stefan Becker
    Stefan Becker
    2013-04-02

    Assigning to Adium backend maintainer.

    My $0.02: you can't please everybody. There is no law against obnoxious idiots using your Open Source project.

    Don't take it personally.

     
    Last edit: Stefan Becker 2013-04-02
  • Michael Lamb
    Michael Lamb
    2013-04-02

    xnyhps@: I was actually working on a fix, in my local repository, for this exact issue (last night serendipitously!). I was adding a build step to change the install name (with the install_name_tool as you mentioned) to the "Current" symlink.

    However, I had not yet checked it into the public repository because it's not a backwards-compatible solution. The problem is, that libpurple has a dependency on libglib. The version of libglib that is now being bundled with Adium (1.5.6) is not backwards-compatible.

    Also, it appears that Adium itself is linking to hard-coded versions of the libraries:

    Adium 1.5.6:
    $ otool -L /Applications/Adium.app/Contents/MacOS/Adium | grep libglib
    @executable_path/../Frameworks/libglib.framework/Versions/2.34.3/libglib (compatibility version 3401.0.0, current version 3401.3.0)

    Adium 1.5.4:
    $ otool -L /Applications/Adium-1.5.4.app/Contents/MacOS/Adium | grep libglib
    @executable_path/../Frameworks/libglib.framework/Versions/2.32.4/libglib (compatibility version 3201.0.0, current version 3201.4.0)

    In order to fix this, I see two solutions:
    1) I bundle all of the dependent libraries (libglib,libintl, libpurple, etc) into the SIPE plugin bundle (which I may end up doing anyway).
    2) Adium changes their bundles to include older versions.

    I would obviously prefer option #2. My reasoning, is that other plugins are likely going to have this same issue, and solving it at the higher (read Adium) level seems like the more "general" solution. I would suggest keeping dependent versions only back as far as the last major dot release. (i.e. 1.5.x would have the linked versions for 1.5.1, 1.5.2, etc… and 1.6 would have only the linked versions for that dot release).

    Another thing I'm investigating now, is how to detect the version of Adium (and dependent libraries) upon install of the plugin. I could then throw up a warning to the user that they need to upgrade to the latest version of Adium. However, this seems like a stop-gap measure.

    Any thoughts/suggestions?

     
  • xnyhps
    xnyhps
    2013-04-02

    Hmm, I had never looked at glib's ABI compatibility guarantees! I was subconsciously assuming it was the same as libpurple.

    libglib updates are rarely critical and libpurple allows relatively old versions of it. The reason it got bumped to 2.34.4 is simply that Homebrew updated their formula for glib, and that's what we're using right now to build those dependencies.

    If this is such a big problem for you, then I'm sure we can promise to not update libglib unless we really need to. Would that work for you?

    The last time I had two different copies of a framework loaded in one application, it was a huge headache.

     
  • Michael Lamb
    Michael Lamb
    2013-04-03

    I did some research, and found an ld flag ("-undefined dynamic_lookup") that allows me to not have to link against those dependent frameworks. Since those frameworks/libraries are already guaranteed to be loaded by Adium (with the libpurple subsystem initialization), dynamic lookup of the symbols will work regardless of version.

    This is now resolved (and is both backwards and forwards compatible)! :)

     
  • Michael Lamb
    Michael Lamb
    2013-04-03

    • status: open --> closed-fixed