Re: Build failure during 9-CURRENT make world
On 26 June 2011 19:55, Dimitry Andric wrote: > On 2011-06-26 20:43, Chris Rees wrote: > ... >> >> cd /usr/cursrc/src >> make KERNCONF=CERBERUS DESTDIR=/mnt world kernel > > ... >> >> >> /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a: >> could not read symbols: File format not recognized > > ... >> >> Any ideas please??? > > The file /usr/obj/cursrc/src/lib/clang/libllvmcodegen/libllvmcodegen.a > is busted, for some reason. My guess would be that you built it for a > different architecture. You can try removing it, and building again, or > if you want to use brute force, zap your entire /usr/obj and rebuild. > I thought I'd tried that... Turns out I hadn't! The file was corrupted presumably because of a disk full error that I had since corrected. I hang my head in shame accordingly. Thanks, Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failure during 9-CURRENT make world
On 2011-06-26 20:43, Chris Rees wrote: ... cd /usr/cursrc/src make KERNCONF=CERBERUS DESTDIR=/mnt world kernel ... /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a: could not read symbols: File format not recognized ... Any ideas please??? The file /usr/obj/cursrc/src/lib/clang/libllvmcodegen/libllvmcodegen.a is busted, for some reason. My guess would be that you built it for a different architecture. You can try removing it, and building again, or if you want to use brute force, zap your entire /usr/obj and rebuild. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Build failure during 9-CURRENT make world
Hi all, Just trying to install 9-CURRENT (csupped today) for my Xbox. What I did: mounted all partitions under /mnt cd /usr/cursrc/src make KERNCONF=CERBERUS DESTDIR=/mnt world kernel *chug chug* ===> usr.bin/clang/clang (all) c++ -O2 -pipe -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/cursrc/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd9.0\" -fstack-protector -fno-exceptions -fno-rtti -o clang cc1_main.o cc1as_main.o driver.o /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangserialization/libclangserialization.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzerfrontend/libclangstaticanalyzerfrontend.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzercheckers/libclangstaticanalyzercheckers.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangstaticanalyzercore/libclangstaticanalyzercore.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangindex/libclangindex.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangrewrite/libclangrewrite.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvminstrumentation/libllvminstrumentation.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdisassembler/libllvmarmdisassembler.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminstprinter/libllvmarminstprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/libllvmarminfo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpccodegen/libllvmpowerpccodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinstprinter/libllvmpowerpcinstprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86disassembler/libllvmx86disassembler.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86asmparser/libllvmx86asmparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmx86codegen/libllvmx86codegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmselectiondag/libllvmselectiondag.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmprinter/libllvmasmprinter.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmmcparser/libllvmmcparser.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmcodegen/libllvmcodegen.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmscalaropts/libllvmscalaropts.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvminstcombine/libllvminstcombine.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmtransformutils/libllvmtransformutils.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmipa/libllvmipa.a /usr/obj/cursrc/src/usr.bin/clang/clang/../../../lib/clang/libllvmanalysis/libllvmanalysis.a /usr/ob
Re: Core dumps on Current Make World this morning
> In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes > : > >> In message <[EMAIL PROTECTED]> Matthew >Jacob writes: > >> : Same with me. > >> > >> This sounds like a job for Captain UPDATING: > > > >Don't you just need to rebuild vi/ex? Ie would not: > > cd /usr/src/usr.bin/vi; > > make cleandir && make obj && make depend && make all install > > > >fix the problem? > > > >Two buildworlds seems like a big sledgehammer when a small tap with > >a 2oz would do :-) > > It's actually libc you need to reinstall (unless your vi/ex is > statically linked). Okay... cd /usr/src/lib/libc; make cleandir && make obj && make depend && make all install -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message <[EMAIL PROTECTED]>, "Rodney W. Grimes" writes : >> In message <[EMAIL PROTECTED]> Matthew Jacob >writes: >> : Same with me. >> >> This sounds like a job for Captain UPDATING: > >Don't you just need to rebuild vi/ex? Ie would not: > cd /usr/src/usr.bin/vi; > make cleandir && make obj && make depend && make all install > >fix the problem? > >Two buildworlds seems like a big sledgehammer when a small tap with >a 2oz would do :-) It's actually libc you need to reinstall (unless your vi/ex is statically linked). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message <[EMAIL PROTECTED]> "Rodney W. Grimes" writes: : > This sounds like a job for Captain UPDATING: : : Don't you just need to rebuild vi/ex? Ie would not: : cd /usr/src/usr.bin/vi; : make cleandir && make obj && make depend && make all install : fix the problem? : : Two buildworlds seems like a big sledgehammer when a small tap with : a 2oz would do :-) If someone with a bad vi tries this and it works, I'll change it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message <[EMAIL PROTECTED]>, Matt Dillon writes: > >:Ta-da! >: >: >:> In message <[EMAIL PROTECTED]> Matthew >Jacob writes: >:> : Same with me. >:> >:> This sounds like a job for Captain UPDATING: >:> >:> 20010101: >:> ex and vi were broken by some changes to sys/queue.h. If >:> you have a bad vi (and are getting core dumps when building >:> termcap), you can work around this problem by adding -k to >:> your command line. This will cause the build to complete >:> and install a new vi. Once that's done, you can rebuild again >:> without the -k to pick up anything that might have been >:> ignored by the -k option. > >Why in (insert favorite deity)'s name does ex and vi depend on >sys/queue.h ? Actually they don't, they depend on db1.85's "mpool" which depends on since it lives in libc. vi/ex comes with their own copy of -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
> In message <[EMAIL PROTECTED]> Matthew Jacob >writes: > : Same with me. > > This sounds like a job for Captain UPDATING: Don't you just need to rebuild vi/ex? Ie would not: cd /usr/src/usr.bin/vi; make cleandir && make obj && make depend && make all install fix the problem? Two buildworlds seems like a big sledgehammer when a small tap with a 2oz would do :-) > 20010101: > ex and vi were broken by some changes to sys/queue.h. If > you have a bad vi (and are getting core dumps when building > termcap), you can work around this problem by adding -k to > your command line. This will cause the build to complete > and install a new vi. Once that's done, you can rebuild again > without the -k to pick up anything that might have been > ignored by the -k option. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message <[EMAIL PROTECTED]> Matt Dillon writes: : Why in (insert favorite deity)'s name does ex and vi depend on : sys/queue.h ? Because it does. :-) Lots of places in the userland tree use it. phk committed a fix to vi that broke vi, and that's the problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
> > Why in (insert favorite deity)'s name does ex and vi depend on > sys/queue.h ? Oh, christ, who knows? I just saw the new David Mamet film "State && Main"... in one scene, Alec Baldwin has just crashed a stationwagon and flipped it, wiping out the only stoplight in this town. he crawls out of the wreckage, lounges against the car and says, "Well... that happened." Thie sys/queue.h is probably of the same order. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
:Ta-da! : : :> In message <[EMAIL PROTECTED]> Matthew Jacob :writes: :> : Same with me. :> :> This sounds like a job for Captain UPDATING: :> :> 20010101: :> ex and vi were broken by some changes to sys/queue.h. If :> you have a bad vi (and are getting core dumps when building :> termcap), you can work around this problem by adding -k to :> your command line. This will cause the build to complete :> and install a new vi. Once that's done, you can rebuild again :> without the -k to pick up anything that might have been :> ignored by the -k option. Why in (insert favorite deity)'s name does ex and vi depend on sys/queue.h ? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
Ta-da! > In message <[EMAIL PROTECTED]> Matthew Jacob >writes: > : Same with me. > > This sounds like a job for Captain UPDATING: > > 20010101: > ex and vi were broken by some changes to sys/queue.h. If > you have a bad vi (and are getting core dumps when building > termcap), you can work around this problem by adding -k to > your command line. This will cause the build to complete > and install a new vi. Once that's done, you can rebuild again > without the -k to pick up anything that might have been > ignored by the -k option. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message <[EMAIL PROTECTED]> Matthew Jacob writes: : Same with me. This sounds like a job for Captain UPDATING: 20010101: ex and vi were broken by some changes to sys/queue.h. If you have a bad vi (and are getting core dumps when building termcap), you can work around this problem by adding -k to your command line. This will cause the build to complete and install a new vi. Once that's done, you can rebuild again without the -k to pick up anything that might have been ignored by the -k option. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Core dumps on Current Make World this morning
same here as well... i did a make -k buildworld and that worked for me/.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matthew Jacob Sent: Tuesday, January 02, 2001 1:06 PM To: Charlie Root Cc: [EMAIL PROTECTED] Subject: Re: Core dumps on Current Make World this morning Same with me. > All the machines that I have running Current dumped core at the same > place this morning. > > ===> share/termcap > ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder > > /dev/null > Segmentation fault - core dumped > *** Error code 139 > > Stop in /usr/src/share/termcap. > *** Error code 1 > > For a couple of days now, I haven't been able to use vi because it also > dumps core on all the machines except the only one that was able to > build world and a new kernel yesterday, just good timing I guess. I > haven't seen this on the list. > > Thanks, > > ed > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
Same with me. > All the machines that I have running Current dumped core at the same > place this morning. > > ===> share/termcap > ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder > > /dev/null > Segmentation fault - core dumped > *** Error code 139 > > Stop in /usr/src/share/termcap. > *** Error code 1 > > For a couple of days now, I haven't been able to use vi because it also > dumps core on all the machines except the only one that was able to > build world and a new kernel yesterday, just good timing I guess. I > haven't seen this on the list. > > Thanks, > > ed > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
The Hermit Hacker wrote:
> do a 'make -k world' ... I had the same problem with vi, and the same
> SegFault ... by using -k, it bypasses the error, which allows it to get to
> the point that the newer vi is installed, which doesn't SegFault ...
Thanks, I just started them all up with -k . I didn't even think of that.
Thanks again,
ed
>
>
> On Tue, 2 Jan 2001, Charlie Root wrote:
>
> > All the machines that I have running Current dumped core at the same
> > place this morning.
> >
> > ===> share/termcap
> > ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder
> > > /dev/null
> > Segmentation fault - core dumped
> > *** Error code 139
> >
> > Stop in /usr/src/share/termcap.
> > *** Error code 1
> >
> > For a couple of days now, I haven't been able to use vi because it also
> > dumps core on all the machines except the only one that was able to
> > build world and a new kernel yesterday, just good timing I guess. I
> > haven't seen this on the list.
> >
> > Thanks,
> >
> > ed
> >
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> >
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
do a 'make -k world' ... I had the same problem with vi, and the same
SegFault ... by using -k, it bypasses the error, which allows it to get to
the point that the newer vi is installed, which doesn't SegFault ...
On Tue, 2 Jan 2001, Charlie Root wrote:
> All the machines that I have running Current dumped core at the same
> place this morning.
>
> ===> share/termcap
> ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder
> > /dev/null
> Segmentation fault - core dumped
> *** Error code 139
>
> Stop in /usr/src/share/termcap.
> *** Error code 1
>
> For a couple of days now, I haven't been able to use vi because it also
> dumps core on all the machines except the only one that was able to
> build world and a new kernel yesterday, just good timing I guess. I
> haven't seen this on the list.
>
> Thanks,
>
> ed
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Core dumps on Current Make World this morning
All the machines that I have running Current dumped core at the same place this morning. ===> share/termcap ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder > /dev/null Segmentation fault - core dumped *** Error code 139 Stop in /usr/src/share/termcap. *** Error code 1 For a couple of days now, I haven't been able to use vi because it also dumps core on all the machines except the only one that was able to build world and a new kernel yesterday, just good timing I guess. I haven't seen this on the list. Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT make world broken
On Thu, Dec 30, 1999 at 12:23:35PM -0500, Kenneth Wayne Culver <[EMAIL PROTECTED]> wrote: > I was just wondering if anyone else was having a problem making the world > on -CURRENT right now? I don't remember the exact error I got because > I'm at work, and my machine is at home, but for the last 3 weeks whenever > I try to make world, it dies in a different place, I've tried every day, > so I'm thinking maybe it's a problem with my computer's setup, or maybe I > forgot to update something. What updates that I'm missing could be causing > this? (for example, once I had this problem, and reinstalling the mk files > in /usr/share/mk fixed it, is there something simple like this that I > missed?) I will be sending the exact error as soon as I have a chance to > reproduce it. I built the world yesterday just fine, althought about a week ago I had great problems with build process. Died with different signals in different places. All these were problems with my motherboard, the DIMM socket contact pins lost tight contact with DIMM because of bad material of contact pins. It seems a lot of cheap motherboards use very cheap DIMM sockets. It was quite a work to hunt it down to this. Just FYI. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT make world broken
I build world this morning, and it built fine. Patrick - Original Message - From: Kenneth Wayne Culver <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 30, 1999 12:23 PM Subject: -CURRENT make world broken > I was just wondering if anyone else was having a problem making the world > on -CURRENT right now? I don't remember the exact error I got because > I'm at work, and my machine is at home, but for the last 3 weeks whenever > I try to make world, it dies in a different place, I've tried every day, > so I'm thinking maybe it's a problem with my computer's setup, or maybe I > forgot to update something. What updates that I'm missing could be causing > this? (for example, once I had this problem, and reinstalling the mk files > in /usr/share/mk fixed it, is there something simple like this that I > missed?) I will be sending the exact error as soon as I have a chance to > reproduce it. > > > = > | Kenneth Culver | FreeBSD: The best OS around.| > | Unix Systems Administrator | ICQ #: 24767726 | > | and student at The | AIM: AgRSkaterq | > | The University of Maryland, | Website: (Under Construction) | > | College Park. | http://www.wam.umd.edu/~culverk/| > = > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-CURRENT make world broken
I was just wondering if anyone else was having a problem making the world on -CURRENT right now? I don't remember the exact error I got because I'm at work, and my machine is at home, but for the last 3 weeks whenever I try to make world, it dies in a different place, I've tried every day, so I'm thinking maybe it's a problem with my computer's setup, or maybe I forgot to update something. What updates that I'm missing could be causing this? (for example, once I had this problem, and reinstalling the mk files in /usr/share/mk fixed it, is there something simple like this that I missed?) I will be sending the exact error as soon as I have a chance to reproduce it. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current Make World
> Speaking of which, is their an archive (web based?) of the FreeBSD-current > mailing list (how about others?)? I didn't see one linked in my searches > around the web pages. I am currently working on a full-text search/archive of Open Source mailing lists, which should be up at http://www.osdigger.com for testing before the end of the year. The site will have searchable archives of over 300 lists including *BSD, Linux, Perl, Apache, KDE, Gnome, and lots lots more :) Watch this space. -Matt Matt Hamilton[EMAIL PROTECTED] Hamilton Computing +44 (0)797 707 2482 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current Make World
On Sun, 14 Nov 1999, Lester Igo wrote: > Speaking of which, is their an archive (web based?) of the FreeBSD-current > mailing list (how about others?)? I didn't see one linked in my searches > around the web pages. http://www.freebsd.org/mail/ kind of obviously pointed to by http://www.freebsd.org/search/#mailinglists ;-) Kris Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current Make World
On Sun, Nov 14, 1999 at 11:02:18PM -0800, Lester Igo wrote: > I started with FreeBSD-3.3-Release last Friday, tried current and it > failed so I moved on to stable, it worked, I installed it and built a new > kernel, and then using the fresh compile I tried to go to -current and it > still fails at the same location with the same signal 12... Did you build a -CURRENT kernel before trying to build a -CURRENT world? See also /usr/src/UPDATING. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current Make World
I have been trying to get world to compile on my system and had a "signal 12" failure at the same location every time. I started with FreeBSD-3.3-Release last Friday, tried current and it failed so I moved on to stable, it worked, I installed it and built a new kernel, and then using the fresh compile I tried to go to -current and it still fails at the same location with the same signal 12... This computer in it's same hardware config compiled many -current versions prior to 3.0 (it is an SMP system 2xP166MMX), so I am fairly sure of the hardware. (not to mention it compiled -stable without a hitch) I haven't followed the FreeBSD current mailing lists for about a year, so if instructions have been sent to get around this problem, I missed them. Note: yes I joined the mailing lists now that I am trying to get back on that track... Speaking of which, is their an archive (web based?) of the FreeBSD-current mailing list (how about others?)? I didn't see one linked in my searches around the web pages. All that said, it bails on a "signal 12" as follows (any suggestions of things to try please let me know): - ===> f77doc ===> cc_tools /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools created for /usr/src/gnu/usr.bin/cc/cc_tools ===> cc_int /usr/obj/usr/src/gnu/usr.bin/cc/cc_int created for /usr/src/gnu/usr.bin/cc/cc_int ===> cc_drv /usr/obj/usr/src/gnu/usr.bin/cc/cc_drv created for /usr/src/gnu/usr.bin/cc/cc_drv ===> cpp /usr/obj/usr/src/gnu/usr.bin/cc/cpp created for /usr/src/gnu/usr.bin/cc/cpp ===> cc1 /usr/obj/usr/src/gnu/usr.bin/cc/cc1 created for /usr/src/gnu/usr.bin/cc/cc1 ===> cc /usr/obj/usr/src/gnu/usr.bin/cc/cc created for /usr/src/gnu/usr.bin/cc/cc ===> cc1obj /usr/obj/usr/src/gnu/usr.bin/cc/cc1obj created for /usr/src/gnu/usr.bin/cc/cc1obj ===> cc1plus /usr/obj/usr/src/gnu/usr.bin/cc/cc1plus created for /usr/src/gnu/usr.bin/cc/cc1plus ===> c++ /usr/obj/usr/src/gnu/usr.bin/cc/c++ created for /usr/src/gnu/usr.bin/cc/c++ ===> c++filt /usr/obj/usr/src/gnu/usr.bin/cc/c++filt created for /usr/src/gnu/usr.bin/cc/c++filt ===> doc /usr/obj/usr/src/gnu/usr.bin/cc/doc created for /usr/src/gnu/usr.bin/cc/doc ===> f77 /usr/obj/usr/src/gnu/usr.bin/cc/f77 created for /usr/src/gnu/usr.bin/cc/f77 ===> f771 /usr/obj/usr/src/gnu/usr.bin/cc/f771 created for /usr/src/gnu/usr.bin/cc/f771 ===> f77doc /usr/obj/usr/src/gnu/usr.bin/cc/f77doc created for /usr/src/gnu/usr.bin/cc/f77doc cd /usr/src/gnu/lib/libgcc; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -B install; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPROFILE -DNOSHARED -B cleandir obj rm -f .depend /usr/obj/usr/src/gnu/lib/libgcc/GPATH /usr/obj/usr/src/gnu/lib/libgcc/GRTAGS /usr/obj/usr/src/gnu/lib/libgcc/GSYMS /usr/obj/usr/src/gnu/lib/libgcc/GTAGS echo '#include '> config.h echo '#include ' >> config.h echo '#include "i386/xm-i386.h"'> tconfig.h echo '#include "i386/i386.h"' > tm.h echo '#include "i386/att.h"'>> tm.h echo '#include "i386/freebsd.h"'>> tm.h echo '#include "i386/perform.h"'>> tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. - Thanks, and I look forward to being back on the -current track again! -- Lester Igo [EMAIL PROTECTED] http://www.vtic.net/~igo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT `make world` fails.. (ucontext.h?)
[removing cc's, since I addressed them in another message in another
thread in another list :]
Will Andrews wrote:
>
> Yes, that's how I did it. Actually, I had 3.3-RELEASE.. I downloaded the entire
If you had 3.3-RELEASE, you wouldn't need a new loader to load the
-current kernel. That's not true of someone who had 3.1-RELEASE.
> > Now, aout_freebsd.c (and possibly other files) in
> > sys/boot/i386/libi386 includes sys/param.h, which, in turn, includes
> > sys/signal.h. The later requires machine/ucontext.h, which is not
> > present. Why the newer signal.h is found but not ucontext.h, I'll
> > find out shortly (I hope :). For now, I'm working with the
> > hypothesis of a "file.h" instead of #include.
>
> Yes, I thought the was the problem. Is
> "machine/ucontext.h" under /usr/src somewhere? I thought I saw one, but
> couldn't seem to finger its precise path.
Actually, now that I spent a few minutes witht he code, it's obvious
that I was way short-sighted in this. The analysis above is too
naive, and, to be blunt, dumb. :-) Obviously, /usr/src/sys/machine/*
cannot be found, because it does not exist. /usr/include/machine/*
is generated from /usr/src/sys/${MACHINE_ARCH}/include. The makefile
uses -I so that files will be found under /usr/src/sys
(well, not exactly -- it uses a relative path, but that's the gist
of it :), but the files included by those cannot be
found.
Thus, we have a situation in which some of the include files are the
latest (), and some are not ().
The problem is triggered by , but it could have
been triggered by a number of other files. It's just not a simple
problem to solve. :-(
> Like I said above, a -CURRENT kernel may have problems with a -STABLE world.
>
> I'm honestly not fully aware of the dependencies regarding the signal changes
> (i.e., ucontext.h), so my thoughts may be completely wrong. :-)
>
> Comments?
You ought to say that a -STABLE world will have problems with a
-CURRENT kernel. The kernel ought to be immune to -STABLE world's
problems. :-) In a perfect world, anyway. :-) Anyway, there are
problems a -STABLE world will have with a -CURRENT kernel, but they
are not likely to be crippling (ie, you should be able to make world
after booting the new kernel). One thing that *can* bite is the use
of klds. Bad ju ju may result from the use of old klds with a new
kernel.
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"I always feel generous when I'm in the inner circle of a
conspiracy to subvert the world order and, with a small group of
allies, just defeated an alien invasion. Maybe I should value myself
a little more?"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT `make world` fails.. (ucontext.h?)
On 18-Oct-99 Daniel C. Sobral wrote: > I'm tracking this now. Well, I'll start tracking as soon as I finish > my mail. I suggested first upgrading to 3.3 (or even 3.2), and only > then to current. That _will_ work, as it will upgrade the loader. > Alas, you need not even go to such pains. Just cvsup to -stable, cd > /sys/boot; make depend && make all install, and then cvsup to > -current, make the kernel, etc, etc. Yes, that's how I did it. Actually, I had 3.3-RELEASE.. I downloaded the entire -CURRENT CVS repository so I could get sources for September 29, before marcel's changes. Then I burned those sources to a CD-R, and loaded it on my laptop. Made world, rebooted, and I'm in 4.0-CURRENT. Then after several unsuccessful attempts to do a newer world, I finally got it. argon.blackdawn.com (my laptop) is _NOW_ running 4.0-CURRENT as of October 17, 1999 @ 9PM EDT. Only one problem is left - my pccard isn't working. I'm working with Warner Losh on that... (hopefully something good will come out of that.) > The person who first reported the problem said he succesfully used > the loader from a recent snap. That will work. Go to a near FreeBSD > ftp site, get the "loader" binary from a snapshot, copy it to /boot, > and that will be able to load a -current kernel. Interesting. All I did was rebuild the kernel again and tried another make world. For some reason, the system wanted me to build the same kernel twice. Or maybe I cvsup'd more than once, and didn't build a new kernel the second or third time. I don't know. :) I didn't try a bootloader off the ftp sites.. that wouldn't have worked for me anyway, since pccard support broke around the time I got to the bootloader in `make world`. I mean, it broke 'cause I lost my old Sept. 29 kernel. I forgot to keep a backup copy of it.. :\ > As for the problem it goes like this: > > FreeBSD 3.1's loader was not capable of loading a kernel at a > different base address than the one FreeBSD used up to that point. > Unfortunately, this resulted in an annoying bug that affected > machines with lots of RAM and big maxusers (like, for instance, > 256). This was corrected by moving the base address of kernel, which > required modifications to loader. > > Thus, FreeBSD's 3.1 loader is not capable of booting a current > kernel. Perhaps people need to install a new boot loader first (one that is of 4.0-CURRENT lineage), as you suggested. Then perhaps building a -CURRENT kernel, and rebooting. Of course, I dunno if that'd work, given the differing kernel and world.. > Now, aout_freebsd.c (and possibly other files) in > sys/boot/i386/libi386 includes sys/param.h, which, in turn, includes > sys/signal.h. The later requires machine/ucontext.h, which is not > present. Why the newer signal.h is found but not ucontext.h, I'll > find out shortly (I hope :). For now, I'm working with the > hypothesis of a "file.h" instead of #include. Yes, I thought the was the problem. Is "machine/ucontext.h" under /usr/src somewhere? I thought I saw one, but couldn't seem to finger its precise path. > All things considered, this isn't much of a problem in itself. > > There is a huge problem here,though. Generally speaking, loader is > immune to world troubles, since it uses libstand. But, are we not > risking chicken-and-egg problems such as this by including standard > sys/*.h? Situations where newer loaders are needed to boot a new > kernel (as much as we would like loader to be able to handle all > future kernels), but not being able to build them until a newer > kernel is booted? Like I said above, a -CURRENT kernel may have problems with a -STABLE world. I'm honestly not fully aware of the dependencies regarding the signal changes (i.e., ucontext.h), so my thoughts may be completely wrong. :-) Comments? -- Will Andrews <[EMAIL PROTECTED]> GCS/E/S @d- s+:+>+:- a--->+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++> DI+++ D+ G++>+++ e-> h! r-->+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT `make world` fails.. (ucontext.h?)
[cc'ing Marcel just in case he wants to volunteer any suggestion... :)] [also cc'ing Mike Smith since aout_freebsd.c seems to be his] [and cc'ing Peter too, since he dabbed a lot in that file] Will Andrews wrote: > ... > Is there any additional information I can provide (I noticed a related thread, > but DCS's reply didn't seem to help..)? I'm tracking this now. Well, I'll start tracking as soon as I finish my mail. I suggested first upgrading to 3.3 (or even 3.2), and only then to current. That _will_ work, as it will upgrade the loader. Alas, you need not even go to such pains. Just cvsup to -stable, cd /sys/boot; make depend && make all install, and then cvsup to -current, make the kernel, etc, etc. The person who first reported the problem said he succesfully used the loader from a recent snap. That will work. Go to a near FreeBSD ftp site, get the "loader" binary from a snapshot, copy it to /boot, and that will be able to load a -current kernel. Alternatively (I just thought of it), you might want to interrupt the boot at boot2 (press any key while the | is being displayed), and boot the kernel directly from there, avoiding going through loader. I'd be interested in hearing whether this can be used as a work-around or not. As for the problem it goes like this: FreeBSD 3.1's loader was not capable of loading a kernel at a different base address than the one FreeBSD used up to that point. Unfortunately, this resulted in an annoying bug that affected machines with lots of RAM and big maxusers (like, for instance, 256). This was corrected by moving the base address of kernel, which required modifications to loader. Thus, FreeBSD's 3.1 loader is not capable of booting a current kernel. Now, aout_freebsd.c (and possibly other files) in sys/boot/i386/libi386 includes sys/param.h, which, in turn, includes sys/signal.h. The later requires machine/ucontext.h, which is not present. Why the newer signal.h is found but not ucontext.h, I'll find out shortly (I hope :). For now, I'm working with the hypothesis of a "file.h" instead of #include. All things considered, this isn't much of a problem in itself. There is a huge problem here,though. Generally speaking, loader is immune to world troubles, since it uses libstand. But, are we not risking chicken-and-egg problems such as this by including standard sys/*.h? Situations where newer loaders are needed to boot a new kernel (as much as we would like loader to be able to handle all future kernels), but not being able to build them until a newer kernel is booted? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-CURRENT `make world` fails.. (ucontext.h?)
Hi, On a fresh cvsup of the -CURRENT sources, I've been trying to do a `make world`. I've gotten all the way through (past signal 12 errors, which were fixed by reading the -CURRENT archives and recompiling an up-to-date kernel) to the boot loader. Since the errors are on another box (which is in singleuser mode), I can't produce the exact log, however, I'll do my best copying it off its screen 10 feet from here..: ==> sys/boot/i386/libi386 cc -O -pipe -I/usr/src/sys/boot/i386/libi386 [...] In file from ... from ... from/usr/src/sys/boot/i386/libi386/aout_freebsd.c:29: /usr/src/sys/boot/i386/libi386/../../../sys/ucontext.h:34: machine/ucontext.h: No such file or directory. [...] *** Error code 1 --- I've looked around the src for a machine/ucontext.h. The particular including file, /usr/src/sys/sys/ucontext.h includes , so if it's looking at /usr/include/machine/ucontext.h, that's not there.. is this the correct file to be #include'ing? Is there any additional information I can provide (I noticed a related thread, but DCS's reply didn't seem to help..)? -- Will Andrews <[EMAIL PROTECTED]> GCS/E/S @d- s+:+>+:- a--->+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++> DI+++ D+ G++>+++ e-> h! r-->+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current make world failure (compat22)
>The following is error related to compat22 is causing a make release >to fail... Has mtree been updated approriately? A grep in /usr/src/etc/mtree/* shows there is no special handling for compat?? dists. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
-current make world failure (compat22)
Hi, The following is error related to compat22 is causing a make release to fail... Has mtree been updated approriately? thanks! John ===> lib/compat/compat22 cd /usr/src/lib/compat/compat22 ; make install DESTDIR=/R/stage/trees/compat22 SHARED=copies install -c -o root -g wheel -m 444 libalias.so.2.4 libc.so.3.1 libc_r.so.3.0 libcalendar.so.2.0 libcom_err.so.2.0 libcurses.so.2.0 libdialog.so.3.1 libedit.so.2.0 libf2c.so.2.0 libftpio.so.4.0 libg++.so.4.0 libgmp.so.3.0 libgnuregex.so.2.0 libipx.so.2.0 libkvm.so.2.0 libm.so.2.0 libmp.so.3.0 libmytinfo.so.2.0 libncurses.so.3.1 libopie.so.2.0 libpcap.so.2.2 libreadline.so.3.0 librpcsvc.so.2.0 libscrypt.so.2.0 libscsi.so.2.0 libskey.so.2.0 libss.so.2.0 libstdc++.so.2.0 libtelnet.so.2.0 libtermcap.so.2.1 libutil.so.2.2 libvgl.so.1.0 libxpg4.so.2.0 libz.so.2.0 /R/stage/trees/compat22/usr/lib/compat/aout usage: install [-CcDps] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-CcDps] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-g group] [-m mode] [-o owner] directory ... *** Error code 64 And looking at /R /snap/release/R/stage/trees %ls bin compat20des games manpages catpagescompat21dictinfoproflibs compat1xcompat3xdoc krb compat22 doesn't seem to exist... To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
