From owner-freebsd-current@FreeBSD.ORG Tue Jun 22 16:00:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13F8C16A4CE; Tue, 22 Jun 2004 16:00:01 +0000 (GMT) Received: from odot.okladot.state.ok.us (odot.okladot.state.ok.us [192.149.244.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49DF243D58; Tue, 22 Jun 2004 16:00:00 +0000 (GMT) (envelope-from root@techpc04.okladot.state.ok.us) Received: from techpc04.okladot.state.ok.us (techpc04.okladot.state.ok.us [199.27.9.37])KAA76068; Tue, 22 Jun 2004 10:59:34 -0500 Received: by techpc04.okladot.state.ok.us (Postfix, from userid 0) id 1F9185C37; Tue, 22 Jun 2004 10:59:33 -0500 (CDT) To: Jon Noack From: "Paul Seniura" Errors-To: "Paul Seniura" Sender: "Paul Seniura" In-Reply-To: <40D7EC48.5010800@alumni.rice.edu> References: <40D7EC48.5010800@alumni.rice.edu> Message-Id: <20040622155933.1F9185C37@techpc04.okladot.state.ok.us> Date: Tue, 22 Jun 2004 10:59:33 -0500 (CDT) cc: freebsd-x11@freebsd.org cc: freebsd-current@freebsd.org Subject: re: -Os -> libXaw.so: undefined reference to `.L91' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Paul Seniura List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 16:00:01 -0000 >[...] >Short version: >Don't compile (XFree86|xorg)-libraries with -Os. >[...] >Anyone run into problems with -Os on other ports? I've seen some ports >not compile with it (mplayer is the only that immediately comes to >mind), but never a delayed issue like this where it affects a different >port. > >Jon Noack It's a known problem with me anyway. Please see what I wrote here, which points to an official GCC website discussion: The bug goes way back: Besides complaining that FreeBSD won't fix their own tools to make them reliable, what I do when discovering src that won't compile right is to whip-up my own patch. This one takes care of x11/XFree86-4-libraries: ====-cut-here-==== --- Makefile_orig Mon Jun 14 00:53:39 2004 +++ Makefile Mon Jun 14 12:00:34 2004 @@ -35,6 +35,8 @@ panoramixext-* printext-* randrext-* renderext-* resourceext-* \ xextensions-* xf86ext-* xlibs-* xorg-libraries-* xproto-* +CFLAGS+= -O2 + USE_X_PREFIX= no PREFIX?= ${X11BASE} MTREE_FILE= /etc/mtree/BSD.x11-4.dist ====-cut-here-==== I don't know if it'll do any good to put these kinds of patches in PRs. This isn't a real fix -- it is a work-around for the lack of maintenance of FreeBSD's system compilers. The 5-current gcc is still a "snapshot" of late last year -- the GCC team released a final version of it earlier this year, but we don't have it. There are a _lot_ of FreeBSD ports that patch the -O-levels in the author's _original_ Make-stuff. I've written on this before; just search the maillist archives. ;) I've said before that if Linux/i386 works with the -O-levels in the original Makefiles, and FreeBSD/i386 is using the same gcc versions that Linux is, then those same -O-levels ought to work fine on FreeBSD. Stop patching them! I've mentioned my main point for using -Os is that this is the _default setting_ on Apple's XCode developer's system. I truly believe it is a major reason Panther (OSX 10.3) has shown incredible speed-ups over the past few updates. It makes a noticable improvement on this puny pentium2 here at work, too (no Macs allowed, been here 27+ years and I still don't know why, but I digress...). There are other reasons for using -Os: * it shaves a good 20% off the size of my customized kernel -- it's around 1.MB smaller... really, honest. * it helps keep loops inside the L1/L2 hardware caches. The "proper" fix would be to update the gcc "snapshots" FreeBSD is using as a system compiler. Get them updated to "official real honest released" gcc versions. It's beyond my expertise... we must depend on others... -- thx, Paul Seniura System Specialist State of Okla. D.O.T.