config problem in gnustep-make

[Stephen Brandon]

Hi,

This problem only recently reared its head for me today; I think it's because 
of getting rid of some old versions of libobjc that I didn't want. I got rid 
of libobjc as provided by various versions of gcc I had been using, in favour 
of the one obtained from gnustep.org.

Platform: linux/ix86

Problem: "configure" in gnustep-make does not pick up the libobjc as 
installed by the libobjc package on gnustep.org.

This is because libobjc installs in  
/usr/GNUstep/System/Libraries/ix86/linux-gnu/gnu-gnu-gnu, whereas 
gnustep-make/configure only looks for it as $GNUSTEP_LDIR/libobjc.so (or .a), 
instead of $GNUSTEP_LDIR/$LIBRARY_COMBO/libobjc.so which 
gnustep-base/configure.in looks at.

This ends up having several implications: one of them being that the check 
for the threading backend check fails "checking whether objc has thread 
support" because there's no path given to find the objc library (nothing to 
do with the pthread library at all).

The easy way to fix this (I think) is to do what's done in base/configure.in, 
and set LDFLAGS="$LDFLAGS -L$GNUSTEP_LDIR/$LIBRARY_COMBO -L$GNUSTEP_LDIR", 
but there's a comment just before the libobjc check in 
gnustep-make/configure.in which seems to suggest it's not good to do this for 
some reason: 

# Check to see if the libobjc library is in our GNUSTEP_SYSTEM_ROOT.
# If so, there are probably other libraries that we want there also, so
# leave the proper includes in CPPFLAGS and LDFLAGS

Could I suggest changing the LDFLAGS temporarily to solve the hunt for 
threading libraries (problem #1), and a more intelligent check for libobjc 
(hard coded check for $GNUSTEP_LDIR/$LIBRARY_COMBO/libobjc.so as well as for 
$GNUSTEP_LDIR/libobjc.so) (problem #2)?

Cheers,
Stephen Brandon
stephen@brandonitconsulting.co.uk