[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

Update of bug #29845 (project gnustep): Status:None => Fixed Open/Closed:Open => In Test ___ Follow-up Comment #7: Great idea about m

Re: [bug #30045] minor incompatibility in NSURL

Thanks again, Richard! Doug On Jun 8, 2010, at 10:54 AM, Richard Frith-Macdonald wrote: > > Update of bug #30045 (project gnustep): > > Status:None => Fixed > Open/Closed:Open => Closed > >

Re: [bug #30077] Unable to launch application on Windows

Okay, here's a bit more information: The crash occurs at line 779 of NSDistributedNotificationCenter.m in the _connect method. Watching the Windows Task Manager I can see that gdnc gets launched ok. The thing that may be different about our app is that this occurs when we call [NSDocumentContr

Re: [bug #30077] Unable to launch application on Windows

Unfortunately, I didn't indicate it before but I was at revision 30606 at the time. I just updated base to r30616 (from 30586) and the crash is back. I didn't think it was anything related to our app specifically, but I'll dig around some more and see what I can find. Doug On Jun 8, 2010, at 3

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

Update of bug #30094 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Thanks, I applied

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

Follow-up Comment #6, bug #29845 (project gnustep): seems like you could declare gnustep_base_user_main with __attribute__((weak)) which should allow it to continue building with -Wl,-z,defs ___ Reply to this item at:

[bug #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared

URL: Summary: (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared Project: GNUstep Submitted by: yavor Submitted on: Wed Jun 9 14:38:36 2010 Ca

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

Follow-up Comment #5, bug #29845 (project gnustep): > Ah ... so '-Wl,-z,defs -Wl,--as-needed' has a similar effect to '-Wl,--no-undefined' Almost; -Wl,-z,defs is another way of writing -Wl,--no-undefined. > the fake main mechanism requires the gnustep_base_user_main() function to be > undefine

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

Follow-up Comment #4, bug #29845 (project gnustep): Ah ... so '-Wl,-z,defs -Wl,--as-needed' has a similar effect to '-Wl,--no-undefined' In that case this is really not a bug ... the linker flags are telling the link to fail since the fake main mechanism *requires* the gnustep_base_user_main() f

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

Follow-up Comment #3, bug #29845 (project gnustep): No news, unfortunately. I'd be glad to provide a patch if I only knew what would be the correct fix... It seems that all platforms which use the GS_FAKE_MAIN hack are affected; on GNU/Linux you can reproduce the problem with ./configure --e

[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined

Follow-up Comment #2, bug #29845 (project gnustep): Any news on this? It would be nice to get a fix into a 1.20.1 release. Also, I looked at the URL https://buildd.debian.org/fetch.cgi?pkg=gnustep-base&arch=hurd-i386&ver=1.19.3-2&stamp=1273445079&file=log&as=raw I can't claim to fully understan