Sun 22 Feb 2009 08:31:11 PM UTC, comment #12:
on netbsd 4.0.1 x86 I get for /usr/lib/libobjc.so
multix lib > nm libobjc.so | grep -i thre
0000f474 T __objc_close_thread_system
0000f468 T __objc_init_thread_system
00015648 B __objc_is_multi_threaded
000155f0 D __objc_runtime_threads_alive
0000f480 T __objc_thread_detach
0000f4a8 T __objc_thread_exit
00015644 B __objc_thread_exit_status
0000f4dc T __objc_thread_get_data
0000f494 T __objc_thread_get_priority
0000f4b4 T __objc_thread_id
0000f4c0 T __objc_thread_set_data
0000f488 T __objc_thread_set_priority
0000f4a0 T __objc_thread_yield
0001564c B _objc_became_multi_threaded
00009d04 T objc_set_thread_callback
0000a044 T objc_thread_add
0000a21c T objc_thread_detach
0000a184 T objc_thread_exit
0000a148 T objc_thread_get_data
0000a1e0 T objc_thread_get_priority
00009d94 T objc_thread_id
0000a008 T objc_thread_remove
0000a164 T objc_thread_set_data
0000a1fc T objc_thread_set_priority
0000a1c4 T objc_thread_yield
so I suppose it is not linked against pthread and netbsd supplies a worse runtime than previous evrsion. The strange part is that it is correclty built with threads enabled, so maybe it is a gcc bug. Let's hope in the next version. It also means that packagers need to package libobjc as well. It should do no harm on previous netbsd evrsions I suppose, our libobjc should always work...
|
Thu 19 Feb 2009 03:22:42 PM UTC, comment #11:
doh, on OpenBSD, everything seems to be fine.
The thread problem only seems to happen, when I have gobjc from gcc-4.2 installed. This only has the following symbols:
nm /usr/local/lib/libobjc.so.2.0 | grep thre
0000ee44 T __objc_close_thread_system
0000ee38 T __objc_init_thread_system
20006ab8 B __objc_is_multi_threaded
20002770 D __objc_runtime_threads_alive
0000ee50 T __objc_thread_detach
0000ed68 t __objc_thread_detach_function
0000ee78 T __objc_thread_exit
20006ab4 B __objc_thread_exit_status
0000eeac T __objc_thread_get_data
0000ee64 T __objc_thread_get_priority
0000ee84 T __objc_thread_id
0000ee90 T __objc_thread_set_data
0000ee58 T __objc_thread_set_priority
0000ee70 T __objc_thread_yield
20006abc B _objc_became_multi_threaded
0000e7a0 T objc_set_thread_callback
0000eae0 T objc_thread_add
0000ecb8 T objc_thread_detach
0000ec20 T objc_thread_exit
0000ebe4 T objc_thread_get_data
0000ec7c T objc_thread_get_priority
0000e830 T objc_thread_id
0000eaa4 T objc_thread_remove
0000ec00 T objc_thread_set_data
0000ec98 T objc_thread_set_priority
0000ec60 T objc_thread_yield
20006ac0 b thread_local_storage
obviously, my problem that I reported here:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=25037
I had linked against the wrong libobjc, because I still have this problem reported here:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=25536
So in short, this particular problem doesn't really exist on OpenBSD, sorry for the noise here.
|
Thu 19 Feb 2009 01:44:24 PM UTC, comment #10:
Yes, all those undefined pthread_... synbols show that your openbsd system has libobjc linked with a pthread library.
I know the configure script checks for that ... so if it's not working the most likely issue is that your pthread library is missing (or in a location not found by the linker) or has dependencies itsself on another library we are not linking.
Investigating this ought to be fairly easy ... you just try building the little objc test program used by configure, add flags to link the appropriate libraries, and examine the libraries to find any dependencies they hae, and add those new libraries to the list to be linked.
Once you know the set of libraries used and the order they need to be linked in, you can provide a patch to the gnustep-make configure script so that it will be able to get a working threaded runtime.
|
Thu 19 Feb 2009 01:02:40 PM UTC, comment #9:
On OpenBSD i seem to have the same problem, usually -lpthread is used.
I checked the system libobjc, a ldd only shows me this:
ldd /usr/lib/libobjc.so.4.0
/usr/lib/libobjc.so.4.0:
Start End Type Open Ref GrpRef Name
0e4d9000 2e4df000 dlib 1 0 0 /usr/lib/libobjc.so.4.0
but I find pthread related symbols in it:
# nm libobjc.so.4.0 | grep -i thre
000097d8 T __objc_close_thread_system
00009770 T __objc_init_thread_system
2000217c D __objc_is_multi_threaded
200027d4 D __objc_runtime_threads_alive
00009824 T __objc_thread_detach
00004838 t __objc_thread_detach_function
00009894 T __objc_thread_exit
20002178 D __objc_thread_exit_status
00009904 T __objc_thread_get_data
0000986c T __objc_thread_get_priority
000098b4 T __objc_thread_id
000098d0 T __objc_thread_set_data
00009860 T __objc_thread_set_priority
00009878 T __objc_thread_yield
20002180 D _objc_became_multi_threaded
20005bc4 b _objc_thread_attribs
20005bc0 b _objc_thread_storage
00004814 T objc_set_thread_callback
00004dc8 T objc_thread_add
000048ec T objc_thread_detach
000049e0 T objc_thread_exit
00004a5c T objc_thread_get_data
000049a8 T objc_thread_get_priority
00004a20 T objc_thread_id
00004e0c T objc_thread_remove
00004a3c T objc_thread_set_data
00004988 T objc_thread_set_priority
000049c4 T objc_thread_yield
U pthread_attr_destroy
U pthread_attr_init
U pthread_attr_setdetachstate
U pthread_cond_broadcast
U pthread_cond_destroy
U pthread_cond_init
U pthread_cond_signal
U pthread_cond_wait
U pthread_create
U pthread_exit
U pthread_getspecific
U pthread_key_create
U pthread_key_delete
U pthread_mutex_destroy
U pthread_mutex_init
U pthread_mutex_lock
U pthread_mutex_trylock
U pthread_mutex_unlock
U pthread_self
U pthread_setspecific
so I guess it should support threading.
|
Thu 19 Feb 2009 10:53:08 AM UTC, comment #8:
Possibly the standard netbsd gcc4 libobjc just doesn't support threads. have you checked that?
|
Thu 19 Feb 2009 10:49:00 AM UTC, comment #7:
using our libobjc solves the problem, yet I'd like to understand why we don't detect/work with the standard netbsd gcc4 libobjc.
|
Wed 18 Feb 2009 03:17:17 PM UTC, comment #6:
I removed the whole /usr/GNUstep, just to be sure I did not have some libobjc lying around.
The problme is indeed the failing test, I copied the relevant piece of the log and I do not understand why -lpthread fails.
In the other attempts of configure, where other libraries get tested, I clearly see the linking failure.
Furthermore, thhis bxo has the same compiler as one year ago, when it used to work... I do not understand.
I tried installing our libobjc and rerunning base tests and not lpthread gets picked up (did not verifiy yet if this solves also the bug in question). Yet I do wonder if it is really necessary, I hope it is not, or the netbsd packages would need to package and install also libobjc.
|
Tue 17 Feb 2009 08:12:39 AM UTC, comment #5:
Maybe I have the same problem on OpenBSD 4.4 i386 as reported in bug #25037.
I did ran the tests from the testsuite, and all tests regarding threads did fail on i386, for the same reason, unable to detach thread.
|
Tue 17 Feb 2009 06:22:23 AM UTC, comment #4:
It seems to me that the critical part in the output you quote is:
checking whether objc has thread support... no
I'm pretty sure that's from the gnustep-make configure (and base gets the information from make) to determine the threading in use.
Looking at configure.ac for gnustep-make, it seems that it tries a variety of options of linker flags to get threading working, but it's possible that none of those work on your system (it's also possible that a non-threaded objc library is being picked up even though the gcc version in use was compiled for threading).
You could check to see how many libobjc's you have installed, and eliminate possibilities to make sure there's only one. You could then examine that libobjc to see what it's linked with and figure out the threading flags needed (or if it really doesn't support threading, replace it with one that does).
|
Mon 16 Feb 2009 10:39:09 PM UTC, comment #3:
indeed, I get:
checking for custom shared objc library... NONE
checking whether objc has thread support... no
checking whether we should use native ObjC exceptions... not requested by user
checking for the GCC version... version: 4.1
but it is very strange not to have threads?
The gcc options seen in configure are:
Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=i386-unknown-netbsdelf4.99.3 --host=i386--netbsdelf --target=i386--netbsdelf
the correct flag for netbsd is -lpthread I believe, the test of which is:
configure:5739: gcc -o conftest -g -O2 -x objective-c -I. -fgnu-runtime -DGNU_RUNTIME conftest.c -lobjc -lpthread >&5
In file included from conftest.c:8:
config_thread.m:7: warning: incomplete implementation of class 'NXConstantString'
config_thread.m:7: warning: method definition for '-length' not found
config_thread.m:7: warning: method definition for '-cString' not found
configure:5742: $? = 0
configure:5748: ./conftest
configure:5751: $? = 255
configure: program exited with status 255
configure: failed program was:
what's wrong? I see only warnings...
|
Fri 22 Aug 2008 03:04:53 PM UTC, comment #2:
it is stock netbsd 4.0 with gcc 4.1.2.
It works on my older netbsd 2.0 on sparc.
How can I know how my runtime is configured?
Maybe I should try installing our libobjc and then reconfiguring adn installing base?
|
Thu 21 Aug 2008 06:28:04 AM UTC, comment #1:
That's just reporting that the runtime function objc_thread_detach() returned a failure value (zero) ... so it's probably a gcc/runtime bug rather than a GNUstep one.
Possibly you are somehow linking with a single threaded version of the runtime though?
|
Wed 20 Aug 2008 11:19:29 PM UTC, original submission:
On x86-32, Netbsd 4.0 I get the following error when starting up FTP (current CVS version with threads):
(gdomap is up and running as root)
2008-08-21 01:20:40.478 FTP[9696] Problem posting notification: <NSException: 0x85285a8> NAME:NSInternalInconsistencyException REASON:Unable to detach thread (last error Undefined error: 0) INFO:(nil)
the application is non functional and needs to be killed.
|