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 [EMAIL PROTECTED] _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
