From owner-freebsd-arch@FreeBSD.ORG Mon May 5 21:33:17 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0934A37B401 for ; Mon, 5 May 2003 21:33:17 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 738FB43FBD for ; Mon, 5 May 2003 21:33:16 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx21-bradley.dialup.earthlink.net ([209.179.192.18] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Cu8Q-0005gg-00; Mon, 05 May 2003 21:32:59 -0700 Message-ID: <3EB73AA4.ADDDE95@mindspring.com> Date: Mon, 05 May 2003 21:31:32 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4ed6b0842f6f101520709b87d324181eb548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: "Andrey A. Chernov" cc: freebsd-arch@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: `Hiding' libc symbols X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 04:33:17 -0000 Daniel Eischen wrote: > If libc also doesn't have any strong symbols (at least for > the functions you want to check), then I suppose you can > check the linked application for these (strong) definitions. > I don't know how to do it myself, but this may give you some > idea. There's really no way to do it. Even with strong symbols; the ones that get linked first "win", and any later references lose. The relocation isn't seperate enough to allow relinking the libc into a .o file (via ld -r). Maybe the answer is to put "/usr/lib/libc.a" on the linker line, instead of "-L/usr/lib -llibc"; even then, it might not work unless you forced the symbol import, and "ld -r"'ed the libc.a into a libc.o, to conver the types. Bottom line: it's a pretty bad idea, and most of the problems are coming from functions that are not in any ratified standard in the first place, which iw why the ports are carrying them around themselves (in the expectation that they will not be present in the host OS). Overriding libc symbols that *are* defined by a standard has a long and glorious history. It's the same one that says that preventing people from doing stupid things also prevents them from doing clever things. Personally, I'd be much happier with the "nm"-based symbol collision checker, whose results were recently posted, being made available in ports, so that ports maintainers who care can check for themselves, and provide patches to their ports to pluck out the offensive symbols: if thine symbols offend thee, pluck them out, oh port maintainer... -- Terry