From owner-freebsd-stable@FreeBSD.ORG Wed Jun 1 18:45:10 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 936DE16A420 for ; Wed, 1 Jun 2005 18:45:10 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 701A243D54 for ; Wed, 1 Jun 2005 18:44:59 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j51IitBn005235; Wed, 1 Jun 2005 14:44:55 -0400 (EDT) Date: Wed, 1 Jun 2005 14:44:55 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Benjamin Lutz In-Reply-To: <429DCF14.8060608@datacomm.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-stable@freebsd.org, Brent Casavant Subject: Re: libpthread problem (segfaults) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2005 18:45:10 -0000 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