Date: Wed, 1 Jun 2005 14:44:55 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Benjamin Lutz <benlutz@datacomm.ch> Cc: freebsd-stable@freebsd.org, Brent Casavant <b.j.casavant@ieee.org> Subject: Re: libpthread problem (segfaults) Message-ID: <Pine.GSO.4.43.0506011437420.9884-100000@sea.ntplx.net> In-Reply-To: <429DCF14.8060608@datacomm.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 1 Jun 2005, Benjamin Lutz wrote: > > I've found the problem for my own program. I was compiling with -lc. Why > I started doing that in the first place I can't remember, but removing > that option fixed above fatal error, and seems to have no negative > effects (of course, why would it). > > So, as a conclusion: gcc apparently produces broken code when -lc is > specified. I don't know much about how gcc is supposed to work, but that > might actually be a bug? No, gcc (the linker really) is doing exactly what you are telling it. The linker already brings in libc, you have to use -nostdlib to prevent it. You must link to objects in the correct order. libpthread, libthr, and libc_r all provide some functions that are overloaded from libc. When you link to libc first, you get the libc versions of those functions instead of the thread versions of them. > And, something in the 5.3->5.4 upgrade process went wrong which left me > with a broken libpthread. Can't say what exactly, maybe my system was > slightly broken to begin with. libpthread ain't broke; your applications are probably linked incorrectly. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0506011437420.9884-100000>