gnustep-gui build link dependency orders wrong

[Marcus Müller]

Hi all!

For a couple of weeks now I'm doing nightly builds of two of my pet projects via Jenkins on FreeBSD 9.1. In order to make sure to spot problems commited to GNUstep trunk which affect my programs as soon as they arise, I'm building and installing a version of GNUstep trunk in one of Jenkins' workspaces, which is isolated from the rest of the system, prior to building my own projects which link against this isolated GNUstep installation. It's pretty easy to achieve this with GNUstep (and has been so for a couple of years).

However it occurs that I've also installed a version of GNUstep in FHS layout to /usr/local. Recently, when doing system maintenance, I've accidentaly deleted a library required by /usr/local/lib/libgnustep-base.so, rendering this particular installation of GNUstep unusable.

When the automated nightly build started, it failed for a rather unexpected (but obvious) cause:

--- snip ---

[…]

Making all for service GSspell...

/usr/local/bin/clang33 GSspell.m -c \

      -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -fobjc-nonfragile-abi -D_NONFRAGILE_ABI -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -fgnu-runtime -fconstant-string-class=NSConstantString -I/usr/local/include/libpng15 -I../Headers/Additions -I../Headers -I../Source/. -I. -I/usr/local/include -I/root/GNUstep/Library/Headers -I/usr/local/jenkins/workspace/GNUstep_trunk/GNUSTEP_ROOT/Local/Library/Headers -I/usr/local/jenkins/workspace/GNUstep_trunk/GNUSTEP_ROOT/System/Library/Headers \

       -o obj/GSspell.obj/GSspell.m.o

/usr/local/bin/clang33  -rdynamic      -pthread -fexceptions -fobjc-nonfragile-abi -fgnu-runtime -o GSspell.service/./GSspell \

./obj/GSspell.obj/GSspell.m.o   -L/usr/local/lib  -licui18n -licuuc -licudata  -L/usr/local/lib -lpng15    -L../Source/./obj -L../Model/./obj    -L/root/GNUstep/Library/Libraries -L/usr/local/jenkins/workspace/GNUstep_trunk/GNUSTEP_ROOT/Local/Library/Libraries -L/usr/local/jenkins/workspace/GNUstep_trunk/GNUSTEP_ROOT/System/Library/Libraries  -L/usr/local/lib   -lgnustep-gui -lgif -lpng -ltiff -lz -ljpeg -lm   -lgnustep-base    -lobjc   -lm

/usr/bin/ld: warning: libgnutls.so.47, needed by /usr/local/lib/libgnustep-base.so, not found (try using -rpath or -rpath-link)

[…]

--- snap ---

Instead of linking against gnustep-base.so installed in /usr/local/jenkins/workspace/GNUstep_trunk/GNUSTEP_ROOT/Local/Library/Libraries, it links against the (defunct) version installed in /usr/local/lib. The obvious culprit is the link order, which should be (according to my understanding):

-L../Source/./obj -L../Model/./obj  -L/root/GNUstep/Library/Libraries -L/usr/local/jenkins/workspace/GNUstep_trunk/GNUSTEP_ROOT/Local/Library/Libraries -L/usr/local/jenkins/workspace/GNUstep_trunk/GNUSTEP_ROOT/System/Library/Libraries  -L/usr/local/lib

However, it seems that dependencies are inserted in the order they are checked for at configure time, which introduces /usr/local/lib way too early and hence leads to this undesirable (and fatal) side effect.

I've stared at the gnustep-make makefiles for some time now but don't understand where to fix the problem at all. Can anyone more familiar with the architecture of these makefiles (Nicola, Richard?) please step in?

P.S.: the same problem holds true for the include order, although it doesn't show up here in this particular case.

Thanks in advance,

  Marcus

--

Marcus Müller  .  .  .  http://www.mulle-kybernetik.com/znek/