Fri 22 Jul 2005 11:53:33 AM UTC, comment #22:
Well if you get a segmentation fault in pthread_init() then at first galnce it looks like an issue with your pthreads implementation and it's probably best to report the bug there.
If you can supply source and debug versions of your pthread implementation (and libobjc), the best thing would be to debug it with gdb 6+. Otherwise we can only guess what may be happening. You can contact me privatly if you can supply the above and ssh access, if you don't feel comfortable debuging yourself.
And please open a new bug report (or in this as, it doesn't seem to be related directly to GNUstep you can simple send a message to bug-gnustep@) rather than attaching messages to old reports that are not directly related to your issue.
|
Fri 22 Jul 2005 10:45:57 AM UTC, comment #21:
i'm getting problem with Segmentation fault in pthread_init(). it does not load my program. i'm trying to execute MPI application. during compilation i've linked all the necessary libraries(including -lpthread). this problem i'm facing on AIX-5.1 and AIX-5.3....
can some one suggest me the solution
|
Thu 14 Jul 2005 02:27:36 AM UTC, comment #20:
I applied ayers' make.patch to a fresh cvs "make" .. but the configure causes a "sigsegv" in the objc-threading detection making it believe threading is not supported in objc.
If interested i Can provide the config.log for that session as well .. just let me know.
I would love to hand out access to my FreeBSD/amd64 machine ... but i am behind a linksys router ... i guess i Could try to fiddle a bit with port-forwarding and all .. to see if i can somehow make external access possible.
|
Wed 13 Jul 2005 03:35:35 PM UTC, comment #19:
> And Once Again ... i am experiencing the Exact Same Crash Bugs
Thanks ... :-(
... very likely the bug you are experiencing is a different one!
I would suggest you open a new bug, and in it describe exactly what problems you are having (include as many details as possible, remember most of us don't have freebsd [even less freebsd on amd64] so we can't really test anything, we're just blind guessing from what is reported) ... then we can try to fix that one as well. :-)
Thanks!
|
Wed 13 Jul 2005 09:24:59 AM UTC, comment #18:
I must say that current CVS, "with patch" everything works fine for me. It may not be the best solution, but I compiled -make, -base, -gui and -back (after reconfiguring everything), I recompiled gworkspace and it works fine. I tried to run Gorm and FTP and they too seem to work. I did not do further tests but i didn't experience crashes.
I am on freebsd 5.3 with ia32 though.
|
Wed 13 Jul 2005 09:09:55 AM UTC, comment #17:
Hello Pascal,
You could attach :
a new config.log and the output of:
gmake messages=yes
to the bug report (after a gmake clean). But I have the feeling that anything short of access to a box on which we can reproduce the issues will be inefficient.
I achieved successful test results on Ricardo's i386-unknown-freebsd5.3 yesterday so I assume that we get lucky with -pthread on that architecture but possibly not on amd64-unknown-freebsd7.0 (which is what you seem to be using according to the config.log you sent me privatly). Also I'm not sure whether GNUstep currently supports any 64-bit architectures.
Personally, I think it is probably wrong to be using -pthread for FreeBSD ELF (and possibly for any platform) and we should use the standard -lpthread mechanisms.
So maybe you could try the following patch, reconfigure -make, install -make, source GNUstep.(c)sh, reconfigure -base, install -base. (But I must admit that I haven't had a chance to test it on i386-unknown-freebsd5.3 yet.) OTOH, you may be experiencing 64-bit issues totally unrelated to pthreads.
|
Wed 13 Jul 2005 01:44:58 AM UTC, comment #16:
I just did an "rm -Rf /usr/local/GNUstep" followed by a completely fresh cvs checkout of GNUstep-cvs .. did a fresh build of make and base ..
And Once Again ... i am experiencing the Exact Same Crash Bugs
I don't know exactly How the testing of the proposed patches here was done ... but apparently either I am doing something wrong ... or the applied "patch" doesn't actually fix the problem after all.
Please let me know if there is anything i can do here ....
|
Tue 12 Jul 2005 02:26:42 PM UTC, comment #15:
Thanks. I'm closing this bug as the 'high priority' issue of having GNUstep compile on FreeBSD should be fixed now. :-)
I agree maybe -pthread is not the best way to deal with threads on FreeBSD (also check Pete's recent email about this), but this probably deserves a separate discussion! :-)
Thanks
|
Tue 12 Jul 2005 02:21:28 PM UTC, comment #14:
Yes indeed that seems to work now. But a note on the side:
A quick search through the gcc manaul reveals that the -pthread option is only documented for RS/6000 and PowerPC (and -pthreads for SPARC)
`-pthread'
Adds support for multithreading with the "pthreads" library. This
option sets flags for both the preprocessor and linker.
I'm currently assuming this is a mere convenience flag. Not sure why it works on i386-unknown-freebsd5.3 but we may just be getting lucky (or gcc's docs are outdated). Does anyone know if using this flag instead of the normal machinery actually has merits?
|
Tue 12 Jul 2005 01:59:38 PM UTC, comment #13:
Cool... thanks ... what about setting INTERNAL_LDFLAGS too then, that is --
+##
+## The -pthread flag must be passed to all compilation/link commands.
+##
+ifeq ($(objc_threaded), -pthread)
+ INTERNAL_CFLAGS += -pthread
+ INTERNAL_OBJCFLAGS += -pthread
+ INTERNAL_LDFLAGS += -pthread
+endif
That should hopefully work :-)
Thanks for your help
|
Tue 12 Jul 2005 01:23:05 PM UTC, comment #12:
Well -base compiles but the Testsuite fails to build the tools as it seems that the flag will be needed all projects:
ayers@saruman$ gmake messages=yes
Making all for test_tool general...
gcc -rdynamic -o shared_obj/general \
./shared_obj/general.o \
-L/home/ayers/GNUstep/Library/Libraries -L/home/ayers/GNUstep/Local/Library/Libraries -L/home/ayers/GNUstep/System/Library/Libraries -L/usr/local/lib -lgnustep-base
/home/ayers/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `pthread_attr_destroy'
/home/ayers/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `pthread_create'
/home/ayers/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `pthread_attr_init'
/home/ayers/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `pthread_exit'
/home/ayers/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `pthread_getschedparam'
/home/ayers/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `pthread_setschedparam'
/home/ayers/GNUstep/System/Library/Libraries/libgnustep-base.so: undefined reference to `pthread_attr_setdetachstate'
gmake[1]: *** [shared_obj/general] Error 1
gmake: *** [general.all.test-tool.variables] Error 2
|
Tue 12 Jul 2005 12:13:12 PM UTC, comment #11:
I don't have a freebsd system but it looks like the following patch should fix it --
Index: target.make
===================================================================
RCS file: /cvsroot/gnustep/gnustep/core/make/target.make,v
retrieving revision 1.168
diff -u -r1.168 target.make
--- target.make 22 May 2005 03:20:14 -0000 1.168
+++ target.make 12 Jul 2005 12:11:30 -0000
@@ -575,7 +575,6 @@
BUNDLE_LDFLAGS += -shared
ADDITIONAL_LDFLAGS += -rdynamic
STATIC_LDFLAGS += -static
-
endif
#
# end Linux ELF
@@ -654,6 +653,14 @@
BUNDLE_LDFLAGS += -shared
ADDITIONAL_LDFLAGS += -rdynamic
STATIC_LDFLAGS += -static
+
+##
+## The -pthread flag must be passed to all compilation/link commands.
+##
+ifeq ($(objc_threaded), -pthread)
+ INTERNAL_CFLAGS += -pthread
+ INTERNAL_OBJCFLAGS += -pthread
+endif
endif
endif
#
Let me know if it works.
Thanks
|
Tue 12 Jul 2005 11:49:33 AM UTC, comment #10:
Actually the Testsuite/base produces pretty good results if I set:
objc_threaded:=-lpthread
101 COMPLETED
9 FAIL
2397 PASS
BTW: Where does POSIX require pthread_init() to be called? In fact it seems that this function is not exported on many platforms. It is not described in the online POSIX documentation (for registered users):
http://www.unix.org/single_unix_specification/
|
Tue 12 Jul 2005 11:11:13 AM UTC, comment #9:
It is actually unclear to me why -base should try to work with pthreads directly. I would expect it to strictly work with the objc_thread functions. I believe the reason why it happens to work most of the time is because objc is commonly configured to use pthreads. But maybe we need to work around some issues...
But the issue seems to lay in the fact that on FreeBSD the prefered way that our configure script wants to link in the pthread library is -pthread (instead of -lpthread or lcpthread which are only fallbacks in configure.ac). So -make's config.make contains:
objc_threaded:=-pthread
which is added to AUXILIARY_OBJC_LIBS but this is later filtered through Intstance/<projecttype>.make:
LIBRARIES_DEPEND_UPON += $(filter-out -l$(LIBRARY_NAME_WITHOUT_LIB), \
... $(AUXILIARY_OBJC_LIBS) ...
OK, so much for the linking... I'll leave it up to the -make maintainers and maybe some FreeBSD user feedback about the merits of using -pthread vs. -lpthread and whether we need special handling for -pthread or whether we need to fix our configure script.
I'll try to look at the runtime issue now...
|
Tue 12 Jul 2005 01:28:27 AM UTC, comment #8:
Updated severity to Blocker, since this is preventing users on FreeBSD from being able to compile GNUstep. GJC
|
Tue 12 Jul 2005 01:20:27 AM UTC, comment #7:
The reason the -pthread "fix" is crap is because since libgnustep-base itself never explicitely gets linked against libpthread ... "pthread_init()" is never called as it is supposed to according to POSIX ... As a result libobjc tries do its own thread-related initialization and as a result causes a SIGSEGV.
|
Sat 09 Jul 2005 05:34:17 AM UTC, comment #6:
I have narrowed it down to this change:
(ChangeLog extract)
2005-06-06 Adam Fedor <fedor@gnu.org>
- Instance/application.make (ALL_GUI_LIBS): Remove OBJC_LIBS,
AUXILIARY_OBJC_LIBS, and TARGET_SYSTEM_LIBS
- Instance/gswapp.make (ALL_GSW_LIBS): Idem.
- Instance/service.make (ALL_SERVICE_LIBS): Idem.
- Instance/test-library.make (ALL_TEST_LIBRARY_LIBS): Idem.
- Instance/tool.make (ALL_TOOL_LIBS): Idem.
Fixes bug #9920.
Pulling the code before this modification works properly on FreeBSD. After this change, it fails. GJC
|
Sat 09 Jul 2005 04:40:11 AM UTC, comment #5:
I did the following to get the last release of make:
cvs update -dPCA -rmake-1_10_0
Using this version of make does not encounter the problem described earlier. This implies that it is a change made between the last release and now which is responsible for this issue.
I believe that it is specifically, the correction for bug #9920 which is causing the issue. More information to follow.
GJC
|
Thu 07 Jul 2005 09:57:17 PM UTC, comment #4:
yes, I did a -base build but I soured the GNUstep.csh file of the release make and not current CVS. Indeed, now -base compiles and installs and some basic tests run, thus it is a -make problem
|
Wed 06 Jul 2005 06:15:57 AM UTC, comment #3:
One thought ... maybe this is a problem in the make package rather than the base library ... if it's just failing to link a library, that sounds like a strong possibility.
I don't have your operating system, so all I can do is advise ...
Can you fix things by rebuilding everything using an earlier version of the make package? If so, you can do a binary search to find the exact date that a change was made which caused the problem ... and we could examine the changes to try to find/fix it.
If changing the make package version does not fix things, you could do the same thing by getting the base library from CVS and finding the day on which the change was made which broke things.
All that being said ... I do have one guess from looking at the ChangeLog of the make package. The linking was changed to fix bug #9920 recently ... this is basically to prevent libraries being linked into things where they are not needed because they are already linked in to other libraries such as the base library. However there is at least one system (windows) which has a problem in that the linker requires libraries to be explicitly relinked at every stage. Perhaps there is a similar problem on your system?
|
Mon 20 Jun 2005 02:27:20 PM UTC, comment #2:
the exact error (and link line when using gmake messages=yes) is:
gcc -rdynamic -o shared_obj/autogsdoc \
./shared_obj/autogsdoc.o ./shared_obj/AGSParser.o ./shared_obj/AGSOutput.o ./shared_obj/AGSIndex.o ./shared_obj/AGSHtml.o \
-L../Source/./shared_obj -L/home/multix/GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -L/usr/local/lib -lgnustep-base
../Source/./shared_obj/libgnustep-base.so: undefined reference to `pthread_attr_destroy'
../Source/./shared_obj/libgnustep-base.so: undefined reference to `pthread_create'
../Source/./shared_obj/libgnustep-base.so: undefined reference to `pthread_attr_init'
../Source/./shared_obj/libgnustep-base.so: undefined reference to `pthread_exit'
../Source/./shared_obj/libgnustep-base.so: undefined reference to `pthread_getschedparam'
../Source/./shared_obj/libgnustep-base.so: undefined reference to `pthread_setschedparam'
../Source/./shared_obj/libgnustep-base.so: undefined reference to `pthread_attr_setdetachstate'
gmake[2]: *** [shared_obj/autogsdoc] Error 1
shouldn't be there a -pthread flag ?
my config.make has:
ifndef objc_threaded
objc_threaded:=-pthread
endif
|
Fri 17 Jun 2005 12:37:28 PM UTC, comment #1:
the problem is more serious than thought. The -lpthread fix is just crap, since it compiles and links (but make configure detected pthreads correctly...)
and also gnustep is unusable, gdnc and plink just segfault... renderinng further tests impossible.
|
Wed 15 Jun 2005 09:14:46 PM UTC, original submission:
autogsdoc and make_strings fail to link, addinf -lpthread to the LDFLAGS fixes the problem.
This wasn't necessary in the past. I have recvonfigured and reinstalled core-make and was building core-base.
Thus I guess something in the pthread detection/linking or the makefiles has gone wrong.
|