35545 - NSPR not building on FreeBSD 5.0-current:undefined references to pthread_*

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[anholt]

From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386; Nav)
BuildID:    

When compiling the NSPR libs on my FreeBSD 5.0-current, it bombs out with a lot
of undefined references to pthread_ functions.  It needs -pthread or -lc_r to
link.

I got it to compile by doing these (I don't quite understand the
Makefile.in/Makefile relationship in Moz.  ./configure didn't seem to rebuild
makefiles, so I made the change in both):

--- nsprpub/pr/src/Makefile.in.orig	Mon Apr 10 19:20:38 2000
+++ nsprpub/pr/src/Makefile.in	Mon Apr 10 19:21:14 2000
@@ -115,6 +115,12 @@
 endif
 endif
 
+ifeq ($(OS_ARCH),Linux)
+ifeq ($(USE_PTHREADS), 1)
+OS_LIBS		= -pthread
+endif
+endif
+
 ifeq ($(OS_ARCH),HP-UX)
 ifeq ($(USE_PTHREADS), 1)
 ifeq (,$(filter-out B.10.10 B.10.20,$(OS_RELEASE)))

--- nsprpub/pr/src/Makefile.orig	Wed Feb 23 15:38:02 2000
+++ nsprpub/pr/src/Makefile	Tue Apr 11 07:26:39 2000
@@ -113,6 +113,12 @@
 endif
 endif
 
+ifeq ($(OS_ARCH),FreeBSD)
+ifeq ($(USE_PTHREADS), 1)
+OS_LIBS		= -lc_r
+endif
+endif
+
 ifeq ($(OS_ARCH),HP-UX)
 ifeq ($(USE_PTHREADS), 1)
 ifeq (,$(filter-out B.10.10 B.10.20,$(OS_RELEASE)))

Comment 1

[cls]

IIRC, NSPR already has checks for -pthread in both the classic & autoconf
builds.  Assuming that you were actually building mozilla, did you give it the
--enable-pthreads option?  The NSPR autoconf build should automatically detect
whether you need -pthread or not. 
Can you also post the env variables & flags passed to configure and the error
log?

 

Comment 2

[Wan-Teh Chang]

The patch for nsprpub/pr/src/Makefile is good.

The patch for nsprpub/pr/src/Makefile.in seems
wrong.  Did you really mean "Linux"?  Also, that
part of the file is ifdef'd out if USE_AUTOCONF
is defined.  The -pthread or -lpthread flag for
Makefile.in needs to be taken care of by the
configure script.

Comment 3

[cls]

Shouldn't the additon of -pthread to OS_LIBS occur in the config/platform.mk
file?  If so, those defines are already there on FreeBSD. You just need to set
USE_PTHREADS=1 to trigger them.  Mozilla's configure script should detect
whether you have pthreads automatically and build NSPR accordingly.  Still need
the details from the logs.

Comment 4

[anholt]

Sorry for being so slow to respond.  Also, most of this is hand-copied
(clipboards don't like me), so I apologize for typos.
Here's what I did just yesterday:
(cvs checkout)
cd /usr/src/moz/mozilla
gmake distclean
./configure --enable-mathml --enable-x1-shm | grep pthread
checking for pthread_attr_init in -lpthread... no
checking for pthread_attr_init in -lc_r... yes
checking whether gcc accepts -pthread... yes
gmake
(build build build)
../../../dist/bin/libnspr4.so: undefined reference to 'pthread_condsignal'
...
../../../dist/bin/libnspr4.so: undefined reference to 'pthread_setspecific'
gmake distclean
./configure --enable-mathml --enable-x1-shm --with-pthreads | grep pthread
checking for pthread_attr_init in -lpthread... no
checking for pthread_attr_init in -lc_r... yes
checking whether gcc accepts -pthread... yes
gmake
(build build build)
../../../dist/bin/libnspr4.so: undefined reference to 'pthread_condsignal'
...
../../../dist/bin/libnspr4.so: undefined reference to 'pthread_setspecific'

Yes, my patch to Makefile.in was a pasto, and the Makefile one wasn't needed
because it's remade after a distclean (that's why I couldn't figure out the
makefiles, because I didn't know when it rebuilt them).  Thus, what I meant was:
--- nsprpub/pr/src/Makefile.in.orig	Mon Apr 10 19:20:38 2000
+++ nsprpub/pr/src/Makefile.in	Mon Apr 10 19:21:14 2000
@@ -115,6 +115,12 @@
 endif
 endif
 
+ifeq ($(OS_ARCH),FreeBSD)
+ifeq ($(USE_PTHREADS), 1)
+OS_LIBS		= -pthread
+endif
+endif
+
 ifeq ($(OS_ARCH),HP-UX)
 ifeq ($(USE_PTHREADS), 1)
 ifeq (,$(filter-out B.10.10 B.10.20,$(OS_RELEASE)))

Comment 5

[cls]

This sounds like it could have been a dup of either 35730 or 35127.  The final
fix for those bugs was checked in on 4/13/2000.  Are you still seeing this
problem with an updated tree?

Comment 6

[Wan-Teh Chang]

This does look like a duplicate of bug 35730 or 35127.

You could fix this by resolving all symbols when you build
libnspr4.so, which is what anholt's patch does.  This will
implicitly pull in -lc_r whenever you link with -lnspr4.

On some platforms the implicit linking of the pthread
library is not the complete solution because you
not only need to link with the pthread library but also
need to link with the pthread library in the right order
(before all other system libraries so that the pthread
library can override certain functions).  This is why
many compilers (which also act as front end to the linkers)
have a -pthread or -mt option.  Since FreeBSD combines the
pthread library and libc into a threaded version of libc
(i.e., -lc_r), it seems that the library linking order
is a non-issue.

I believe cls's fix for bug 35730 or 35127 should fix this
problem.  We could still check in anholt's patch, but whether
one needs to resolve all symbols when building a shared library
is a matter of style.  We should always use the -pthread flag
when compiling and linking, even if -lnspr4 is implicitly linked
with -lc_r.

Comment 7

[anholt]

Yep, it builds now after a fresh checkout.  Still some issues running it, but
will take a look at that more.

Comment 8

[Tobias Burnus]

*** Bug 137187 has been marked as a duplicate of this bug. ***