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


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

bug #42778: Frameworks with different SONAME cannot coexist

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

Sun Apr 9 06:35:19 2017, comment #4:

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

Richard Frith-Macdonald <CaS>
Project Member
Wed Jun 29 09:40:20 2016, 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 Jul 24 12:25:42 2014, 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 Jul 21 16:19:21 2014, 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 Jul 15 17:28:37 2014, 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 (3kB - 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 Apr 9 06:35:19 2017CaSStatusNone=>Fixed
      Open/ClosedOpen=>In Test
    Thu Jul 24 12:25:42 2014yavorAttached File-=>Added versioned-frameworks.patch, #31767

    Back to the top

    Powered by Savane 3.1-cleanup1