Tue 22 Jun 2010 07:41:44 AM UTC, comment #11:
Just mentioning that 1.20.1 built successfully on Debian's kfreebsd-i386 and kfreebsd-amd64 autobuilders.
|
Fri 18 Jun 2010 09:24:10 AM UTC, comment #10:
The configure seems to work for me on GNU/HURD, GNU/Linux (Debian and Gentoo), Windows/mingw and FreeBSD 8.0.
I close the bug and will test other platfoms in the coming days (OpenBSD, Solaris, NetBSD)
|
Sun 13 Jun 2010 10:46:49 PM UTC, comment #9:
Unfortunately I won't be able to confirm that the failure is fixed on GNU/kFreeBSD until gnustep-base 1.20.x is uploaded to Debian (either with the upstream fix, or the same as a Debian patch). It's like a chicken and egg problem for us...
So do whatever you think is right, and I'll followup later here with the result.
|
Sun 13 Jun 2010 07:22:25 AM UTC, comment #8:
I'd like to make a bugfix release of the base library (1.20.1) with all the recent changes, and this issue is the thing that's holding it up.
I've applied all the latest changes to the stable branch in svn so that things can be tried out easily.
Please let me know how you get on.
|
Sat 12 Jun 2010 07:23:42 AM UTC, comment #7:
I agree with Yavor that it makes sense to remove all the cruft from our sourcecode and rely on autoconf to do the hard work for us. So I've manually (hope I didn't make any mistake) applied the supplied patch to svn trunk to let us try it.
If it doesn't work out, we can always revert back.
|
Fri 11 Jun 2010 09:33:52 PM UTC, comment #6:
I modified the remaining files, it works for me on HURD. Let's keep the bug in test, for some time so that people have time to build on their machines.
It would be nice if you can arrange a test on kFreeBSD.
|
Fri 11 Jun 2010 06:48:02 AM UTC, comment #5:
Strange, but if that works, OK.
There are 3 more places where this condition needs to be changed, could you please do that?
GSPThread.h, NSLock.m, NSZone.m
|
Fri 11 Jun 2010 12:04:14 AM UTC, comment #4:
added both _GNU_ and _GLIBC_
seems to work on my platfosm.
|
Thu 10 Jun 2010 11:01:54 PM UTC, comment #3:
On which Solaris version/machine? _GLIBC_ should have zero effect on any non-GNU platform...
Does it help if you use AC_USE_SYSTEM_EXTENSIONS and remove all manually crafted defines? (This is the autoconf (almost) bullet-proof way for dealing with this particular problem.)
A second, less capable solution is to use
_linux_ || _GNU_ || _FreeBSD_kernel_
but that would need adjustments as time goes by...
|
Thu 10 Jun 2010 09:00:46 PM UTC, comment #2:
this fix breaks compilation on Solaris again, glibc is a mess, the _GLIBC_ check is not enough and not inconditionally valid.
|
Wed 09 Jun 2010 01:26:42 PM UTC, comment #1:
Thanks, I applied that fix.
|
Wed 09 Jun 2010 11:38:36 AM UTC, original submission:
1.20.0 fails to build on GNU/kFreeBSD with the following error:
gcc sync.m -c \
-MMD -MP -Wall -Wdeclaration-after-statement -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -fgnu-runtime -fgnu-runtime -fconstant-string-class=NSConstantString -I../../Headers/Additions -I../. -I../ -I../../Headers -I. -I/usr/include/GNUstep -I/usr/local/include/GNUstep -I/usr/local/include/GNUstep -I/usr/include/libxml2 -I/usr/include -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
-o obj/ObjectiveC2.obj/sync.m.o
sync.m: In function 'initLockObject':
sync.m:87: warning: implicit declaration of function 'pthread_mutexattr_settype'
sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this function)
sync.m:87: error: (Each undeclared identifier is reported only once
sync.m:87: error: for each function it appears in.)
make[5]: *** [obj/ObjectiveC2.obj/sync.m.o] Error 1
Trivial patch attached.
GNU libc supports several kernels: Linux, GNU Mach+Hurd, kFreeBSD and (unofficially) kOpenSolaris. So the correct check in this case is for the symbol _GLIBC_, which is guaranteed to be defined on all glibc-based platforms.
Perhaps it's worth to leave _linux_ for the rare cases when another libc is used with Linux (uClibc, dietlibc, etc.), although I'm not sure if the GNUstep stack works on those systems at all.
Thanks.
|