bugGNUstep - Bugs: bug #42423, base.make errouneously pollutes...

Group
 
 

bug #42423: base.make errouneously pollutes CONFIG_SYSTEM_* variables

Submitter:  Yavor Doganov <yavor>
Submitted:  Sun 25 May 2014 10:38:46 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Post a Comment

Add a New Comment Rich Markup
   

Discussion

Sun 13 Jul 2014 11:28:25 AM UTC, comment #2: 


> That change was to avoid conflicting library versions
> being linked into base and gui ...


I see.  The way to address this problem is to take care to relink all reverse dependencies of the library.  Which I agreee is a bit tedious and even error prone if you install everything manually.

> I don't really know/understand the benefits of explicitly
> specifying the libraries


There is no benefit at all.  If program foo links dynamically with libA which dynamically links with libB, there is no good reason for foo to link with libB (unless the dynamic linker is not capable of loading the DSOs in which case the last resort would be static linking).  Imagine if libB is being linked with libC and libD, and libD is linked with libE...  Shared libraries are ubiquitous nowadays so a system would easily become unmaintainable mess if one does that.  For this reason, almost all binary-based distros delete libtool .la files or at least empty their dependency_libs field.  The GNUstep core libraries have been doing a great job on this front by keeping their external library dependencies unexposed.

Yavor Doganov <yavor>
Sun 13 Jul 2014 07:28:32 AM UTC, comment #1: 

That change was to avoid conflicting library versions being linked into base and gui ... but I guess easing building in a sandbox for packaging is more important.
Beyond that, I don't really know/understand the benefits of explicitly specifying the libraries, so I'll trust your opinion  ... at least until/unless others complain.
Thanks.

Richard Frith-Macdonald <CaS>
Group Member
Sun 25 May 2014 10:38:46 PM UTC, original submission:  

This change

http://svn.gna.or ... amp;pathrev=37409

is clearly wrong.  You don't really want everything that uses Base to be linked with ICU, Avahi, GnuTLS, libxslt, libffi, etc.    I don't really understand the rationale for removing the make conditional -- if GUI needs ICU (as it does), it needs to check for ICU itself (as it does).  There's no need for Base to impose the libraries it uses to other packages.  Furthermore, literally everything fails to build if built in a chroot or with special linker flags, for example Cynthiune:

gcc -shared  -rdynamic     -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -Wl,-rpath,/usr/lib/cynthiune.app -pthread -shared-libgcc -fexceptions -o ./MP3.format/./MP3 ./obj/MP3.obj/xing.c.o ./obj/MP3.obj/MP3.m.o      -L/usr/local/lib -L/usr/lib   -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed -L/usr/local/lib -L/usr/local/lib -L/usr/lib -L/usr/lib/x86_64-linux-gnu  -lmad  -lid3tag -lz    -L../../Frameworks/Cynthiune/Cynthiune.framework/Versions/Current -lCynthiune   -lgnustep-gui    -lgnustep-base    -lobjc   -lavahi-common -lavahi-client  -lgnutls  -lgcrypt -lxslt -lxml2 -lffi  -lrt -ldl  -lpthread -lz -licui18n -licuuc -licudata  -lm
/usr/bin/ld: cannot find -lavahi-common
/usr/bin/ld: cannot find -lavahi-client
/usr/bin/ld: cannot find -lxslt
/usr/bin/ld: cannot find -lffi
collect2: error: ld returned 1 exit status
/usr/share/GNUstep/Makefiles/Instance/bundle.make:205: recipe for target 'MP3.format/./MP3' failed

Yavor Doganov <yavor>

 

Attached Files

This item currently has no attached files.

(Note: upload size limit is set to 4.0MiB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

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

    Votes

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

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

    History

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-07-13 CaS StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.16-2753.
    Corresponding source code