bugGNUstep - Bugs: bug #13413, pthread link failure on freebsd 5.3

Group
 
 

bug #13413: pthread link failure on freebsd 5.3

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Wed 15 Jun 2005 09:14:46 PM UTC
   
 
Category:  Makefiles Severity:  5 - Blocker
Item Group:  Bug Status:  Invalid
Privacy:  Public Assigned to:  nico
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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.

David Ayers <ayers>
Group Member
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

Anonymous
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.

Pascal Hofstee <caelian>
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!

Nicola Pero <nico>
Group Member
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.

Riccardo Mottola <rmottola>
Group Member
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.

David Ayers <ayers>
Group Member
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 ....

Pascal Hofstee <caelian>
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

Nicola Pero <nico>
Group Member
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?

David Ayers <ayers>
Group Member
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

Nicola Pero <nico>
Group Member
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

David Ayers <ayers>
Group Member
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

Nicola Pero <nico>
Group Member
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/


David Ayers <ayers>
Group Member
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...

David Ayers <ayers>
Group Member
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

Gregory John Casamento <gcasa>
Group administrator
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.


Pascal Hofstee <caelian>
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

Gregory John Casamento <gcasa>
Group administrator
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

Gregory John Casamento <gcasa>
Group administrator
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

Riccardo Mottola <rmottola>
Group Member
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?

Richard Frith-Macdonald <CaS>
Group Member
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

Riccardo Mottola <rmottola>
Group Member
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.

Riccardo Mottola <rmottola>
Group Member
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.

Riccardo Mottola <rmottola>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #3223:  config.log added by caelian (25KiB - text/x-log - config.log for a cvs make .. with ayers make.patch applied .. obviously objc-threading-detection breaks here)
file #3222:  gmake.cvs.out added by caelian (137KiB - application/octet-stream - output of a gmake messages=yes build from the same fresh "base" cvs build on FreeBSD/amd64 7.0-CURRENT)
file #3221:  config.log.cvs added by caelian (158KiB - application/octet-stream - config.log of a fresh plain CVS "base" configure using a fresh cvs make on FreeBSD/amd64 7.0-CURRENT)
file #3216:  make.patch added by ayers (10KiB - text/x-patch - Patch removing -pthread handling)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 11 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-07-22 ayers StatusNone Invalid
2005-07-14 caelian Attached File- Added config.log, #2704
2005-07-14 caelian Attached File- Added gmake.cvs.out, #2703
2005-07-14 caelian Attached File- Added config.log.cvs, #2702
2005-07-13 ayers Attached File- Added make.patch, #2697
2005-07-12 nico CategoryBase/Foundation Makefiles
    Assigned toNone nico
    Open/ClosedOpen Closed
2005-07-12 ayers CategoryMakefiles Base/Foundation
2005-07-12 nico CategoryBase/Foundation Makefiles
2005-07-12 gcasa Severity3 - Normal 5 - Blocker

Back to the top

Powered by Savane 3.13-758e.
Corresponding source code