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/
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
