-lpthread -lstdc++ crashes on IRIX 6.5

-lpthread -lstdc++ crashes on IRIX 6.5

[Peter O'Gorman]

Hi,

We're currently using gcc-4.4.

On IRIX 6.5, we get crashes if -lpthread is ordered before
-lstdc++ (warnings about "not used for resolving any symbol" removed
below):
% echo 'int main() {}' >a.cpp
% g++ a.cpp -lpthread; ./a.out; echo $?
zsh: segmentation fault (core dumped)  ./a.out
139
% g++ a.cpp -pthread; ./a.out; echo $? 
0
% g++ a.cpp -lstdc++ -lpthread; ./a.out; echo $?
0

With gcc-4.2.x we had a similar issue, but on Tru64, that seems to be
fixed in 4.4.5. We have not tried trunk yet, is the problem already
fixed there?

We're looking at reordering -lpthread to come after -lstdc++ by patching
cp/g++spec.c to fix this, but perhaps that is the wrong approach?

Thanks for any help,
Peter
-- 
Peter O'Gorman
pogma@thewrittenword.com

Re: -lpthread -lstdc++ crashes on IRIX 6.5

[Jonathan Wakely]

On 21 February 2011 18:10, Peter O'Gorman wrote:
> Hi,
>
> We're currently using gcc-4.4.
>
> On IRIX 6.5, we get crashes if -lpthread is ordered before
> -lstdc++ (warnings about "not used for resolving any symbol" removed
> below):
> % echo 'int main() {}' >a.cpp
> % g++ a.cpp -lpthread; ./a.out; echo $?
> zsh: segmentation fault (core dumped)  ./a.out
> 139
> % g++ a.cpp -pthread; ./a.out; echo $?
> 0
> % g++ a.cpp -lstdc++ -lpthread; ./a.out; echo $?
> 0
>
> With gcc-4.2.x we had a similar issue, but on Tru64, that seems to be
> fixed in 4.4.5. We have not tried trunk yet, is the problem already
> fixed there?
>
> We're looking at reordering -lpthread to come after -lstdc++ by patching
> cp/g++spec.c to fix this, but perhaps that is the wrong approach?

What if you use -D_REENTRANT as well as -lpthread?

Re: -lpthread -lstdc++ crashes on IRIX 6.5

[Peter O'Gorman]

On Tue, Feb 22, 2011 at 12:34:44AM +0000, Jonathan Wakely wrote:
> On 21 February 2011 18:10, Peter O'Gorman wrote:
> > % echo 'int main() {}' >a.cpp
> > % g++ a.cpp -lpthread; ./a.out; echo $?
> > zsh: segmentation fault (core dumped)  ./a.out
> > 139
> >
> > We're looking at reordering -lpthread to come after -lstdc++ by patching
> > cp/g++spec.c to fix this, but perhaps that is the wrong approach?
> 
> What if you use -D_REENTRANT as well as -lpthread?

It still crashes, but I understand why you asked - the above is a
compile and link. Here's the same thing with only a link step:

% g++ -pthread -c a.cpp
% g++ -pthread a.o -o a.out
% ./a.out
% g++ -D_REENTRANT -lpthread a.o -o a.out
% ./a.out
zsh: segmentation fault (core dumped)  ./a.out
% g++ -lstdc++ -lpthread a.o -o a.out
% ./a.out
% echo $?
0

We're rebuilding now with a modified g++spec.c (patched to reorder
-lpthread after -lstdc++), but still not sure that is the correct fix
for this.

Thank you,
Peter
-- 
Peter O'Gorman
pogma@thewrittenword.com

Re: -lpthread -lstdc++ crashes on IRIX 6.5

[Jonathan Wakely]

On 22 February 2011 00:49, Peter O'Gorman wrote:
> On Tue, Feb 22, 2011 at 12:34:44AM +0000, Jonathan Wakely wrote:
>> On 21 February 2011 18:10, Peter O'Gorman wrote:
>> > % echo 'int main() {}' >a.cpp
>> > % g++ a.cpp -lpthread; ./a.out; echo $?
>> > zsh: segmentation fault (core dumped)  ./a.out
>> > 139
>> >
>> > We're looking at reordering -lpthread to come after -lstdc++ by patching
>> > cp/g++spec.c to fix this, but perhaps that is the wrong approach?
>>
>> What if you use -D_REENTRANT as well as -lpthread?
>
> It still crashes, but I understand why you asked - the above is a
> compile and link. Here's the same thing with only a link step:
>
> % g++ -pthread -c a.cpp
> % g++ -pthread a.o -o a.out
> % ./a.out
> % g++ -D_REENTRANT -lpthread a.o -o a.out

the preprocessor option won't be used here

> % ./a.out
> zsh: segmentation fault (core dumped)  ./a.out
> % g++ -lstdc++ -lpthread a.o -o a.out
> % ./a.out
> % echo $?
> 0
>
> We're rebuilding now with a modified g++spec.c (patched to reorder
> -lpthread after -lstdc++), but still not sure that is the correct fix
> for this.

The reason I asked is that on most platforms -pthread does two things,
it uses -D_REENTRANT when compiling (technically when preprocessing)
and uses -lpthread when linking.  On some platforms doing one without
the other is not supported, so you should use -pthread when compiling
and when linking.

Re: -lpthread -lstdc++ crashes on IRIX 6.5

[Peter O'Gorman]

On Tue, Feb 22, 2011 at 01:06:01AM +0000, Jonathan Wakely wrote:
> > We're rebuilding now with a modified g++spec.c (patched to reorder
> > -lpthread after -lstdc++), but still not sure that is the correct fix
> > for this.
> 
> The reason I asked is that on most platforms -pthread does two things,
> it uses -D_REENTRANT when compiling (technically when preprocessing)
> and uses -lpthread when linking.  On some platforms doing one without
> the other is not supported, so you should use -pthread when compiling
> and when linking.

While I agree with all of this, adding -lpthread to the link line as
well as -pthread should not cause the resulting application to crash.

I see I never got to that in my original mail, sorry :(. Even if we
consistently use -pthread for compiling and linking with gcc, we
sometimes end up with a -lpthread on the link line (often because
libtool has it in some .la files dependency_libs, sometimes due to
pkgconfig), and when that happens the resulting application crashes at
launch.

Peter
-- 
Peter O'Gorman
pogma@thewrittenword.com

Re: -lpthread -lstdc++ crashes on IRIX 6.5

[Peter O'Gorman]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

On Mon, Feb 21, 2011 at 07:24:00PM -0600, Peter O'Gorman wrote:
> 
> While I agree with all of this, adding -lpthread to the link line as
> well as -pthread should not cause the resulting application to crash.
> 
> I see I never got to that in my original mail, sorry :(. Even if we
> consistently use -pthread for compiling and linking with gcc, we
> sometimes end up with a -lpthread on the link line (often because
> libtool has it in some .la files dependency_libs, sometimes due to
> pkgconfig), and when that happens the resulting application crashes at
> launch.

This patch (for gcc-4.4, but if this is the right way to go, we will
forward port) works around the issue. Is it the correct approach? Or
perhaps the problem is specific to our build of gcc-4.4 on IRIX?

Thanks,
Peter
-- 
Peter O'Gorman
pogma@thewrittenword.com

[-- Attachment #2: reorderstdcpp.patch --]
[-- Type: text/plain, Size: 2167 bytes --]

Index: gcc/config/mips/iris6.h
===================================================================
--- gcc/config/mips/iris6.h.orig	2009-02-20 15:20:38.000000000 +0000
+++ gcc/config/mips/iris6.h	2011-02-21 17:32:14.040113998 +0000
@@ -23,7 +23,12 @@
 #undef TARGET_IRIX6
 #define TARGET_IRIX6 1
 
+/* We need to reorder -lpthread to come after -lstdc++. */
+#undef PTHREAD_LIBRARY
+#define PTHREAD_LIBRARY "-lpthread"
+
 /* Default to -mabi=n32 and -mips3.  */
+
 #undef MULTILIB_DEFAULTS
 #define MULTILIB_DEFAULTS { "mabi=n32" }
 
Index: gcc/cp/g++spec.c
===================================================================
--- gcc/cp/g++spec.c.orig	2009-02-20 15:20:38.000000000 +0000
+++ gcc/cp/g++spec.c	2011-02-21 17:33:55.979598307 +0000
@@ -30,10 +30,17 @@
 #define MATHLIB		(1<<2)
 /* This bit is set if they did `-lc'.  */
 #define WITHLIBC	(1<<3)
+/* This bit is set if they did '-lpthread'. */
+#define WITHLIBPTHREAD	(1<<4)
 
 #ifndef MATH_LIBRARY
 #define MATH_LIBRARY "-lm"
 #endif
+
+#ifndef PTHREAD_LIBRARY
+#define PTHREAD_LIBRARY ""
+#endif
+
 #ifndef MATH_LIBRARY_PROFILE
 #define MATH_LIBRARY_PROFILE MATH_LIBRARY
 #endif
@@ -86,6 +93,9 @@
   /* "-lm" or "-lmath" if it appears on the command line.  */
   const char *saw_math = 0;
 
+  /* "-lpthread" if it appears on the command line.  */
+  const char *saw_pthread = 0;
+
   /* "-lc" if it appears on the command line.  */
   const char *saw_libc = 0;
 
@@ -143,6 +153,8 @@
 	      args[i] |= MATHLIB;
 	      need_math = 0;
 	    }
+	  else if (strcmp (argv[i], PTHREAD_LIBRARY) == 0)
+	    args[i] |= WITHLIBPTHREAD;
 	  else if (strcmp (argv[i], "-lc") == 0)
 	    args[i] |= WITHLIBC;
 	  else if (strcmp (argv[i], "-pg") == 0 || strcmp (argv[i], "-p") == 0)
@@ -282,6 +294,12 @@
 	  saw_math = argv[i];
 	}
 
+      if (!saw_pthread && (args[i] & WITHLIBPTHREAD) && library > 0)
+	{
+	  --j;
+	  saw_pthread = argv[i];
+	}
+
       if (!saw_libc && (args[i] & WITHLIBC) && library > 0)
 	{
 	  --j;
@@ -335,6 +353,8 @@
     }
   if (saw_libc)
     arglist[j++] = saw_libc;
+  if (saw_pthread)
+    arglist[j++] = saw_pthread;
   if (shared_libgcc)
     arglist[j++] = "-shared-libgcc";
 

Re: -lpthread -lstdc++ crashes on IRIX 6.5

[Rainer Orth]

"Peter O'Gorman" <pogma@thewrittenword.com> writes:

> On Mon, Feb 21, 2011 at 07:24:00PM -0600, Peter O'Gorman wrote:
>> 
>> While I agree with all of this, adding -lpthread to the link line as
>> well as -pthread should not cause the resulting application to crash.
>> 
>> I see I never got to that in my original mail, sorry :(. Even if we
>> consistently use -pthread for compiling and linking with gcc, we
>> sometimes end up with a -lpthread on the link line (often because
>> libtool has it in some .la files dependency_libs, sometimes due to
>> pkgconfig), and when that happens the resulting application crashes at
>> launch.
>
> This patch (for gcc-4.4, but if this is the right way to go, we will
> forward port) works around the issue. Is it the correct approach? Or
> perhaps the problem is specific to our build of gcc-4.4 on IRIX?

Sorry for chiming in so late: I've been off for an extended weekend.

No, I don't think this is the right approach, but just a hack: if
libstdc++ needs the full/real libpthread to work on IRIX (which I assume
is the case, just as on Tru64 UNIX), it should be linked with it
directly instead of hacking around in the driver.  If the library is
properly self-contained (as it should), it doesn't depend on being
linked with g++, but works with the gcc driver as well.

I'll check this out soon, but now it's time for bed.

Could you file a PR for this issue in the meantime and Cc: me?

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: -lpthread -lstdc++ crashes on IRIX 6.5

[Peter O'Gorman]

On Tue, Feb 22, 2011 at 09:17:24PM +0100, Rainer Orth wrote:
> "Peter O'Gorman" <pogma@thewrittenword.com> writes:
> >
> > This patch (for gcc-4.4, but if this is the right way to go, we will
> > forward port) works around the issue. Is it the correct approach? Or
> > perhaps the problem is specific to our build of gcc-4.4 on IRIX?
> 
> Sorry for chiming in so late: I've been off for an extended weekend.

No problem, thanks for replying.

> 
> No, I don't think this is the right approach, but just a hack: if
> libstdc++ needs the full/real libpthread to work on IRIX (which I assume
> is the case, just as on Tru64 UNIX), it should be linked with it
> directly instead of hacking around in the driver.  If the library is
> properly self-contained (as it should), it doesn't depend on being
> linked with g++, but works with the gcc driver as well.

That makes sense. Thanks.

> Could you file a PR for this issue in the meantime and Cc: me?

http://gcc.gnu.org/PR47852

Peter
-- 
Peter O'Gorman
pogma@thewrittenword.com