bugGNUstep - Bugs: bug #42778, Frameworks with different SONAME...


You are not allowed to post comments on this tracker with your current authentication level.

bug #42778: Frameworks with different SONAME cannot coexist

Submitted by:  Yavor Doganov <yavor>
Submitted on:  Tue 15 Jul 2014 05:28:37 PM UTC  
Category: MakefilesSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: In Test

Sun 31 Dec 2017 05:05:20 PM UTC, comment #5:

Niels, this hunk (in comment #3) was completely intentional. As it stands, if a framework with a new interface version is installed, the Resources symlink will be updated to point to the Current version. This is wrong. Different versions may have different resources and this is 100% doomed to fail if some of these resources are arch-dep, because an app still linking with the old framework will attempt to load bundles that are linked against the new framework.

I also thought it may break resource lookups, but it doesn't. Let me demonstrate:

Notice the absence of the Resources symlink. PopplerKit has fonts as resources and this method in PopplerFontManager.m:

The fonts are available in the arch-indep location where the Resources symlink under Versions/VER points to (as symlinks to the actual font files from the gsfonts package in Debian, but this doesn't matter here):

Relevant portion from the log:

The duplicate messages come from poppler_init in bindings/poppler.cc but the important thing is that this symlink is not necessary for proper resource lookups.

Yavor Doganov <yavor>
Sun 09 Apr 2017 06:35:19 AM UTC, comment #4:

It seems Niels fixed this one ... can it be confirmed as working?

Richard Frith-Macdonald <CaS>
Project Member
Wed 29 Jun 2016 09:40:20 AM UTC, comment #3:

The patch as been applied to gnustep-make in the meantime, but this part causes problems:

@@ -389,10 +389,6 @@ build-framework-dirs: $(DERIVED_SOURCES_DIR) \
- if [ ! -h "Resources" ]; then \
- $(RM_LN_S) Resources; \
- $(LN_S_RECURSIVE) Versions/Current/Resources Resources; \
- fi; \
if [ ! -h "Headers" ]; then \
$(RM_LN_S) Headers; \
$(LN_S_RECURSIVE) Versions/Current/Headers Headers; \

It breaks resource lookups and prevents proper dynamic loading of frameworks. I'm pretty sure that this is accidental and will revert that part.

Niels Grewe <thebeing>
Project Member
Thu 24 Jul 2014 12:25:42 PM UTC, comment #2:

Proposed patch attached. It makes the existence of two framework versions (in fact, multiple framework versions) possible. It doesn't delete the installed framework prior to the installation of the new one and symlinks are created directly to the versioned directory instead of the Current symlink. Also, since Resources are version-specific (or at least they may be) it is not correct to create a Resources symlink pointing to Current. Headers are also version-specific but as there can only be one .so symlink only one set of headers can be used at any time (the "Current" headers, so this behavior is retained).

Tested with RSSKit/0.3, then RSSKit/0.4 installed on top of it with INTERFACE_VERSION set to 1, then RSSKit/0.4 with VERSION bumped to 0.4.1 (simulating a new release which is ABI-compatible with 0.4). It appears to work:

Installing in the USER domain is OK too:

I also checked that projects that have an internal framework (whether intended to be public or not) and set ADDITIONAL_LIB_DIRS to something like "-L../../Foo.framework/Versions/Current" continue to build/link without problems.

As this is one of the most sensitive areas in GNUstep Make, I guess this change should be tested very well (with as many layouts as possible) before it is installed.

(file #31767)

Yavor Doganov <yavor>
Mon 21 Jul 2014 04:19:21 PM UTC, comment #1:

Actually, it is even more serious than that. Installing a new version of the framework will wipe out the old one completely, so there will only be one Version, with Current pointing to it. This is done unconditionally as the first command of the internal_framework_install_ recipe. The current behavior defeats the whole idea of frameworks (not that I ever understood what frameworks are for in the first place).

What I wrote in the first message (that the old libBar is still in Versions/0) is true when the framework is packaged as it is installed in a tmp dir during build and there's no previous framework version to delete there.

Steps to reproduce (with a random GNUstep framework):

$ make
$ make install DESTDIR=/tmp/foo
$ make clean
$ make install INTERFACE_VERSION=5 DESTDIR=/tmp/foo

And the shocking result:
libRSSKit.so.0 is a broken symlink. As a result applications that linked with RSSKit cannot be started.
There should be a "0" directory there with the old library.

Would you accept a patch that stops deleting the installed framework and also creates symlinks directly to Versions/$ver instead of Versions/Current? The .so symlink must probably still point to Current for projects linking with an internal framework to continue to work.

Yavor Doganov <yavor>
Tue 15 Jul 2014 05:28:37 PM UTC, original submission:

There is a fundamental issue in the way GNUstep Make creates the symlinks for the frameworks, at least with the fhs-system layout.

Suppose that you have Foo.app linked with the Bar framework, which has interface version 0:

So far so good, and then you install a new version of Bar which is not binary compatible and has interface version 1. This will replace the "Current" symlink to point to Versions/1 and subsequently will wipe the /usr/lib/libBar.so.0 symlink. Then Foo.app will fail to load because the dynamic linker cannot find the library (it is there, in Versions/0, but the symlink is gone):

Normally, Foo.app should still be working by continuing to link with libBar.so.0 until it is rebuilt, at which point it should link with libBar.so.1. I am not sure if this is a problem for this layout only.

Yavor Doganov <yavor>


Attached Files
file #31767:  versioned-frameworks.patch added by yavor (3KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by thebeing (Posted a comment)
  • -unavailable- added by yavor (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 09 Apr 2017 06:35:19 AM UTCCaSStatusNone=>Fixed
      Open/ClosedOpen=>In Test
    Thu 24 Jul 2014 12:25:42 PM UTCyavorAttached File-=>Added versioned-frameworks.patch, #31767

    Back to the top

    Powered by Savane 3.1-cleanup1