From nobody@FreeBSD.org  Sat Jan  5 18:47:06 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id BC22B37B417
	for <freebsd-gnats-submit@FreeBSD.org>; Sat,  5 Jan 2002 18:47:05 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g062l5503889;
	Sat, 5 Jan 2002 18:47:05 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200201060247.g062l5503889@freefall.freebsd.org>
Date: Sat, 5 Jan 2002 18:47:05 -0800 (PST)
From: "f.johan.beisser" <jan@caustic.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: libc breaking in -STABLE
X-Send-Pr-Version: www-1.0

>Number:         33595
>Category:       misc
>Synopsis:       libc breaking in -STABLE
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jan 05 18:50:00 PST 2002
>Closed-Date:    Tue Jan 8 02:22:57 PST 2002
>Last-Modified:  Tue Jan  8 07:50:05 PST 2002
>Originator:     f.johan.beisser
>Release:        4.4-STABLE, 4.5-PRERELEASE
>Organization:
>Environment:
FreeBSD pogo.caustic.org 4.4-STABLE FreeBSD 4.4-STABLE #0: Tue Oct 23 10:12:28 PDT 2001     root@punk.caustic.org:/usr/src/sys/compile/POGO  i386

>Description:
strcasestr.c and strnstr.c in /usr/src/lib/libc/strings both have __BSDID, which causes a failure in libc compiling in 4.4-STABLE to 4.5-PRERELEASE.
>How-To-Repeat:
upgrade to the latest -STABLE source  tree (4.5-PRERELEASE) as of today (Sat Jan  5 18:46:39 PST 2002). cd to /usr/src/lib/libc, do "make depend && make all". it will fail on strcacestr.c and strnstr.c in the "strings" directory.
>Fix:
find and comment out the lines with __BSDID in them.

__FBSDID("$FreeBSD: src/lib/libc/string/strcasestr.c,v 1.2.2.1 2001/12/25 00:36:53 ache Exp $");

 __FBSDID("$FreeBSD: src/lib/libc/string/strnstr.c,v 1.2.2.1 2001/12/09 06:50:03 mike Exp $");

once these two lines are commented out, libc compiles just fine.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: kris 
State-Changed-When: Sat Jan 5 19:44:46 PST 2002 
State-Changed-Why:  
Believed to not be a bug. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33595 

From: Kris Kennaway <kris@obsecurity.org>
To: "f.johan.beisser" <jan@caustic.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/33595: libc breaking in -STABLE
Date: Sat, 5 Jan 2002 19:44:28 -0800

 --5vNYLRcllDrimb99
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Sat, Jan 05, 2002 at 06:47:05PM -0800, f.johan.beisser wrote:
 
 > >Description:
 > strcasestr.c and strnstr.c in /usr/src/lib/libc/strings both have __BSDID, which causes a failure in libc compiling in 4.4-STABLE to 4.5-PRERELEASE.
 > >How-To-Repeat:
 > upgrade to the latest -STABLE source  tree (4.5-PRERELEASE) as of today (Sat Jan  5 18:46:39 PST 2002). cd to /usr/src/lib/libc, do "make depend && make all". it will fail on strcacestr.c and strnstr.c in the "strings" directory.
 
 This isn't a supported upgrade method.  Using the supported upgrade
 method (which includes 'make buildworld' to rebuild the userland
 source) shouldn't suffer from this problem; please confirm.
 
 Kris
 
 --5vNYLRcllDrimb99
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.6 (FreeBSD)
 Comment: For info see http://www.gnupg.org
 
 iD8DBQE8N8gaWry0BWjoQKURAi0HAKCHILqum9CL8mPcCQk3wsdxGhSQvQCfb2tc
 AznXwkJjD2fCJirVVopD3G0=
 =aHo4
 -----END PGP SIGNATURE-----
 
 --5vNYLRcllDrimb99--
State-Changed-From-To: analyzed->feedback 
State-Changed-By: sheldonh 
State-Changed-When: Mon Jan 7 06:41:37 PST 2002 
State-Changed-Why:  
We're waiting for feedback from the originator. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33595 
State-Changed-From-To: feedback->closed 
State-Changed-By: sheldonh 
State-Changed-When: Tue Jan 8 02:22:57 PST 2002 
State-Changed-Why:  
Kris' suspicions have been confirmed -- the originator was 
trying to build a standalone libc from a different version 
of FreeBSD, which (even if such a build was supported), 
would be very unlikely to actually work, given that it'd be 
out of synch with the installed kernel. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33595 

From: Sheldon Hearn <sheldonh@starjuice.net>
To: "f.johan.beisser" <jan@caustic.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/33595: libc breaking in -STABLE 
Date: Tue, 08 Jan 2002 12:24:48 +0200

 On Mon, 07 Jan 2002 11:59:52 PST, "f.johan.beisser" wrote:
 
 > it seems that it would be a bit odd to not be able to rebuild a small
 > section (such as libc) alone, should it need replacement or an upgrade.
 
 You're confusing two different issues.
 
 You can build libc standalone, possibly with local modifications, so
 long as you're building it on a synchronized system.
 
 You can upgrade your system using a ''make world'', thus acquiring such
 a "synchronized system".
 
 The fact that you thought you'd be able to build a standalone version of
 libc that is not synchronized with the system suggests that you haven't
 understood the FreeBSD operating system, which provides a tightly
 coupled userland and kernel.  This is very different from Linux, where
 there's a tendency to mix and match bits and pieces.
 
 Ciao,
 Sheldon.

From: "f.johan.beisser" <jan@caustic.org>
To: Sheldon Hearn <sheldonh@starjuice.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/33595: libc breaking in -STABLE 
Date: Tue, 8 Jan 2002 05:40:28 -0800 (PST)

 On Tue, 8 Jan 2002, Sheldon Hearn wrote:
 
 > > it seems that it would be a bit odd to not be able to rebuild a small
 > > section (such as libc) alone, should it need replacement or an upgrade.
 >
 > You're confusing two different issues.
 >
 > You can build libc standalone, possibly with local modifications, so
 > long as you're building it on a synchronized system.
 >
 > You can upgrade your system using a ''make world'', thus acquiring such
 > a "synchronized system".
 
 i know this, but recently having patched gcc with the "stack-protector"
 made me wish to test a build on *part* of the base system, without
 rebuilding all of the userland or kernel. libc was one of the recommended
 pieces to rebuild.
 
 simply, i was "just following instructions".
 
 > The fact that you thought you'd be able to build a standalone version of
 > libc that is not synchronized with the system suggests that you haven't
 > understood the FreeBSD operating system, which provides a tightly
 > coupled userland and kernel.  This is very different from Linux, where
 > there's a tendency to mix and match bits and pieces.
 
 since you don't know me, i won't take offence to the linux reference (i've
 not really touched/admin'd any linux machines since about 97, and there've
 been worlds of changes since then from what i've heard and read) or to the
 lack of knowledge about FreeBSD.
 
 granted, doing a buildworld to rebuild the entire base system is a bit
 better of a habit (it's what i ususally do), rebuilding everything to test
 a "modified" compiler is a bit excessive. anyhow, consider the bug
 withdrawn, and set the bit to closed/disproved.
 
 thanks for the extra info,
 -- johan
 
 -------/ f. johan beisser /--------------------------------------+
   http://caustic.org/~jan                      jan@caustic.org
     "John Ashcroft is really just the reanimated corpse
          of J. Edgar Hoover." -- Tim Triche
 
 

From: Sheldon Hearn <sheldonh@starjuice.net>
To: "f.johan.beisser" <jan@caustic.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/33595: libc breaking in -STABLE 
Date: Tue, 08 Jan 2002 17:32:57 +0200

 On Tue, 08 Jan 2002 05:40:28 PST, "f.johan.beisser" wrote:
 
 > i know this, but recently having patched gcc with the "stack-protector"
 > made me wish to test a build on *part* of the base system, without
 > rebuilding all of the userland or kernel. libc was one of the recommended
 > pieces to rebuild.
 
 You _can_ rebuild just libc, but you must use sources synchronized with
 the installed base.  In other words, use the same sources used to build
 world.
 
 > since you don't know me, i won't take offence to the linux reference (i've
 > not really touched/admin'd any linux machines since about 97, and there've
 > been worlds of changes since then from what i've heard and read) or to the
 > lack of knowledge about FreeBSD.
 
 No offense intended.  My assumption is simply that folks who're not
 familiar with the tight coupling of FreeBSD's userland and kernel are
 likely to come from a Linux background, where this does not exist.
 
 > granted, doing a buildworld to rebuild the entire base system is a bit
 > better of a habit (it's what i ususally do), rebuilding everything to test
 > a "modified" compiler is a bit excessive.
 
 The "mistake" you made was to update your sources to do this, instead of
 just using the sources used for the last upgrade (or the sources
 installed with the binary upgrade / installation).
 
 Ciao,
 Sheldon.

From: "f.johan.beisser" <jan@caustic.org>
To: Sheldon Hearn <sheldonh@starjuice.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/33595: libc breaking in -STABLE 
Date: Tue, 8 Jan 2002 07:36:32 -0800 (PST)

 On Tue, 8 Jan 2002, Sheldon Hearn wrote:
 
 > On Tue, 08 Jan 2002 05:40:28 PST, "f.johan.beisser" wrote:
 >
 > > i know this, but recently having patched gcc with the "stack-protector"
 > > made me wish to test a build on *part* of the base system, without
 > > rebuilding all of the userland or kernel. libc was one of the recommended
 > > pieces to rebuild.
 >
 > You _can_ rebuild just libc, but you must use sources synchronized with
 > the installed base.  In other words, use the same sources used to build
 > world.
 
 so, tracking RELENG_4_4 would work, but RELENG_4 would not?
 
 > > granted, doing a buildworld to rebuild the entire base system is a bit
 > > better of a habit (it's what i ususally do), rebuilding everything to test
 > > a "modified" compiler is a bit excessive.
 >
 > The "mistake" you made was to update your sources to do this, instead of
 > just using the sources used for the last upgrade (or the sources
 > installed with the binary upgrade / installation).
 
 upgraded source tree that i tend to keep up to date, even if i don't build
 from it. that was my mistake. tracking the wrong branch.
 
 anyhow, now i know, despite several years of working on this stuff. i like
 things that keep the OS interesting.
 
 -- johan
 -------/ f. johan beisser /--------------------------------------+
   http://caustic.org/~jan                      jan@caustic.org
     "John Ashcroft is really just the reanimated corpse
          of J. Edgar Hoover." -- Tim Triche
 

From: Sheldon Hearn <sheldonh@starjuice.net>
To: "f.johan.beisser" <jan@caustic.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/33595: libc breaking in -STABLE 
Date: Tue, 08 Jan 2002 17:47:14 +0200

 On Tue, 08 Jan 2002 07:36:32 PST, "f.johan.beisser" wrote:
 
 > > You _can_ rebuild just libc, but you must use sources synchronized with
 > > the installed base.  In other words, use the same sources used to build
 > > world.
 > 
 > so, tracking RELENG_4_4 would work, but RELENG_4 would not?
 
 It doesn't matter what you're tracking, so long as, when you do
 component builds, the component source matches the installed system.
 
 Incidentally, this often isn't entirely necessary.  You can often get
 away with component builds from future sources.  But since it won't
 always work (as you've seen for yourself), it's not recommended and
 can't really be supported.
 
 > upgraded source tree that i tend to keep up to date, even if i don't build
 > from it. that was my mistake. tracking the wrong branch.
 
 I'm not sure it had to do so much with tracking the wrong branch as it
 did with the reasons explained above.
 
 > anyhow, now i know, despite several years of working on this stuff. i like
 > things that keep the OS interesting.
 
 Interesting in the Chinese sense of the word. :-)
 
 Ciao,
 Sheldon.

From: Peter Pentchev <roam@ringlet.net>
To: "f.johan.beisser" <jan@caustic.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/33595: libc breaking in -STABLE
Date: Tue, 8 Jan 2002 17:47:44 +0200

 On Tue, Jan 08, 2002 at 07:40:07AM -0800, f.johan.beisser wrote:
 > The following reply was made to PR misc/33595; it has been noted by GNATS.
 > 
 > From: "f.johan.beisser" <jan@caustic.org>
 > To: Sheldon Hearn <sheldonh@starjuice.net>
 > Cc: freebsd-gnats-submit@FreeBSD.org
 > Subject: Re: misc/33595: libc breaking in -STABLE 
 > Date: Tue, 8 Jan 2002 07:36:32 -0800 (PST)
 > 
 >  On Tue, 8 Jan 2002, Sheldon Hearn wrote:
 >  
 >  > On Tue, 08 Jan 2002 05:40:28 PST, "f.johan.beisser" wrote:
 >  >
 >  > > i know this, but recently having patched gcc with the "stack-protector"
 >  > > made me wish to test a build on *part* of the base system, without
 >  > > rebuilding all of the userland or kernel. libc was one of the recommended
 >  > > pieces to rebuild.
 >  >
 >  > You _can_ rebuild just libc, but you must use sources synchronized with
 >  > the installed base.  In other words, use the same sources used to build
 >  > world.
 >  
 >  so, tracking RELENG_4_4 would work, but RELENG_4 would not?
 
 Even then it is not really guaranteed to work.  In practice I really
 expect that it should work, because RELENG_4_4 sees no changes of this
 magnitude.  The problem is with the tracking itself - when you updated
 your source tree, you updated pieces outside of libc along with those
 in libc.  In this particular case, the ones in libc depend on the correct
 'bootstrap' and the other phases that a buildworld does before rebuilding
 libraries.  In this particular case, rebuilding libc without having
 the proper header files already in a place where the compiler can see
 them is doomed to failure.
 
 >  > > granted, doing a buildworld to rebuild the entire base system is a bit
 >  > > better of a habit (it's what i ususally do), rebuilding everything to test
 >  > > a "modified" compiler is a bit excessive.
 >  >
 >  > The "mistake" you made was to update your sources to do this, instead of
 >  > just using the sources used for the last upgrade (or the sources
 >  > installed with the binary upgrade / installation).
 >  
 >  upgraded source tree that i tend to keep up to date, even if i don't build
 >  from it. that was my mistake. tracking the wrong branch.
 
 Not really.  Your mistake was rebuilding only a part of the source tree
 *after upgrading the whole of it* and *before building the whole of it*.
 Once you have completed a buildworld, you can change and rebuild any
 of the libraries all you like.
 
 >  anyhow, now i know, despite several years of working on this stuff. i like
 >  things that keep the OS interesting.
 
 I can relate to that :)
 
 G'luck,
 Peter
 
 -- 
 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI
>Unformatted:
