Re: lib/libgcc_s fails on make all after make world succeeds
On Sun, 2019-05-19 at 23:54 +0200, Dimitry Andric wrote: > On 19 May 2019, at 23:29, Julian H. Stacey wrote: > > > > Hi curr...@freebsd.org > > On current src/ on 2 boxes, I have seen the same break for a week > > or 2, > > lib/libgcc_s fails on make all after make world succeeds, > > Anyone else seen it or got ideas please ? Notes below the sample. > > > > ===> lib/libgcc_s (all) > > building shared library libgcc_s.so.1 > > cc -nodefaultlibs -Wl,--version- > > script=/usr/src/lib/libgcc_s/Version.map > > -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o \ > > libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1 > > ... > > -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \ > > ld: error: can't create dynamic relocation R_X86_64_32S \ > > against symbol: __je_sz_size2index_tab in readonly segment; \ > > recompile object files with -fPIC or pass '-Wl,-z,notext' \ > > to allow text relocations in the output > > > > > defined in > > > > > /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o) > > It looks like for some reason, it chooses to link with libc.a instead > of > libc.so here. Maybe your libc.so is not getting built at all, > because > of your environment? > > Or maybe you are hitting some build race where libc.a is done, but > libc.so is still being built, while at the same time, libgcc_s.so.1 > is > being linked? > > There are some difficult-to-reproduce races with libgcc_s, which are > sometimes also hit by CI (I think Li-Wen mentioned them multiple > times > now). But usually I would expect this to be "solved" by simply > re-running buildworld, as the race window is very small, and you have > to be quite lucky (or unlucky, depending on your point of view :) to > hit > it. > > -Dimitry > There is definitely something racy going on here. I ran into /usr/bin/ld: error: unable to find library -lgcc_s Just a couple minutes into a build with an empty /usr/obj. I killed it, re-emptied /usr/obj, and started it again, and it didn't repeat the problem. Also, I noticed that libgcc_eh and libgcc_s seem to be getting built twice in parallel here (this is about 2 minutes into a build of 12- stable on a 12-stable system) with -j16, so all of these libs started building together... -- >>> stage 4.2: building libraries -- ===> lib/libcompiler_rt (obj,all,install) ===> gnu/lib/libssp/libssp_nonshared (obj,all,install) ===> lib/libgcc_eh (obj,all,install) ===> lib/libgcc_s (obj,all,install) ===> gnu/lib/csu (obj,all,install) ===> lib/libcompiler_rt (obj,all,install) ===> lib/csu (obj,all,install) ===> lib/libc_nonshared (obj,all,install) ===> lib/libc (obj,all,install) ===> lib/libgcc_eh (obj,all,install) ===> lib/csu/amd64 (all) ===> lib/csu/amd64 (install) ===> lib/libgcc_s (obj,all,install) ===> lib/libcxxrt (obj,all,install) I've seen some bad things happen in the past when parallel jobs try to build in the same directory. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lib/libgcc_s fails on make all after make world succeeds
> On 19 May 2019, at 23:29, Julian H. Stacey wrote: > > > > Hi curr...@freebsd.org > > On current src/ on 2 boxes, I have seen the same break for a week or 2, > > lib/libgcc_s fails on make all after make world succeeds, > > Anyone else seen it or got ideas please ? Notes below the sample. > > > > ===> lib/libgcc_s (all) > > building shared library libgcc_s.so.1 > > cc -nodefaultlibs -Wl,--version-script=/usr/src/lib/libgcc_s/Version.map > > -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o \ > > libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1 > ... > > -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \ > > ld: error: can't create dynamic relocation R_X86_64_32S \ > > against symbol: __je_sz_size2index_tab in readonly segment; \ > > recompile object files with -fPIC or pass '-Wl,-z,notext' \ > > to allow text relocations in the output > >>>> defined in /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o) > > It looks like for some reason, it chooses to link with libc.a instead of > libc.so here. Maybe your libc.so is not getting built at all, because > of your environment? I've removed my environment variables & src.conf & make.conf, & new test running. > Or maybe you are hitting some build race where libc.a is done, but > libc.so is still being built, while at the same time, libgcc_s.so.1 is > being linked? > > There are some difficult-to-reproduce races with libgcc_s, which are > sometimes also hit by CI (I think Li-Wen mentioned them multiple times > now). But usually I would expect this to be "solved" by simply > re-running buildworld, as the race window is very small, and you have > to be quite lucky (or unlucky, depending on your point of view :) to hit > it. > > -Dimitry Thanks Dimitry, I'll re-read & consider but re. Race conditions, I hadnt thought of that. I never use make [-j max_jobs] and ls -l ~jhs/.MAKE.JOBS ~root/.MAKE.JOBS # shows nothing cd /usr/share/mk ; grep '\-j' * bsd.cpu.mk:_CPUCFLAGS = -march=i686 -falign-functions=0 -falign-jumps=0 -falign-loops=0 bsd.info.mk:.if !empty(.MAKEFLAGS:M-j) bsd.suffixes.mk:# XXX not -j safe bsd.suffixes.mk:# XXX not -j safe bsd.suffixes.mk:# XXX not -j safe gendirdeps.mk: echo '# local dependencies - needed for -jN in clean tree'; \ meta.stage.mk:# for non-jobs mode the order here matters cd /usr/src; grep '\-j' * Makefile:# make universe -DMAKE_JUST_KERNELS JFLAG=-j${_jflag} Makefile.inc1:echo "ncpu: $$(sysctl -n hw.ncpu)${.MAKE.JOBS:S/^/, make -j/}" Makefile.inc1:.if ${.MAKEFLAGS:M-j} Makefile.inc1:.error The buildenv target is incompatible with -j Makefile.inc1:echo "ncpu: $$(sysctl -n hw.ncpu)${.MAKE.JOBS:S/^/, make -j/}" Makefile.inc1: ${MAKE} -f Makefile.inc1 create-world-packages-jobs \ Makefile.inc1:.if make(create-world-packages-jobs) Makefile.inc1:create-world-packages-jobs: .PHONY Makefile.inc1:create-world-packages-jobs: create-world-package-${pkgname} UPDATING: Avoid using make -j when upgrading. While generally safe, there are UPDATING: sometimes problems using -j to upgrade. If your upgrade fails with UPDATING: -j, please try again without -j. From time to time in the past there UPDATING: have been problems using -j with buildworld and/or installworld. This My 2 current hosts are old, a lot slower than I guess most developers use: --- FreeBSD 13.0-CURRENT #14033: Sat May 11 18:48:02 CEST 2019 j...@blak.js.berklix.net:/usr/src/sys/amd64/compile/BLAK.small amd64 FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) VT(vga): resolution 640x480 CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3000.00-MHz K8-class CPU) Origin="GenuineIntel" Id=0x6fb Family=0x6 Model=0xf Stepping=11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 VT-x: HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4096159744 (3906 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) __stack_chk_init: WARNING: Initializing stack protection with non-random cookies! __stack_chk_init: WARNING: This severely limits the benefit of -fstack-protector! ioapic0: Changing APIC ID to 2 --- FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #14033: Sat May 11 18:56:03 CEST 2019 j...@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small amd64 FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) VT(vga): resolution 640x480 module urndis already present! module_register: cannot register pccard/wi fr
Re: lib/libgcc_s fails on make all after make world succeeds
On 19 May 2019, at 23:29, Julian H. Stacey wrote: > > Hi curr...@freebsd.org > On current src/ on 2 boxes, I have seen the same break for a week or 2, > lib/libgcc_s fails on make all after make world succeeds, > Anyone else seen it or got ideas please ? Notes below the sample. > > ===> lib/libgcc_s (all) > building shared library libgcc_s.so.1 > cc -nodefaultlibs -Wl,--version-script=/usr/src/lib/libgcc_s/Version.map > -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o \ > libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1 ... > -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \ > ld: error: can't create dynamic relocation R_X86_64_32S \ > against symbol: __je_sz_size2index_tab in readonly segment; \ > recompile object files with -fPIC or pass '-Wl,-z,notext' \ > to allow text relocations in the output >>>> defined in /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o) It looks like for some reason, it chooses to link with libc.a instead of libc.so here. Maybe your libc.so is not getting built at all, because of your environment? Or maybe you are hitting some build race where libc.a is done, but libc.so is still being built, while at the same time, libgcc_s.so.1 is being linked? There are some difficult-to-reproduce races with libgcc_s, which are sometimes also hit by CI (I think Li-Wen mentioned them multiple times now). But usually I would expect this to be "solved" by simply re-running buildworld, as the race window is very small, and you have to be quite lucky (or unlucky, depending on your point of view :) to hit it. -Dimitry signature.asc Description: Message signed with OpenPGP
lib/libgcc_s fails on make all after make world succeeds
Hi curr...@freebsd.org On current src/ on 2 boxes, I have seen the same break for a week or 2, lib/libgcc_s fails on make all after make world succeeds, Anyone else seen it or got ideas please ? Notes below the sample. ===> lib/libgcc_s (all) building shared library libgcc_s.so.1 cc -nodefaultlibs -Wl,--version-script=/usr/src/lib/libgcc_s/Version.map -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o \ libgcc_s.so.1.full -Wl,-soname,libgcc_s.so.1 `NM='nm' NMFLAGS='' \ lorder absvdi2.pico absvsi2.pico absvti2.pico addvdi3.pico addvsi3.pico \ addvti3.pico apple_versioning.pico ashldi3.pico ashlti3.pico \ ashrdi3.pico ashrti3.pico clear_cache.pico clzdi2.pico clzsi2.pico \ clzti2.pico cmpdi2.pico cmpti2.pico ctzdi2.pico ctzsi2.pico ctzti2.pico \ divdc3.pico divdi3.pico divmoddi4.pico divmodsi4.pico divsc3.pico \ divsi3.pico divtc3.pico divti3.pico divxc3.pico enable_execute_stack.pico \ eprintf.pico extendhfsf2.pico ffsdi2.pico ffssi2.pico ffsti2.pico \ fixdfdi.pico fixdfti.pico fixsfdi.pico fixsfti.pico fixunsdfdi.pico \ fixunsdfsi.pico fixunsdfti.pico fixunssfdi.pico fixunssfsi.pico \ fixunssfti.pico fixunsxfdi.pico fixunsxfsi.pico fixunsxfti.pico \ fixxfdi.pico fixxfti.pico floatditf.pico floatsitf.pico floattidf.pico \ floattisf.pico floattixf.pico floatunditf.pico floatunsidf.pico \ floatunsisf.pico floatuntidf.pico floatuntisf.pico floatuntixf.pico \ gcc_personality_v0.pico int_util.pico lshrdi3.pico lshrti3.pico \ moddi3.pico modsi3.pico modti3.pico muldc3.pico muldi3.pico \ mulodi4.pico mulosi4.pico muloti4.pico mulsc3.pico multi3.pico \ mulvdi3.pico mulvsi3.pico mulvti3.pico multc3.pico mulxc3.pico \ negdf2.pico negdi2.pico negsf2.pico negti2.pico negvdi2.pico \ negvsi2.pico negvti2.pico paritydi2.pico paritysi2.pico parityti2.pico \ popcountdi2.pico popcountsi2.pico popcountti2.pico powidf2.pico \ powisf2.pico powitf2.pico powixf2.pico subvdi3.pico subvsi3.pico \ subvti3.pico trampoline_setup.pico truncdfhf2.pico truncsfhf2.pico \ ucmpdi2.pico ucmpti2.pico udivdi3.pico udivmoddi4.pico udivmodsi4.pico \ udivmodti4.pico udivsi3.pico udivti3.pico umoddi3.pico umodsi3.pico \ umodti3.pico floatdidf.pico floatdisf.pico floatdixf.pico \ floatundidf.pico floatundisf.pico floatundixf.pico cpu_model.pico \ adddf3.pico addsf3.pico divdf3.pico divsf3.pico extendsfdf2.pico \ fixdfsi.pico fixsfsi.pico floatsidf.pico floatsisf.pico muldf3.pico \ mulsf3.pico subdf3.pico subsf3.pico truncdfsf2.pico comparedf2.pico \ comparesf2.pico gcc_personality_v0.pico int_util.pico Unwind-EHABI.pico \ Unwind-sjlj.pico UnwindLevel1-gcc-ext.pico UnwindLevel1.pico \ UnwindRegistersRestore.pico UnwindRegistersSave.pico libunwind.pico \ s_fabs.pico s_fabsf.pico s_fabsl.pico s_fmax.pico s_fmaxf.pico \ s_logb.pico s_logbf.pico s_scalbn.pico s_scalbnf.pico s_fmaxl.pico \ s_logbl.pico s_scalbnl.pico | tsort -q` \ -L/usr/obj/usr/src/amd64.amd64/lib/libc -lc \ ld: error: can't create dynamic relocation R_X86_64_32S \ against symbol: __je_sz_size2index_tab in readonly segment; \ recompile object files with -fPIC or pass '-Wl,-z,notext' \ to allow text relocations in the output >>> defined in /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_sz.o) >>> referenced by sz.h:0 \ (/usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:0) >>> jemalloc_jemalloc.o:(a0ialloc) in archive \ /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a ld: error: can't create dynamic relocation R_X86_64_32 against local symbol \ in readonly segment; recompile object files with -fPIC or pass \ '-Wl,-z,notext' to allow text relocations in the output >>> defined in /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a(jemalloc_jemalloc.o) >>> referenced by mutex.h:144 \ (/usr/src/contrib/jemalloc/include/jemalloc/internal/mutex.h:144) >>> jemalloc_jemalloc.o:(a0ialloc) in archive \ /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a - First i thought it was my custom src/ but generic src/ breaks too. Then I did: /etc/src.conf Removed /etc/make.conf Removed env varsStripped to just PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin TERM=xterm TERMPATH=/etc/termcap:/usr/share/misc/termcap A new make buildworld is running on virgin generic src/ inside a script with cat .svn_revision 347964 cat .ctm_status src-cur 14046 That will take a while before I can report. Meantime I also have a 2nd box I can experiment on if people have ideas ? cat .svn_revision 347422 cat .ctm_status src-cur 14033 Cheers, Julian -- Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. ___
Re: r245838: make world fails: /usr/src/usr.bin/dtc/dtc.cc:196:24: error: use of undeclared identifier 'optarg', string arg = string(optarg);
This appears to be caused by your addition of -stdlib=libc++ -std=c++11 to your CXXFLAGS. So, first of all, thank you for testing libc++! I tested with libc++ while I was developing dtc, but then was building with libstdc++ while I was removing extraneous includes. Unfortunately, libstdc++ leaks a load of C headers, whereas libc++ is very careful not to. I've now (r245839) explicitly included everything so it now builds with libc++ and in C++11 mode. Thanks for the report, David On 23 Jan 2013, at 08:15, O. Hartmann wrote: > Make world fails in /usr/src/usr.bin/dtc/dtc.cc with a lot of errors > com[laining about an undeclared identifier: > > [...] > ===> usr.bin/dtc (obj,depend,all,install) > /usr/obj/usr/src/tmp/usr/src/usr.bin/dtc created for /usr/src/usr.bin/dtc > rm -f .depend > mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include > -std=c++11 -stdlib=libc++ /usr/src/usr.bin/dtc/dtc.cc > /usr/src/usr.bin/dtc/input_buffer.cc /usr/src/usr.bin/dtc/string.cc > /usr/src/usr.bin/dtc/dtb.cc /usr/src/usr.bin/dtc/fdt.cc > /usr/src/usr.bin/dtc/checking.cc > echo dtc: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >>> .depend > echo dtc: /usr/lib/libc++.a >> .depend > c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include > -stdlib=libc++ -std=c++11 -c /usr/src/usr.bin/dtc/dtc.cc > c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include > -stdlib=libc++ -std=c++11 -c /usr/src/usr.bin/dtc/input_buffer.cc > /usr/src/usr.bin/dtc/input_buffer.cc:116:11: error: use of undeclared > identifier 'strtoll' > [...] > 7 errors generated. > *** [string.o] Error code 1 > /usr/src/usr.bin/dtc/input_buffer.cc:218:10: error: use of undeclared > identifier 'stderr' >fprintf(stderr, "Current cursor: %d\n", cursor); >^ > /usr/src/usr.bin/dtc/input_buffer.cc:219:42: error: use of undeclared > identifier 'stderr' >fwrite(&buffer[cursor], size-cursor, 1, stderr); >^ > /usr/src/usr.bin/dtc/input_buffer.cc:227:3: error: use of undeclared > identifier 'perror' >perror("Failed to stat file"); >^ > /usr/src/usr.bin/dtc/input_buffer.cc:234:3: error: use of undeclared > identifier 'perror' >perror("Failed to mmap file"); >^ > /usr/src/usr.bin/dtc/input_buffer.cc:249:20: error: use of undeclared > identifier 'stdin' >while ((c = fgetc(stdin)) != EOF) > ^ > /usr/src/usr.bin/dtc/input_buffer.cc:249:31: error: use of undeclared > identifier 'EOF' >while ((c = fgetc(stdin)) != EOF) > ^ > 15 errors generated. > *** [input_buffer.o] Error code 1 > /usr/src/usr.bin/dtc/dtb.cc:87:2: error: use of undeclared identifier > 'write' >write(fd, buffer.data(), buffer.size()); >^ > /usr/src/usr.bin/dtc/dtb.cc:125:2: error: use of undeclared identifier > 'snprintf'; did you mean 'vswprintf'? >snprintf(out, 3, "%.2hhx", b); >^~~~ >vswprintf > /usr/include/wchar.h:130:5: note: 'vswprintf' declared here > int vswprintf(wchar_t * __restrict, size_t n, const wchar_t * > __restrict, >^ > /usr/src/usr.bin/dtc/dtb.cc:125:11: error: cannot initialize a parameter > of type 'wchar_t *' with an lvalue of type 'char [3]' >snprintf(out, 3, "%.2hhx", b); > ^~~ > /usr/include/wchar.h:130:35: note: passing argument to parameter here > int vswprintf(wchar_t * __restrict, size_t n, const wchar_t * > __restrict, > ^ > /usr/src/usr.bin/dtc/dtb.cc:218:2: error: use of undeclared identifier > 'write' >write(fd, buffer.data(), buffer.size()); >^ > /usr/src/usr.bin/dtc/dtb.cc:259:11: error: use of undeclared identifier > 'stderr' >fprintf(stderr, "Missing magic token in header. Got %" > PRIx32 >^ > 5 errors generated. > *** [dtb.o] Error code 1 > /usr/src/usr.bin/dtc/dtc.cc:102:15: error: use of undeclared identifier > 'getopt' >while ((ch = getopt(argc, argv, options)) != -1) > [...] > signature.asc Description: Message signed with OpenPGP using GPGMail
r245838: make world fails: /usr/src/usr.bin/dtc/dtc.cc:196:24: error: use of undeclared identifier 'optarg', string arg = string(optarg);
Make world fails in /usr/src/usr.bin/dtc/dtc.cc with a lot of errors com[laining about an undeclared identifier: [...] ===> usr.bin/dtc (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/usr.bin/dtc created for /usr/src/usr.bin/dtc rm -f .depend mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -stdlib=libc++ /usr/src/usr.bin/dtc/dtc.cc /usr/src/usr.bin/dtc/input_buffer.cc /usr/src/usr.bin/dtc/string.cc /usr/src/usr.bin/dtc/dtb.cc /usr/src/usr.bin/dtc/fdt.cc /usr/src/usr.bin/dtc/checking.cc echo dtc: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend echo dtc: /usr/lib/libc++.a >> .depend c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include -stdlib=libc++ -std=c++11 -c /usr/src/usr.bin/dtc/dtc.cc c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include -stdlib=libc++ -std=c++11 -c /usr/src/usr.bin/dtc/input_buffer.cc /usr/src/usr.bin/dtc/input_buffer.cc:116:11: error: use of undeclared identifier 'strtoll' [...] 7 errors generated. *** [string.o] Error code 1 /usr/src/usr.bin/dtc/input_buffer.cc:218:10: error: use of undeclared identifier 'stderr' fprintf(stderr, "Current cursor: %d\n", cursor); ^ /usr/src/usr.bin/dtc/input_buffer.cc:219:42: error: use of undeclared identifier 'stderr' fwrite(&buffer[cursor], size-cursor, 1, stderr); ^ /usr/src/usr.bin/dtc/input_buffer.cc:227:3: error: use of undeclared identifier 'perror' perror("Failed to stat file"); ^ /usr/src/usr.bin/dtc/input_buffer.cc:234:3: error: use of undeclared identifier 'perror' perror("Failed to mmap file"); ^ /usr/src/usr.bin/dtc/input_buffer.cc:249:20: error: use of undeclared identifier 'stdin' while ((c = fgetc(stdin)) != EOF) ^ /usr/src/usr.bin/dtc/input_buffer.cc:249:31: error: use of undeclared identifier 'EOF' while ((c = fgetc(stdin)) != EOF) ^ 15 errors generated. *** [input_buffer.o] Error code 1 /usr/src/usr.bin/dtc/dtb.cc:87:2: error: use of undeclared identifier 'write' write(fd, buffer.data(), buffer.size()); ^ /usr/src/usr.bin/dtc/dtb.cc:125:2: error: use of undeclared identifier 'snprintf'; did you mean 'vswprintf'? snprintf(out, 3, "%.2hhx", b); ^~~~ vswprintf /usr/include/wchar.h:130:5: note: 'vswprintf' declared here int vswprintf(wchar_t * __restrict, size_t n, const wchar_t * __restrict, ^ /usr/src/usr.bin/dtc/dtb.cc:125:11: error: cannot initialize a parameter of type 'wchar_t *' with an lvalue of type 'char [3]' snprintf(out, 3, "%.2hhx", b); ^~~ /usr/include/wchar.h:130:35: note: passing argument to parameter here int vswprintf(wchar_t * __restrict, size_t n, const wchar_t * __restrict, ^ /usr/src/usr.bin/dtc/dtb.cc:218:2: error: use of undeclared identifier 'write' write(fd, buffer.data(), buffer.size()); ^ /usr/src/usr.bin/dtc/dtb.cc:259:11: error: use of undeclared identifier 'stderr' fprintf(stderr, "Missing magic token in header. Got %" PRIx32 ^ 5 errors generated. *** [dtb.o] Error code 1 /usr/src/usr.bin/dtc/dtc.cc:102:15: error: use of undeclared identifier 'getopt' while ((ch = getopt(argc, argv, options)) != -1) [...] signature.asc Description: OpenPGP digital signature
Re: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
Am 04/02/12 16:06, schrieb Alexander Kabaev: > On Mon, 02 Apr 2012 14:32:51 +0200 > "O. Hartmann" wrote: > >> Hello out there. >> >> My FreeBSD 10 box is at revision r233779. I updated the sources this >> morning and made a buildworld successfully. >> >> After a reboot of the box, I witness several bad issues. Firefox, for >> instance, is droppimng a core now when starting. Using portmaster for >> updates produces a lot of Segmentation faults on the screen. Othe >> minor clients which were working prior to the update today (last >> makeworl on Friday last week) aren't any more and dropping cores. >> >> Does anyone also realize this on FreeBSD 10 boxes? >> >> I use CLANG as the base compiler and also for the ports (for those >> which are compiling with CLANG). >> >> Regards, >> Oliver >> > > > Since you did not provide any details, I'd have to guess and I am > guessing this is an interaction between rtld and new libstdc++ that is > a likely cause for the crashes. Please try with revision r233778. Sorry for the late response. Indeed, I use the tag WITH_LIBCPLUSPLUS= YES in /etc/src.cnf. After an upgrade of the sources shortly after I posted the mail in the list, I recompiled the newly sources and reinstalled the system again and all problems I reported before were gone. Sorry for the noise. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
In message <4f79abf1.70...@lissyara.su>, Alex Keda writes: >02.04.2012 16:32, O. Hartmann пиÑеÑ: >> Firefox, for instance, is droppimng a core now when starting. I tried r233749M and saw the same thing. This Warning looks non-ignorable to me, but I havn't investigated: ===> gnu/lib/libssp (all) /freebsd/head/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c: In function 'fail': /freebsd/head/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:109: warning: implicit declaration of function 'alloca' /freebsd/head/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:109: warning: incompatible implicit declaration of built-in function 'alloca' -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
On Mon, 2 Apr 2012 10:06:38 -0400 Alexander Kabaev wrote: > On Mon, 02 Apr 2012 14:32:51 +0200 > "O. Hartmann" wrote: > > > Hello out there. > > > > My FreeBSD 10 box is at revision r233779. I updated the sources this > > morning and made a buildworld successfully. > > > > After a reboot of the box, I witness several bad issues. Firefox, > > for instance, is droppimng a core now when starting. Using > > portmaster for updates produces a lot of Segmentation faults on the > > screen. Othe minor clients which were working prior to the update > > today (last makeworl on Friday last week) aren't any more and > > dropping cores. > > > > Does anyone also realize this on FreeBSD 10 boxes? > > > > I use CLANG as the base compiler and also for the ports (for those > > which are compiling with CLANG). > > > > Regards, > > Oliver > > > I guess I should correct myself, you already should have the fix in. Please collect some backtraces. -- Alexander Kabaev signature.asc Description: PGP signature
Re: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
On Mon, 02 Apr 2012 14:32:51 +0200 "O. Hartmann" wrote: > Hello out there. > > My FreeBSD 10 box is at revision r233779. I updated the sources this > morning and made a buildworld successfully. > > After a reboot of the box, I witness several bad issues. Firefox, for > instance, is droppimng a core now when starting. Using portmaster for > updates produces a lot of Segmentation faults on the screen. Othe > minor clients which were working prior to the update today (last > makeworl on Friday last week) aren't any more and dropping cores. > > Does anyone also realize this on FreeBSD 10 boxes? > > I use CLANG as the base compiler and also for the ports (for those > which are compiling with CLANG). > > Regards, > Oliver > Since you did not provide any details, I'd have to guess and I am guessing this is an interaction between rtld and new libstdc++ that is a likely cause for the crashes. Please try with revision r233778. -- Alexander Kabaev signature.asc Description: PGP signature
Re: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
02.04.2012 16:32, O. Hartmann пишет: Hello out there. My FreeBSD 10 box is at revision r233779. I updated the sources this morning and made a buildworld successfully. After a reboot of the box, I witness several bad issues. Firefox, for instance, is droppimng a core now when starting. Using portmaster for updates produces a lot of Segmentation faults on the screen. Othe minor clients which were working prior to the update today (last makeworl on Friday last week) aren't any more and dropping cores. Does anyone also realize this on FreeBSD 10 boxes? I use CLANG as the base compiler and also for the ports (for those which are compiling with CLANG). Regards, Oliver confirm, for amd64 using gcc ___ 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"
FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
Hello out there. My FreeBSD 10 box is at revision r233779. I updated the sources this morning and made a buildworld successfully. After a reboot of the box, I witness several bad issues. Firefox, for instance, is droppimng a core now when starting. Using portmaster for updates produces a lot of Segmentation faults on the screen. Othe minor clients which were working prior to the update today (last makeworl on Friday last week) aren't any more and dropping cores. Does anyone also realize this on FreeBSD 10 boxes? I use CLANG as the base compiler and also for the ports (for those which are compiling with CLANG). Regards, Oliver signature.asc Description: OpenPGP digital signature
make world failure r232929
cc -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/include -std=gnu99 -c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/sprintf-chk.c -o sprintf-chk.So ctfconvert -L VERSION sprintf-chk.So cc -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/include -std=gnu99 -c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/stpcpy-chk.c -o stpcpy-chk.So ctfconvert -L VERSION stpcpy-chk.So cc -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/include -std=gnu99 -c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/strcat-chk.c -o strcat-chk.So ctfconvert -L VERSION strcat-chk.So cc -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/include -std=gnu99 -c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/strcpy-chk.c -o strcpy-chk.So ctfconvert -L VERSION strcpy-chk.So cc -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/include -std=gnu99 -c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/strncat-chk.c -o strncat-chk.So ctfconvert -L VERSION strncat-chk.So cc -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/include -std=gnu99 -c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/strncpy-chk.c -o strncpy-chk.So ctfconvert -L VERSION strncpy-chk.So cc -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/include -std=gnu99 -c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/vsnprintf-chk.c -o vsnprintf-chk.So ctfconvert -L VERSION vsnprintf-chk.So cc -fpic -DPIC -O2 -pipe -fno-omit-frame-pointer -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp -I/usr/src/gnu/lib/libssp/../../../contrib/gcclibs/include -std=gnu99 -c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/vsprintf-chk.c -o vsprintf-chk.So ctfconvert -L VERSION vsprintf-chk.So building shared library libssp.so.0 ctfmerge -L VERSION -o libssp.so.0 ssp.So gets-chk.So memcpy-chk.So memmove-chk.So mempcpy-chk.So memset-chk.So snprintf-chk.So sprintf-chk.So stpcpy-chk.So strcat-chk.So strcpy-chk.So strncat-chk.So strncpy-chk.So vsnprintf-chk.So vsprintf-chk.So ERROR: ctfmerge: libssp.so.0: Cannot get sect .gnu.version_d data: Invalid section descriptor ===> gnu/lib/libssp/libssp_nonshared (all) ===> gnu/lib/libstdc++ (all) c++ -O2 -pipe -fno-omit-frame-pointer -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. -frandom-seed=RepeatabilityConsideredGood -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/bitmap_allocator.cc -o bitmap_allocator.o c++ -O2 -pipe -fno-omit-frame-pointer -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. -frandom-seed=RepeatabilityConsideredGood -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/pool_allocator.cc -o pool_allocator.o c++ -O2 -pipe -fno-omit-frame-pointer -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libs
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: dumb question 'Bad system call' after make world
On Fri, 21 Nov 2003, Barney Wolff wrote: > Does make world build a kernel? I didn't think so, and OP's message > indicates that make world is all he did. I suspect re-install is the > best answer now. > > Will somebody please tell me when "make world" is ever correct in the > environment of the last several years? I've been unable to understand > its continued existence as a target. I'd call it hysterical raisins, but there are some decomposed targets, which I use regularly: buildworld buildkernel installworld installkernel -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: dumb question 'Bad system call' after make world
From: Barney Wolff [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 22, 2003 1:14 PM > To: Bruce Evans > Cc: [EMAIL PROTECTED] > Subject: Re: dumb question 'Bad system call' after make world > > > On Sat, Nov 22, 2003 at 11:42:04PM +1100, Bruce Evans wrote: > > On Fri, 21 Nov 2003, Barney Wolff wrote: > > > > > Will somebody please tell me when "make world" is ever > correct in the > > > environment of the last several years? I've been unable > to understand > > > its continued existence as a target. > > > > >From my normal world-building script: > > > > DESTDIR=/c/z/root \ > > MAKEOBJDIRPREFIX=/c/z/obj \ > > time -l make -s world > /tmp/world.out 2>&1 > > Oh, so it's only correct when you're not really installing world on > the system you're building on? Would replacing this with > ( make buildworld && make installworld ) really be a hardship? > Must we continue to invite innocents to clobber their systems? For interest, in case this happens to someone else, i 'fixed' it by booting from the mini iso disk, inserting disk 2 (live), going to a shell, and copying all of /bin, /usr/bin, /usr/lib, /usr/libexec, /lib over to the hd, rebooting, and then doing the rest of the normal steps. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dumb question 'Bad system call' after make world
On Sat, Nov 22, 2003 at 11:42:04PM +1100, Bruce Evans wrote: > On Fri, 21 Nov 2003, Barney Wolff wrote: > > > Will somebody please tell me when "make world" is ever correct in the > > environment of the last several years? I've been unable to understand > > its continued existence as a target. > > >From my normal world-building script: > > DESTDIR=/c/z/root \ > MAKEOBJDIRPREFIX=/c/z/obj \ > time -l make -s world > /tmp/world.out 2>&1 Oh, so it's only correct when you're not really installing world on the system you're building on? Would replacing this with ( make buildworld && make installworld ) really be a hardship? Must we continue to invite innocents to clobber their systems? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dumb question 'Bad system call' after make world
On Fri, 21 Nov 2003, Barney Wolff wrote: > Will somebody please tell me when "make world" is ever correct in the > environment of the last several years? I've been unable to understand > its continued existence as a target. >From my normal world-building script: DESTDIR=/c/z/root \ MAKEOBJDIRPREFIX=/c/z/obj \ time -l make -s world > /tmp/world.out 2>&1 Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dumb question 'Bad system call' after make world
Hello, On Fri, Nov 21, 2003 at 09:44:17PM -0500, Barney Wolff wrote: > Does make world build a kernel? I didn't think so, and OP's message > indicates that make world is all he did. I suspect re-install is the > best answer now. Yes, make world does not build or install kernels. I'd also go for reinstall, provided the OP has not yet put a lot of work into customising the install... > Will somebody please tell me when "make world" is ever correct in the > environment of the last several years? I've been unable to understand > its continued existence as a target. One of it's last hideouts seems to be the "make release" target... -- Regards: Szilveszter ADAM Budapest Hungary ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dumb question 'Bad system call' after make world
On Fri, Nov 21, 2003 at 05:35:59PM -0800, Doug White wrote: > On Fri, 21 Nov 2003, Don Bowman wrote: > > > > > So i have a machine freshly installed from 5.1 mini iso. > > I did a cvs co of latest current sources, and accidentally > > did a 'make world' instead of 'make buildworld'. > > Now i just get 'Bad system call' when i try to do anything. > > i need to get the correct kernel on there, does anyone have a > > suggestion for how to fix this? > > If you have it, boot off of the mini iso, pull down and burn CD 2, then > use the fixit facility to start a fixit shell with teh CD. From there > manually install the new kernel (it'll be in > /usr/obj/usr/src/sys/KERNELNAME/kernel) and boot from it. From there you > should be able to finish the installworld. Does make world build a kernel? I didn't think so, and OP's message indicates that make world is all he did. I suspect re-install is the best answer now. Will somebody please tell me when "make world" is ever correct in the environment of the last several years? I've been unable to understand its continued existence as a target. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dumb question 'Bad system call' after make world
On Fri, 21 Nov 2003, Don Bowman wrote: > > So i have a machine freshly installed from 5.1 mini iso. > I did a cvs co of latest current sources, and accidentally > did a 'make world' instead of 'make buildworld'. > Now i just get 'Bad system call' when i try to do anything. > i need to get the correct kernel on there, does anyone have a > suggestion for how to fix this? If you have it, boot off of the mini iso, pull down and burn CD 2, then use the fixit facility to start a fixit shell with teh CD. From there manually install the new kernel (it'll be in /usr/obj/usr/src/sys/KERNELNAME/kernel) and boot from it. From there you should be able to finish the installworld. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dumb question 'Bad system call' after make world
On Fri, 21 Nov 2003, Don Bowman wrote: > > So i have a machine freshly installed from 5.1 mini iso. > I did a cvs co of latest current sources, and accidentally > did a 'make world' instead of 'make buildworld'. > Now i just get 'Bad system call' when i try to do anything. > i need to get the correct kernel on there, does anyone have a > suggestion for how to fix this? > > --don Probably the easiest thing will be to start over with a fresh 5.1 install, then follow the steps in UPDATING of make buildworld make kernel reboot to single user make installworld mergemaster reboot Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dumb question 'Bad system call' after make world
So i have a machine freshly installed from 5.1 mini iso. I did a cvs co of latest current sources, and accidentally did a 'make world' instead of 'make buildworld'. Now i just get 'Bad system call' when i try to do anything. i need to get the correct kernel on there, does anyone have a suggestion for how to fix this? --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recovery? recent "make world" rendered system unusable (64 bit change)
Barney Wolff <[EMAIL PROTECTED]> writes: > Re-install/upgrade from a cd. Upgrade should leave your files alone. Thanks, Barney -- that's what I did and it saved my butt. A few folks suggested either LiveCD images or "fixit" functionality. I was kinda dead in the water and didn't think I could download a LiveCD and burn it from another system. I played with the floppy "fixit" functionality a bit but didn't see a way to preserve /etc and such. So I used a 5.1-RELEASE CD I had and used the UPGRADE option which promised to save my /etc stuff. I specified my old mount points (fortunately, I was able to read /etc/fstab from the boot "OK" prompt and make paper notes!). I then tried -- twice -- to install the "minimal" system from the CD and both times it kernel panic'd with a page fault (in process bufdaemon, last time). For grins, I again specified my mounts (only /, /var, /tmp, /usr; I didn't bother with /home and /usr/local), and told it to install via FTP. Surprisingly, this worked -- no panic. It appears to have installed a working kernel, /bin, /usr/bin, and friends and now I'm running again. I'm now doing a "make build world" and then will do a "make kernel KERNCONF=MyKernelDefinitionFileName", then finally a "make installworld" per the UPGRADING guide. I've never used the Upgrade option to FreeBSD and I've been using it heavily since 2.2.x. It's a good thing. Many thanks to everyone who replied. I promise I'll scan UPGRADING before doing a "make *world" next time! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recovery? recent "make world" rendered system unusable (64 bit change)
On Tue, 2003-11-18 at 08:50, Chris Shenton wrote: > I've been running 5.1-CURRENT for a while and a couple nights ago did > a "make world". After a couple hours building, my system was > unusable. Critical binaries like "rm", "ls", "mtree", "sh" failed, > reporting "Exec format error". I can't login, not even single user. > I can no longer even boot single user. > > I've hosed my system and am looking for a way to recover without > having to reinstall everything and overwrite critical data and system > config files. Naturally, I only discovered the note in UPDATING after > I trashed my system -- in fact, I read it from the "OK" boot prompt > with its "more". Doh! > > 20031112: The statfs structure has been updated with 64-bit fields > to allow accurate reporting of multi-terabyte filesystem sizes. You > should build world, then build and boot the new kernel BEFORE doing > a `installworld' as the new kernel will know about binaries using > the old statfs structure, but an old kernel will not know about the > new system calls that support the new statfs structure. [...] > Running an old kernel after a `make world' will cause programs such > as `df' that do a statfs system call to fail with a bad system > call. [...] DO NOT make installworld after the buildworld w/o > building and installing a new kernel FIRST. You will be unable to > build a new kernel otherwise on a system with new binaries and an > old kernel. > > I'm looking for recommendations on how to recover, hopefully without > trashing my critical system files like /etc/passwd. Ideally, I guess > I'd like a way to replace all the broken binaries and any related > libraries without overwriting other files. > > If I do a floppy-based install and then select Custom/Expert than > request a minimal install, I presume it will install a small set of > binaries but also overwrite /etc/passwd, /etc/ssh/* and so on. Is > there a way to have it just update binaries and libraries? > > If I have to, I could add another disk to this box. Then I could do a > floppy install of 5.x on to that new disk. Then I could boot it, and > mount the old disk's partitions. Then install the new install's > binaries on the old partitions. Or perhaps I could do a make > buildworld, kernel, installworld the proper way, using the old disk's > partitions as the target. > > Or could I -- somehow -- push a 64-bit-aware kernel onto this box so > that the newly "broken" binaries will work again? How? Again, I've > got no shell access any more so everything's gonna have to be done > from floppy or maybe CD if I can borrow a burner. Naturally, this is > my net boot server for my diskless clients so I can't go that route > either. :-( > > Any other suggestions? Thanks. > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" Best suggestion would be to get a 5.0-CURRENT live CD off of current.snapshot.org with the kernel with the new statfs changes if it exists (I forget if we make live CD's daily or not) That or you can loadup a emergency holoshell of 5.1 RELEASE, reinstall /bin /sbin /usr/sbin etc and then rebuild the kernel to the new statfs kernel, then install the new world once again. The basic problem is you need a kernel with the new statfs changes, maybe you can find someone nice enough here to email you their kernel with the new changes that'll boot on your computer, and then you can get it corrected. Even I had that problem, luckily the machine was just a test machine so reinstallation wasn't going to kill me. Scott -- "I think we ought to be out there doing what we do best - making large holes in other people's countries." - George Carlin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recovery? recent 'make world' rendered system unusable (64 bit change)
Allegedly Chris Shenton said > "masta" <[EMAIL PROTECTED]> writes: > >> The easy way is to grab a recent livecd from the jp snapshot service. >> With the jpsnap livecd I was able to boot, copy all the working >> binaries from the cdrom over the corrupt binaries on the local HDD. I >> suggest you try the same idea. > > [ http://livecd.sourceforge.net/ ] > That seems a like a nice suite, but the site says it's acts like a 4.6 > repair, so I don't think the binaries would be suitable for replacing my > damaged 5.1 commands. :-( I wasn't talking about that, I was talking about the jp snapshot service, which is accessible at: http://snapshots.jp.freebsd.org/ The site speaks for itself, but basicly it is a dailly snapshot service for FreeBSD, which by now should have all the fixes you need on their livecd version of -cuurent. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recovery? recent "make world" rendered system unusable (64 bit change)
"masta" <[EMAIL PROTECTED]> writes: > The easy way is to grab a recent livecd from the jp snapshot service. > [ http://livecd.sourceforge.net/ ] > > With the jpsnap livecd I was able to boot, copy all the working > binaries from the cdrom over the corrupt binaries on the local HDD. I > suggest you try the same idea. That seems a like a nice suite, but the site says it's acts like a 4.6 repair, so I don't think the binaries would be suitable for replacing my damaged 5.1 commands. :-( ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recovery? recent "make world" rendered system unusable (64 bit change)
On Tue, Nov 18, 2003 at 11:50:22AM -0500, Chris Shenton wrote: > I've been running 5.1-CURRENT for a while and a couple nights ago did > a "make world". After a couple hours building, my system was > unusable. Critical binaries like "rm", "ls", "mtree", "sh" failed, > reporting "Exec format error". I can't login, not even single user. > I can no longer even boot single user. Re-install/upgrade from a cd. Upgrade should leave your files alone. I've argued before that "world" should be removed as a target, as I don't believe it's ever correct to do it. Why leave this gun pointed at people's feet? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recovery? recent "make world" rendered system unusable (64 bit change)
Hiya, Chris Shenton wrote: ... [snip] ... > > Any other suggestions? Thanks. > Yes, You need to exploit the notion of booting from another root filesystem, mounting the broken root, and then taking corrective action on the corrupted files. The easy way is to grab a recent livecd from the jp snapshot service. With the jpsnap livecd I was able to boot, copy all the working binaries from the cdrom over the corrupt binaries on the local HDD. I suggest you try the same idea. Certainly there are other ways to do the same exact thing, but without the time and expense of downloading the iso9660 image, and burning a rom. Certainly you could make due with a set of floppies, and/or nfs from another -current machine. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Recovery? recent "make world" rendered system unusable (64 bit change)
In message: <[EMAIL PROTECTED]> Chris Shenton <[EMAIL PROTECTED]> writes: : I'm looking for recommendations on how to recover, hopefully without : trashing my critical system files like /etc/passwd. Ideally, I guess : I'd like a way to replace all the broken binaries and any related : libraries without overwriting other files. Grab a recent snapshot. Boot off of that with the fixit functionality. Fix things. Chances are good that you'll be able to build a new kernel with the kernel that you booted... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Recovery? recent "make world" rendered system unusable (64 bit change)
I've been running 5.1-CURRENT for a while and a couple nights ago did a "make world". After a couple hours building, my system was unusable. Critical binaries like "rm", "ls", "mtree", "sh" failed, reporting "Exec format error". I can't login, not even single user. I can no longer even boot single user. I've hosed my system and am looking for a way to recover without having to reinstall everything and overwrite critical data and system config files. Naturally, I only discovered the note in UPDATING after I trashed my system -- in fact, I read it from the "OK" boot prompt with its "more". Doh! 20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a `installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. [...] Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. [...] DO NOT make installworld after the buildworld w/o building and installing a new kernel FIRST. You will be unable to build a new kernel otherwise on a system with new binaries and an old kernel. I'm looking for recommendations on how to recover, hopefully without trashing my critical system files like /etc/passwd. Ideally, I guess I'd like a way to replace all the broken binaries and any related libraries without overwriting other files. If I do a floppy-based install and then select Custom/Expert than request a minimal install, I presume it will install a small set of binaries but also overwrite /etc/passwd, /etc/ssh/* and so on. Is there a way to have it just update binaries and libraries? If I have to, I could add another disk to this box. Then I could do a floppy install of 5.x on to that new disk. Then I could boot it, and mount the old disk's partitions. Then install the new install's binaries on the old partitions. Or perhaps I could do a make buildworld, kernel, installworld the proper way, using the old disk's partitions as the target. Or could I -- somehow -- push a 64-bit-aware kernel onto this box so that the newly "broken" binaries will work again? How? Again, I've got no shell access any more so everything's gonna have to be done from floppy or maybe CD if I can borrow a burner. Naturally, this is my net boot server for my diskless clients so I can't go that route either. :-( Any other suggestions? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make world failure
What do you have your CFLAGS/CPUTYPE set to? I've run into this before with aggressive CFLAGS/CPUTYPE i believe (-O3 with athlon-mp) seth > Hi, > > I end up with the following when I run `make world` on 5.1-RELEASE-p10. > > > /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such > file or directory > In file included from > /usr/src/contrib/libstdc++/libsupc++/eh_globals.cc:33: > /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such > file or directory > In file included from > /usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:34: > /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such > file or directory > /usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:38:23: unwind-pe.h: > No such file or directory > In file included from > /usr/src/contrib/libstdc++/libsupc++/eh_terminate.cc:34: > /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such > file or directory > In file included from /usr/src/contrib/libstdc++/libsupc++/eh_throw.cc:32: > /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such > file or directory > In file included from /usr/src/contrib/libstdc++/libsupc++/eh_type.cc:32: > /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such > file or directory > In file included from /usr/src/contrib/libstdc++/libsupc++/pure.cc:31: > /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such > file or directory > In file included from /usr/src/contrib/libstdc++/libsupc++/vec.cc:37: > /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such > file or directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/src/gnu/lib/libstdc++. > *** Error code 1 > > Stop in /usr/src/gnu/lib. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > beastie# date > Mon Nov 17 19:20:06 EAT 2003 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make world failure
Hi, I end up with the following when I run `make world` on 5.1-RELEASE-p10. /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_globals.cc:33: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:34: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory /usr/src/contrib/libstdc++/libsupc++/eh_personality.cc:38:23: unwind-pe.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_terminate.cc:34: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_throw.cc:32: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/eh_type.cc:32: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/pure.cc:31: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/contrib/libstdc++/libsupc++/vec.cc:37: /usr/src/contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 Stop in /usr/src/gnu/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. beastie# date Mon Nov 17 19:20:06 EAT 2003 beastie# uname -a FreeBSD beastie.wananchi.com 5.1-RELEASE-p10 FreeBSD 5.1-RELEASE-p10 # -Wash -- |\ _,,,---,,_ | Odhiambo Washington<[EMAIL PROTECTED]> Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 + California is a fine place to live -- if you happen to be an orange. -- Fred Allen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make world failure with today's current. (in /usr/src/sys/boot/i386/boot2/boot2.c)
Hi Guys, Source as of 4 hours ago I get the following in make world ... Cheers, Mark Full log of error follows : objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=276 count=1 2>/dev/null nm -t d boot1.out | awk '/([0-9])+ T xread/ { x = $1 - ORG1; printf("#define X READORG %#x\n", REL1 + x) }' ORG1=`printf "%d" 0x7c00` REL1=`printf "%d" 0x700 ` > boot2.h cc -elf -ffreestanding -Os -fno-builtin -fno-guess-branch-probability -fomit-fr ame-pointer -mno-align-long-strings -mrtd -DUFS1_AND_UFS2 -I/usr/src/sys/boot /i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall - Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmis sing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes - Wwrite-strings -ffreestanding -mpreferred-stack-boundary=2 -S -o boot2.s.tmp /u sr/src/sys/boot/i386/boot2/boot2.c /usr/src/sys/boot/i386/boot2/boot2.c: In function `load': /usr/src/sys/boot/i386/boot2/boot2.c:362: error: `RB_BOOTINFO' undeclared (first use in this function) /usr/src/sys/boot/i386/boot2/boot2.c:362: error: (Each undeclared identifier is reported only once /usr/src/sys/boot/i386/boot2/boot2.c:362: error: for each function it appears in .) *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 Stop in /usr/src/sys/boot/i386. *** Error code 1 Stop in /usr/src/sys/boot. *** Error code 1 Stop in /usr/src/sys. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make world
On Mon, 10 Nov 2003, Aleksandar Simonovski wrote: > after making make buildworld,installworld mergemaster and everything > that i suposed to do ( reading UPDATING) i get this error: > > init: can't exec getty `/usr/libexec/getty` for /dev/ttyv1: No souch file or > directory > init: can't exec getty `/usr/libexec/getty` for /dev/ttyv2: No souch file or > directory Hm, no devfs mounted? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
make world
after making make buildworld,installworld mergemaster and everything that i suposed to do ( reading UPDATING) i get this error: init: can't exec getty `/usr/libexec/getty` for /dev/ttyv1: No souch file or directory init: can't exec getty `/usr/libexec/getty` for /dev/ttyv2: No souch file or directory ...and so on any help thanx Aleksandar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bge phy read timeout possibly solved / now make world broken (Re: bge0 driver "PHY read timeout" and pccardd not finding PCMCIA card, DELL Latitude D600, with current of yesterday)
Luckily I had some old -current SNAP CDs. 1. Tried a snap from Aug 31: No problems with bge0 interface with -curremnt 2. Updated sources to -current of today. Compiled and installed only new actual kernel. No problems with bge0 interface. Currently am trying to do make world but it fails in stage 4.2 - building libraries: lib/libypclnt/ypclnt_connect.c Best regards Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi - too hot, make world dies with various signals
Hi, Agree fully. I have the same problem on my ThinkPad T21 - as reported on this list earlier. Running without ACPI is no problem. Another problem when running with ACPI is that suspend mode doesn't turn the display off. Pretty annoying, and besides it will never come back from suspend either :) So for now I'm running without acpi all the time. Better that way. //Eirik On Sun, 3 Aug 2003 18:59:52 +1000 (EST) Tony Maher <[EMAIL PROTECTED]> wrote: > Hello > > I attempted to do make buildworld on my N610c laptop but it kept dying > with various signals > *** Signal 4 > *** Signal 11 > > The fan does go off and on in response to high CPU activity but I am > guessing not enough and not soon enough. I rebooted with acpi > disabled so that fan runs continuously (when there is AC power). > Buildworld is now almost complete. > > It would be nice if acpiconf had option to switch cooling on > (permanently) and off (well until acpi decided it was too hot). > (Hmm maybe if I had of used 'acpiconf -d' I wouldn't have had to > reboot and I could just disable thermal portion of acpi at boot. Wil > that leave fan on when no ac power??? hmm.) > > Even better if acpi switched cooling on sooner. I'll try to look at > it myself but that wont be till next weekend. But if anyone has > patches or wants me to get debug info I'd be happy to try. > > thanks > -- > tonym > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" pgp0.pgp Description: PGP signature
acpi - too hot, make world dies with various signals
Hello I attempted to do make buildworld on my N610c laptop but it kept dying with various signals *** Signal 4 *** Signal 11 The fan does go off and on in response to high CPU activity but I am guessing not enough and not soon enough. I rebooted with acpi disabled so that fan runs continuously (when there is AC power). Buildworld is now almost complete. It would be nice if acpiconf had option to switch cooling on (permanently) and off (well until acpi decided it was too hot). (Hmm maybe if I had of used 'acpiconf -d' I wouldn't have had to reboot and I could just disable thermal portion of acpi at boot. Wil that leave fan on when no ac power??? hmm.) Even better if acpi switched cooling on sooner. I'll try to look at it myself but that wont be till next weekend. But if anyone has patches or wants me to get debug info I'd be happy to try. thanks -- tonym ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make world failure: tar/cleaning object tree
On Mon, 16 Jun 2003, Kris Kennaway wrote: > On Mon, Jun 16, 2003 at 10:21:51AM +0200, Matthias Andree wrote: > > "make world" fails, "rm -rf /usr/obj ; make -DNOCLEAN world" is fine. > > Always update with 'cvs update -PdA' I used cvsup without -s. -- Matthias Andree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make world failure: tar/cleaning object tree
On Mon, Jun 16, 2003 at 10:21:51AM +0200, Matthias Andree wrote: > Hi, > > "make world" fails, "rm -rf /usr/obj ; make -DNOCLEAN world" is fine. Always update with 'cvs update -PdA' Kris pgp0.pgp Description: PGP signature
make world failure: tar/cleaning object tree
Hi, "make world" fails, "rm -rf /usr/obj ; make -DNOCLEAN world" is fine. make world failure happens in -- >>> stage 2: cleaning up the object tree -- ... ===> gnu/usr.bin/tar rm -f tar addext.o argmatch.o backupfile.o basename.o dirname.o error.o exclude. o full-write.o getdate.o getline.o getopt.o getopt1.o getstr.o hash.o human.o mk time.o modechange.o prepargs.o print-copyr.o quotearg.o safe-read.o save-cwd.o s avedir.o unicodeio.o xgetcwd.o xmalloc.o xstrdup.o xstrtoul.o xstrtoumax.o buffe r.o compare.o create.o delete.o extract.o incremen.o list.o mangle.o misc.o name s.o rtapelib.o tar.o update.o tar.1.gz tar.1.cat.gz rm: tar: is a directory *** Error code 1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
i386-P4 make world from 06.01.2003 source failed: (csu/i386-elf)ISO CB89 long long error
System: i386 P4 5.1-BETA2 (cvsup 06.01.2003.2114CDT) cd /usr/src cvsup standard-supfile make world . . . cc -O -pipe -mcpu=pentiumpro -elf -Wall -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -pedantic -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o cc1: warnings being treated as errors In file included from /usr/src/lib/csu/i386-elf/crt1.c:33: /usr/obj/usr/src/i386/usr/include/stdlib.h:134: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:135: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:140: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:148: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:151: warning: ISO C89 does not support `long long' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make world fails in libexec/pt_chown
>Date: Mon, 24 Feb 2003 15:43:34 +0100 >From: Christoph Kukulies <[EMAIL PROTECTED]> >Freshly supped and got: >===> libexec/pt_chown >cc -O -pipe -mcpu=pentiumpro -Wformat=2 -Wno-format-extra-args -Werror -c >/usr/src/libexec/pt_chown/pt_chown.c >cc1: warnings being treated as errors >/usr/src/libexec/pt_chown/pt_chown.c: In function `main': >/usr/src/libexec/pt_chown/pt_chown.c:86: warning: assignment makes pointer from >integer without a cast >*** Error code 1 >Stop in /usr/src/libexec/pt_chown. >... >Should I cvsup again? Not sure about that, but I got through the "make buildworld" OK, and am building a -CURRENT kernel from today's sources. Recent CVSup history here: freebeast(5.0-C)[1] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Thu Feb 20 04:18:51 PST 2003 CVSup ended from cvsup14.freebsd.org at Thu Feb 20 04:29:15 PST 2003 CVSup begin from cvsup14.freebsd.org at Fri Feb 21 03:47:02 PST 2003 CVSup ended from cvsup14.freebsd.org at Fri Feb 21 03:58:48 PST 2003 CVSup begin from cvsup14.freebsd.org at Sat Feb 22 03:47:03 PST 2003 CVSup ended from cvsup14.freebsd.org at Sat Feb 22 03:58:53 PST 2003 CVSup begin from cvsup14.freebsd.org at Sun Feb 23 03:47:02 PST 2003 CVSup ended from cvsup14.freebsd.org at Sun Feb 23 03:55:36 PST 2003 CVSup begin from cvsup14.freebsd.org at Mon Feb 24 03:47:02 PST 2003 CVSup ended from cvsup14.freebsd.org at Mon Feb 24 03:56:04 PST 2003 (Yesterday's build was uneventful, FWIW. Oh -- committers: please note that this is *not* a complaint. :-}) Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] WARNING: Use of Microsoft products may be hazardous to your system's integrity. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world fails in libexec/pt_chown
Freshly supped and got: ===> libexec/pt_chown cc -O -pipe -mcpu=pentiumpro -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/pt_chown/pt_chown.c cc1: warnings being treated as errors /usr/src/libexec/pt_chown/pt_chown.c: In function `main': /usr/src/libexec/pt_chown/pt_chown.c:86: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /usr/src/libexec/pt_chown. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Should I cvsup again? -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lib/libdisk compile failure during 'make world'
Greetings, Running -CURRENT, I cvsupped today... and afterwards ran 'world' which bailed out here: cc1: warnings being treated as errors /usr/src/lib/libdisk/rules.c: In function `Check_Chunk': /usr/src/lib/libdisk/rules.c:265: warning: enumeration value `p_any' not handled in switch /usr/src/lib/libdisk/rules.c:265: warning: enumeration value `p_alpha' not handled in switch /usr/src/lib/libdisk/rules.c:265: warning: enumeration value `p_sparc64' not handled in switch /usr/src/lib/libdisk/rules.c:265: warning: enumeration value `p_ia64' not handled in switch /usr/src/lib/libdisk/rules.c:265: warning: enumeration value `p_ppc' not handled in switch Please cc: me on replies, I am not subscribed. Cheers, Dylan Carlson [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Make world as benchmark?
I have two identical installations of -CURRENT on one machine. The only difference is that one is on a UDMA100 disk and the other is on a UDMA66 disk. Both have softupdates enabled. The total times for a make world && make kernel: UDMA100: 88 minutes UDMA66 : 95 minutes Does this seem an appropriate difference? Anyone else tried the same thing? Next I'll disable softupdates and repeat the test. Any predictions on how much difference I'll see? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** DON'T MAKE WORLD !!!
On Fri, Oct 11, 2002 at 07:37:53AM -0700, David Wolfskill wrote: > On Fri, Oct 11, 2002 at 02:42:34AM -0700, David O'Brien wrote: > > On Fri, Oct 11, 2002 at 01:04:23AM -0700, David O'Brien wrote: > > > I've ended up hosing world with the Binutils upgrade. > > > > I think world is OK now. > > Looks as if something is (still?) broken: Worked around. Very sorry for the breakage.. it was almost 4am and I thought I had gotten the world building fine. Several things conspired against the import this time... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** DON'T MAKE WORLD !!!
hmm. I just up'd three -CURRENT machines from 22 Sept to 10 Oct. buildworld; cd sys/i386/conf config , etc; reboot; installworld. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** DON'T MAKE WORLD !!!
On Fri, Oct 11, 2002 at 02:42:34AM -0700, David O'Brien wrote: > On Fri, Oct 11, 2002 at 01:04:23AM -0700, David O'Brien wrote: > > I've ended up hosing world with the Binutils upgrade. > > I think world is OK now. Looks as if something is (still?) broken: >>> stage 4: building everything.. ... ===> gnu/usr.bin/binutils/gdb ... cc -O -pipe -mcpu=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/src/gnu/usr.bin/binutils/gdb/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/include -Dprint_insn_i386=print_insn_i386_att -DDEFAULT_BFD_VEC=bfd_elf32_i386_vec -DGDB_XM_FILE -Dprint_insn_i386=print_insn_i386_att -DDEFAULT_BFD_VEC=bfd_elf32_i386_vec -DGDB_XM_FILE -DDEFAULT_BFD_ARCH=bfd_i386_arch -I/usr/src/gnu/usr.bin/binutils/gdb/i386 -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/binutils -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/binutils/bfd -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/config -I/usr/src/gnu/usr.bin/binutils/gdb -I/usr/obj/usr/src/i386/usr/include/readline -static -o gdb init.o annotate.o ax-general.o ax-gdb.o bcache.o blockframe.o breakpoint.o buildsym.o c-exp.o c-lang.o c-typeprint.o c-valprint.o ch-exp.o ch-lang.o ch-typeprint.o ch-valprint.o coffread.o complaints.o copying.o corefile.o corelow.o cp-valprint.o dcache.o dbxread.o demangle.o dwarfread.o dwarf2read.o elfread.o environ.o eval.o exec.o expprint.o f-exp.o f-lang.of-typeprint.o f-valprint.o findvar.o fork-child.o gdbarch.o gdbtypes.o infcmd.o inflow.o infptrace.o infrun.o inftarg.o language.o jv-exp.o jv-lang.o jv-valprint.o jv-typeprint.o nlmread.o m2-lang.o m2-exp.o m2-typeprint.o m2-valprint.o main.o maint.o mdebugread.o mem-break.o minsyms.o objfiles.o parse.o printcmd.o remote.o remote-utils.o scm-exp.o scm-lang.o scm-valprint.o solib.o source.o stabsread.o stack.o symfile.o symmisc.o symtab.o target.o thread.o top.o tracepoint.o typeprint.o utils.o valarith.o valops.o valprint.o values.o serial.o ser-unix.o ser-tcp.o arch-utils.o cp-abi.o completer.o doublest.o event-loop.o event-top.o frame.o gdb-events.o inf-loop.o linespec.o memattr.o regcache.o signals.o solib-svr4.o solib-legacy.o ui-file.o ui-out.o wrapper.o cli-out.o cli-cmds.o cli-decode.o cli-script.o cli-setshow.o cli-utils.o freebsd-uthread.o kvm-fbsd.o i386fbsd-nat.o i386bsd-tdep.o i386bsd-nat.o i386-nat.o i386-tdep.o i387-nat.o i387-tdep.o core-regset.o core-aout.o gdbversion.o -lkvm -lm ../libbfd/libbfd.a ../libopcodes/libopcodes.a -lgnuregex ../libiberty/libiberty.a -lreadline -ltermcap arch-utils.o(.data+0x40): undefined reference to `bfd_elf32_i386_vec' *** Error code 1 1 error What next? Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** DON'T MAKE WORLD !!!
On Fri, Oct 11, 2002 at 01:04:23AM -0700, David O'Brien wrote: > I've ended up hosing world with the Binutils upgrade. I think world is OK now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** DON'T MAKE WORLD !!!
Thanks for the warning! M > I've ended up hosing world with the Binutils upgrade. > > It is best you don't try to install a world right now. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP ** DON'T MAKE WORLD !!!
I've ended up hosing world with the Binutils upgrade. It is best you don't try to install a world right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On 5 Jul, Sheldon Hearn wrote: > If you want to clean out crap left behind by `make world', just do this: > > make world > rm -r /usr/include # Make world really should overwrite > make installincludes # header files! > find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/share \ > -type f -mtime +1 -delete Just a side note for those who want to try this: - you need to mkdir /usr/include after the rm - you delete init.bak this way Bye, Alexander. -- I believe the technical term is "Oops!" http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
At 12:42 PM +0100 7/6/02, Paul Richards wrote: >On Sat, 2002-07-06 at 03:46, Garance A Drosihn wrote: >> At 3:05 AM +0100 7/6/02, Paul Richards wrote: >> >Let's start with a premise: No-one running current is using >> >it for anything other than developing FreeBSD. >> >> This is assumption is too limiting. > >It shouldn't be. You're trying to defend a position that >the project doesn't support. It is too limiting. I might be on current because I have my *own* work I am doing on current. You talk as if the only development on -current is things that "other developers have officially committed" to -current. The fact that I have not committed some work to -current does not give anyone the right to go hog-wild with an 'rm' hanging off a blind 'find' command. It still boils down that you do not know why the files are there. I don't see why you're so determined to cause even more hassle for people trying to "do the right thing" and develop their changes on -current. >The -current branch is for FreeBSD developers, or volunteers >brave enough to test the -current branch. > >As such, don't be surprised if it wipes your hard disk clean. Don't be surprised if you have even fewer -current testers. Don't be surprised if we get to Novemeber of this year, and -current is just as unstable and untested as it was last year. Don't be surprised if we never manage to release -current, because it will never be sufficiently tested. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
In message: <[EMAIL PROTECTED]> Paul Richards <[EMAIL PROTECTED]> writes: : A 'sysclean' target would be the same in my mind. If you're "within : spec" of what -current supports then running that target shouldn't hose : you. If you're outside spec then you need to take your own precautions. NetBSD has in its distribution sets things that look like: obsolete.mi obsolete.${ARCH} and its distribution tools remove the old cruft on installation of the newer distribution set. Something like the following would then put things right: sysclean: @ head -2 ${SRCDIR}/release/obsolete.mi | xargs rm @ head -2 ${SRCDIR}/release/obsolete.${MACHINE_ARCH} | xargs rm would be the FreeBSD way of saying something similar. However, the obsolete.mi file would get large with time :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
Sheldon Hearn wrote: > On (2002/07/05 17:24), Sheldon Hearn wrote: > > You and Paul are both pretty "out there" if you think -current users > > will graciously accept a new world order in which ports linked > > dymanically against system libraries won't work between a system upgrade > > and the next port reinstall. > > Sorry about the "heat" of my post. I was stressed out and shouldn't > even have been reading my FreeBSD mail to start with. > > I liked Mark Murray's response to Paul's suggestion much better than my > own. Heat is a measure of how strongly opinions are held. If no one had any strong opinions on something like *this*, then the project would be in *real* trouble. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On Sat, Jul 06, 2002 at 12:42:53PM +0100, Paul Richards wrote: > On Sat, 2002-07-06 at 03:46, Garance A Drosihn wrote: > > At 3:05 AM +0100 7/6/02, Paul Richards wrote: > > >Let's start with a premise: No-one running current is using > > >it for anything other than developing FreeBSD. > > > > This is assumption is too limiting. > > It shouldn't be. You're trying to defend a position that the project > doesn't support. The -current branch is for FreeBSD developers, or > volunteers brave enough to test the -current branch. > > As such, don't be surprised if it wipes your hard disk clean. There's a significant difference between not supporting something and activly breaking it. In any case, I don't agree with that view because I've found that the best way to keep up with -current is to run it as a production desktop. It's worked quite well for several years with only a few minor bumps. Please don't break this. > I think having it as a make target is a good thing, since it would allow > us to easily document that people who truly want to test current should > run that target after a build to ensure they're not running old stuff. > It keeps the code tied into the build process too. A separate optional > script wouldn't be as well integrated into our build setup. A make target is a lousy place because it is too hard to figure out what it does until it's happened. If you're going to just nuke things at random, you might as well reinstall the box every time. It would be cleaner if that's your goal and it wouldn't hurt the rest of us. If you really want a build target, a target that runs something based on an mtree.obsolete file would be reasionable since there would be exactly one place to look. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg40547/pgp0.pgp Description: PGP signature
Re: Removing perl in make world
On (2002/07/05 17:24), Sheldon Hearn wrote: > You and Paul are both pretty "out there" if you think -current users > will graciously accept a new world order in which ports linked > dymanically against system libraries won't work between a system upgrade > and the next port reinstall. Sorry about the "heat" of my post. I was stressed out and shouldn't even have been reading my FreeBSD mail to start with. I liked Mark Murray's response to Paul's suggestion much better than my own. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On Sat, 2002-07-06 at 13:29, Ruslan Ermilov wrote: > On Fri, Jul 05, 2002 at 10:45:41AM +0100, Paul Richards wrote: > > I think we should add a target to make world that checks for the > > existence of an old base install of Perl and removes it if it exists. > > > > As a general principle, if we do things like remove code during -current > > development then make world needs to cater for that change. The idea of > > make world is that what you get at the end of it is a pristine install > > of a snapshot of FreeBSD from the current branch. > > > > The bootstrap target was originally added for this purpose, to deal with > > issues during releases i.e. to bootstrap from one version of current to > > another. It's got misunderstood along the way to mean bootstrapping > > tools needed early in the build process. > > > > I'd like to resurrect it's original meaning and add code to clean out > > old versions of Perl. > > > I strongly object to this unless we clearly define the procedure of > deleting the old stuff like libraries, headers, programs, etc. > I routinely do the cleanup by installing the world into a separate > DESTDIR, and comparing it with what is available under /. I don't > see a major problem with this except maybe a space. Another approarch > is to compare the modification times with the current date; this > works almost ok for all things except headers and (now) static > libraries plus some miscellaneous stuff that is getting installed > with -C. You need to catch up with the rest of this thread, since I think we're moving towards something more acceptable. However, in the particular case of Perl, I think it does highlight a slightly separate issue in that our build process has no concept of deprecating parts of the OS. The 'sysclean' target will "accidentally" deal with the Perl issue, but I don't think it's wrong to have a target remove a module that has been removed from source since that's what installing the system should really do if the system has opted to deprecate something. -- Paul Richards | FreeBSD Services Ltd| Order 4.6 on DVD now. http://www.freebsd-services.com | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On Fri, Jul 05, 2002 at 10:45:41AM +0100, Paul Richards wrote: > I think we should add a target to make world that checks for the > existence of an old base install of Perl and removes it if it exists. > > As a general principle, if we do things like remove code during -current > development then make world needs to cater for that change. The idea of > make world is that what you get at the end of it is a pristine install > of a snapshot of FreeBSD from the current branch. > > The bootstrap target was originally added for this purpose, to deal with > issues during releases i.e. to bootstrap from one version of current to > another. It's got misunderstood along the way to mean bootstrapping > tools needed early in the build process. > > I'd like to resurrect it's original meaning and add code to clean out > old versions of Perl. > I strongly object to this unless we clearly define the procedure of deleting the old stuff like libraries, headers, programs, etc. I routinely do the cleanup by installing the world into a separate DESTDIR, and comparing it with what is available under /. I don't see a major problem with this except maybe a space. Another approarch is to compare the modification times with the current date; this works almost ok for all things except headers and (now) static libraries plus some miscellaneous stuff that is getting installed with -C. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg40541/pgp0.pgp Description: PGP signature
Re: Removing perl in make world
Paul Richards wrote: > On Sat, 2002-07-06 at 03:46, Garance A Drosihn wrote: > > At 3:05 AM +0100 7/6/02, Paul Richards wrote: > > >Let's start with a premise: No-one running current is using > > >it for anything other than developing FreeBSD. > > > > This is assumption is too limiting. > > It shouldn't be. You're trying to defend a position that the project > doesn't support. The -current branch is for FreeBSD developers, or > volunteers brave enough to test the -current branch. > > As such, don't be surprised if it wipes your hard disk clean. It's really "less testing of what will eventually be released and more testers, vs. more testing of what will be eventually released and less testers". It's a saddle curve. Please see the patches I just posted; I think they will permit everyone to "be happy" by letting you add knobs that do what you want to do, set defaults, and then permit people to opt out of those defaults, without having to worry that your default settings will sneak up on them and (e.g.) delete perl out from under them. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On Sat, 2002-07-06 at 03:46, Garance A Drosihn wrote: > At 3:05 AM +0100 7/6/02, Paul Richards wrote: > >Let's start with a premise: No-one running current is using > >it for anything other than developing FreeBSD. > > This is assumption is too limiting. It shouldn't be. You're trying to defend a position that the project doesn't support. The -current branch is for FreeBSD developers, or volunteers brave enough to test the -current branch. As such, don't be surprised if it wipes your hard disk clean. > People running -current are doing it to test the latest builds. > What they *do* to test it is their business. Ie, if I want to > install some port in /usr instead of /usr/local, that is something > I should be able to do. You're free to do that, but you're not really testing -current then, since you're doing things outside the scope of what -current is designed to support. If you're doing stuff to stress it in some way that's particular to you're testing regime then fine, but that's something you'd need to be aware of and it's not that different to installing a personal, more up to date version of gcc in the base, if you do that you need to be aware that the standard current build system will overwrite your changes. A 'sysclean' target would be the same in my mind. If you're "within spec" of what -current supports then running that target shouldn't hose you. If you're outside spec then you need to take your own precautions. I'm not suggesting that 'sysclean' be a default part of installworld anymore. I suggested that removing perl should be, but the debate has moved on from that position and I think the sensible thing now would be to create a 'sysclean' target, that could be run as desired that was more comprehensive than just removing perl or other deprecated apps. A more aggressive cleaning target I think solves more problems more effectively and if it's an optional target I can't see any problems. Probably a make.conf knob, like the update target uses, so people can have it on or off as part of the standard build as they desire. I think having it as a make target is a good thing, since it would allow us to easily document that people who truly want to test current should run that target after a build to ensure they're not running old stuff. It keeps the code tied into the build process too. A separate optional script wouldn't be as well integrated into our build setup. -- Paul Richards | FreeBSD Services Ltd| Order 4.6 on DVD now. http://www.freebsd-services.com | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
Here are two files that make stateful configuration of world building somewhat easier. I expect that the way this will be used is to allow Paul, et. al. the option of setting a default, and having the system ask users if they want to live with Paul's default, or if they want to select their own default instead. This is a proof of concept; it works on my machine, but obviously it could be hacked until the end of time, and not everyone would be satisfied. Basically, you dump these two files int /usr/src, and then add # # System configuration # .include Before "TGTS=" at the top of /usr/src/Makefile. It will force you to select options (offerring defaults) for two example knobs. It then writes the results to a file called /etc/world.mk, which is then sucked back in by the Makefile.world, after it adds a .BEGIN target that causes the file to be rebuilt if it's missing any options. Basically, this means that you can incrementally add knobs, and anyone who builds, instead of getting surprised by the new knobs, ends up getting asked to select the new knob. If you are afraid of running from a cron script, you can: yes x | make world or make world < /dev/null And it will select the defaults, or: yes n | make world And it will turn all new knobs off automatically. You can edit the file by hand if you need/want to; knobs the script doesn't know about will go away, as will anything other than the default comments, but the ability is there for knobs it knows about. The script as written has two default knobs, "PRISTINE" and "BOB"; these are terrible names, but the are only intended as examples (I expect that the actuall names will be things like "KNOB_DELETE_INCLUDES" and "KNOB_DELETE_PERL", etc.). Basically, it ends up being three data lines in a shell script, per new knob. Note that I haven't tried a "make release" with this yet; I expect you will want to copy in the /etc/world.mk from the local system to do the build, or add the /dev/null redirect to the sub-shell in the jail for the build. -- Terry # Support mandatory option recording # # Original: 06 Jul 2002, Terry Lambert # WORLD_CONFIG= /etc/world.mk .BEGIN: @sh ${.CURDIR}/worldconfig.sh ${WORLD_CONFIG} .if exists(${WORLD_CONFIG}) .include "${WORLD_CONFIG}" .endif worldconfig.sh Description: Bourne shell script
Re: Removing perl in make world
On 6 Jul, Paul Richards wrote: > Let's start with a premise: No-one running current is using it for > anything other than developing FreeBSD. > > Given that premise, then there shouldn't be anything in /usr outside of > /usr/local, that wasn't put there by make world. Likewise the same > should be true of /sbin and /bin. The X11 ports install stuff under /usr/X11R6 ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
NetBSD has a mtree.obsolete. Seems like that might not be a bad way to solve this generically. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
At 3:05 AM +0100 7/6/02, Paul Richards wrote: >Let's start with a premise: No-one running current is using >it for anything other than developing FreeBSD. This is assumption is too limiting. People running -current are doing it to test the latest builds. What they *do* to test it is their business. Ie, if I want to install some port in /usr instead of /usr/local, that is something I should be able to do. >Given that premise, then there shouldn't be anything in /usr >outside of usr/local, that wasn't put there by make world. >Likewise the same should be true of /sbin and /bin. > >Therefore running, > >find $listofdirs -newermt $date -delete > >should be perfectly OK since it's only going to clear out old >files that are no longer part of FreeBSD Wrong. It will delete files which were not installed by the FreeBSD install process, but that is *not* necessarily the same thing as "old files". The fact that installworld did not install the file does not mean that *I* do not want that file to be right where it is. How you test your -current system is your own business. There should be no command as part of 'installworld' which assumes how I am going to test my system, or what things I am testing on my system. No blind 'find' command should be automatically deleting any files on my system. The perplexing part of this debate is that I do see what problem you are trying to solve, and I *do* think it would be valuable to address that issue. I do not see what is so perplexing about having a separate script, just like mergemaster, which a person could run WHEN THEY WANT TO, and which would *LIST* what files are in their system that would not be in a "pristine install of -current". It could even go thru, just like mergemaster, and ask "What do you want to do about this file? (Remove, LeaveIt)". People reporting a problem could even be told to run this script, so any other person who is debugging that problem can realize exactly what is different about the first person's system. I can see that someone might say "Ah, you have some old perl installed, and therefore I will ignore your bug report for now". What would be the PROBLEM with THAT solution? Please answer that question, instead of just reinterating how you would like to add find command which will blindly delete files from the system of every developer who is on current. If 'installworld' starts erasing files on me, then I am going to have to reserve a larger block of time to cvsup/buildworld. I will react to that by building world less often, and that isn't going to help any wish for "valuable debugging". As it is, I have spent more than 60 hours in the last month just trying to do a buildworld of current, only to be foiled by one problem or another. (nothing dramatic, it's mainly been a matter of picking the wrong times to cvsup...). And here I am on a friday night, doing a new buildworld while running a -current system from April 23rd, because all of those attempts have failed. 60 hours of my free time in the past month with not a damn thing to show for it, and you're going to make installworlds on -current even more of a hassle. Pardon me if I don't signup for it. I will simply drop back to using stable and I won't bother to help out one bit with testing -current. If you think that -current needs FEWER people trying to run it, then feel free to screw up the installworld target. That's just my 2 cents worth. I see the problem you're trying to address, and if most developers of -current see this as a major problem, then maybe it's better to solve the problem and drive away a few other developers. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On Sat, 2002-07-06 at 01:07, Garance A Drosihn wrote: > At 3:33 PM -0700 7/5/02, Terry Lambert wrote: > > > >So, to summarize: > > > > Let me summarize my own position. > > There are a number of files which installworld does install. After > an installworld is done, there may be a number of files on a person's > hard disk which were not put there by the most recent installworld. > > For each of those files, the issue is one of intent. > >1) Is it there because the administrator explicitly wanted it > to be there, for explicit reasons that may be perfectly valid > even while testing the latest snapshot of current? >2) or is it left-over cruft from some previous install, and > which is only getting in the way of proper testing? > > If you keep it that simple, instead of writing 200-line summaries > of what is going on (and the possible motivations of everyone), then > the solution is also simple. The above is just a slight variation > from what happens with /etc config files during a new installworld. > > We should not have anything which automatically blows away those > files. We should have an "unmergemaster" script, which will find > those files, and **ASKS THE DEVELOPER** what they want to do for > each of those files (or maybe for each set of files). No automatic > process is going to be 100% right 100% of the time. I think a -current system is something that should be assumed to be a semi-known environment though. Let's start with a premise: No-one running current is using it for anything other than developing FreeBSD. Given that premise, then there shouldn't be anything in /usr outside of /usr/local, that wasn't put there by make world. Likewise the same should be true of /sbin and /bin. Therefore running, find $listofdirs -newermt $date -delete should be perfectly OK since it's only going to clear out old files that are no longer part of FreeBSD (where $listofdirs is directories that should not be touched other than by make world, and $date is the date of the last install). The only tweak that is necessary is in the case of /usr/lib, where files should be moved to a compat dir and not deleted. I do this periodically on my dev box and it does show up issues. I think it's something we should build into our infrastructure as a step towards a better known environment for testing -current. -- Paul Richards | FreeBSD Services Ltd| Order 4.6 on DVD now. http://www.freebsd-services.com | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
Garance A Drosihn wrote: > At 3:33 PM -0700 7/5/02, Terry Lambert wrote: > >So, to summarize: > > > > Let me summarize my own position. I was summarizing both. It's not really necessary to summarize a position you've already taken... that's "reiterating". 8-) 8-). You want a one sentence summary instead of a "200 line" summary? Both sides want as many developers as possible using -current in order to advance things as quickly as possible, but they disagree on how that can be best accomplished and are too busy proving they are right to listen to each other and find a compromise. I think automatically removing perl -- or anything else that could result in a runtime error, if it were removed -- is a bad idea. It's asking "make installworld" to be better at component management than "sysinstall upgrade". This is impossible, with the present tools for configuration management that FreeBSD has. I don't think there is *any* way you can turn a system that is a result of "make installworld" into the same system it would have been if you had installed a snapshot from a CDROM on a clean hard drive, and done minor system configuration. Removing old system header files is a possibility. Doing that will cause compile-time errors, but not runtime errors. If we are looking for a minimum valid set of things to remove automatically, then header files are a good candidate. Doing it, though, is a scary default, if you can't turn it off. How about leaving perl along, and starting with a proof-of-concept? Garance: Could you agree to let Paul add Makefile code *that is on by default* to zap /usr/include so that it contained only header files from the "make installworld", after that command is run? Paul: Could you agree to add a knob that Garance and anyone else who is interested could set in their /etc/make.conf or somewhere else where it only has to be set once, so they could opt-out of participating in your experiment? Does this sound reasonable? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
At 3:33 PM -0700 7/5/02, Terry Lambert wrote: > >So, to summarize: > Let me summarize my own position. There are a number of files which installworld does install. After an installworld is done, there may be a number of files on a person's hard disk which were not put there by the most recent installworld. For each of those files, the issue is one of intent. 1) Is it there because the administrator explicitly wanted it to be there, for explicit reasons that may be perfectly valid even while testing the latest snapshot of current? 2) or is it left-over cruft from some previous install, and which is only getting in the way of proper testing? If you keep it that simple, instead of writing 200-line summaries of what is going on (and the possible motivations of everyone), then the solution is also simple. The above is just a slight variation from what happens with /etc config files during a new installworld. We should not have anything which automatically blows away those files. We should have an "unmergemaster" script, which will find those files, and **ASKS THE DEVELOPER** what they want to do for each of those files (or maybe for each set of files). No automatic process is going to be 100% right 100% of the time. Developers do not need to have installworld forcing some person's idea of what a "pristine" testing environment should look like. However, it would be very useful to have something which would just *tell* us what the difference is between our environment and this imaginary perfect testing environment, so we can decide what should (and what should not) be changed. While the solution may be conceptually simple, I will admit that I have no intention of working on it myself. I will therefore drop out of the debate in this thread at this time. Not that I'm upset about any of it, it's just that I don't think I have anything more to contribute. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On Fri, Jul 05, 2002 at 03:33:08PM -0700, Terry Lambert wrote: > Others: I think the flaw in your idea is that you aren't > really running -current, so why the heck aren't you just > running -stable, instead of pretending to run -current? Of course by this argument, we wouldn't be running -stable either... I agree there is a need to allow developers to clean up their systems to be as much like a clean install as possiable, but I definatly think installworld is the wrong place to do so. I'm also pretty convinced that a make target is the wrong place entierly. The problem is that if you just go nuking everything that's OBE, you will break development machines and that's unacceptable. I can't just rebuild kde on a whim, it takes 10-20 hours on my laptop (and since I last built it with gcc 2.x, it's presumably much worse now.) What would be useful to me, would be a way to list the files that are OBE so I can make a reasionable decision about removing them. Idealy, such a system would have some handy ldd scripts to tell me if libs are used or not. I think Paul's goal is fairly noble, but the suggest solution is unacceptable in my book. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg40503/pgp0.pgp Description: PGP signature
Re: Removing perl in make world
Garance A Drosihn wrote: > While I agree there should be some automatic way to get rid > of old cruft (or at least to list it), I do not think that it > should be part of installworld or installkernel. All that > any such step can do is find things which "it does not expect" > to be there, but it would have no way of knowing *why* the > file is there. Maybe it's stale, *or* maybe someone build the > port and explicitly pointed it at /usr instead of /usr/local. So, to summarize: o People with old cruft may have working -current systems that should not be working, but they can't see the problems because they have files that would not be there if they had done a fresh install. o People with old cruft may be reporting broken -current experiences (e.g. like some of the libc_r breakage recently), when *their personal system* is what is broken, because they have files that would not be there if they had done a fresh install. o Making "make install" remove "everything which is not -current" is a bad idea, because it could surprise people by moving them from the first category -- "should not be working" -- into the "not working" category. Just to play devil's advocate... Aren't the people who would be "surprised" in this case using -current in a way it is not intended to be used? Specifically, isn't -current there *solely* for testing, and not production work, and therefore shouldn't the *primary* purpose of -current -- testing for breakage in -current -- be the first and foremost result of running -current? -- I think that there are two contradictory assumptions in this dicussion... either you want -current to work because it's good code, or you want -current to "just work", and you don't care if that doesn't mean that you can't build an identical, working system from the code in the source repository. Paul: I think the flaw in your idea is that when the source code goes from a working to a non-working condition, there would be no going back to correct the problem, short of a full reinstall or an emergency recovery disk. Others: I think the flaw in your idea is that you aren't really running -current, so why the heck aren't you just running -stable, instead of pretending to run -current? I think it comes down to this: Everyone is interested in having the most people possible running -current. Paul wants to attract new people, and Sheldon wants to not scare away old people. So back to my original suggestion (to Paul) of compromise: | I guess the best way for you to argue for this outcome is for | you to do the bsd.*.mk modifications to support your idea, and | to do all the Makfile modifications to provide the targets, | and to have it "off by default". E.g. with a "make installpristine" or some other target. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
Sheldon Hearn wrote: > You and Paul are both pretty "out there" if you think -current users > will graciously accept a new world order in which ports linked > dymanically against system libraries won't work between a system upgrade > and the next port reinstall. > > If you want to clean out crap left behind by `make world', just do this: > > make world > rm -r /usr/include # Make world really should overwrite > make installincludes# header files! > find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/share \ > -type f -mtime +1 -delete > > If you're just annoyed by the recent perl wobble, think about how important > it is to do what Paul suggests, if it means annoying users who have very > good reasons to prefer the way the `make world' upgrade method works. > > Then, if you still think it's important, figure out a way to do it > _without_ annoying those users, as suggested by Terry. 1) It was Paul that suggested it. I merely stated that he had a reasonable argument, depending on his goals. 2) Right after you stopped quoting, implying that I was for the idea, I had said: | Note that this is really problematic, since there are optional | install components, such as binary backward compatability | libraries that are installed into system directories, such as | /usr/lib, that aren't technically the result of the build | process itself. | | Header files under /usr/include are pretty straight forward, as | far as that goes, though, unless they overlap components that | get installed for binary compatability (I don't think the tools | actually support building for this, though, because of crt, | manifest constant, and the a,out->ELF change). ... in other words: i. It's reasonable to want this ii. I don't think you can have this So... before you try to tar something with the "Terry likes it, it must be bad" brush, make sure you know which side of the issue I'm on. This time, I'm on your side. I guess that must mean you're wrong. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On Fri, Jul 05, 2002 at 11:29:30AM +0100, Mark Murray wrote: > > I think we should add a target to make world that checks for the > > existence of an old base install of Perl and removes it if it exists. > > I agree that we may need a tool to do this, but I don't agree that it > gets done automatically by "make world". Could we also make this tool mv /usr/include /usr/include.old so that it could be run before an installworld? -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
At 11:16 AM +0100 7/5/02, Paul Richards wrote: >On Fri, 2002-07-05 at 10:52, Sheldon Hearn wrote: > > On (2002/07/05 10:45), Paul Richards wrote: > > > I'd like to resurrect it's original meaning and add code > > > to clean out old versions of Perl. > > > > This would not fit in with the rest of the world target, > > which doesn't clean out stale headers, stale libraries > > or stale binaries. Special-casing certain things will > > surprise people. >I recently cleaned out a load of stale libraries and I was >quite surprised to find that what I thought was a version of >current updated daily was not in fact that at all since a >lot of my binaries were still linked to much older libraries >so I was running a pseudo current, partly up to date and >partly not. While I agree there should be some automatic way to get rid of old cruft (or at least to list it), I do not think that it should be part of installworld or installkernel. All that any such step can do is find things which "it does not expect" to be there, but it would have no way of knowing *why* the file is there. Maybe it's stale, *or* maybe someone build the port and explicitly pointed it at /usr instead of /usr/local. And if the process automatically removes some old library, and you have a lot of programs linked to that library, won't that be a bit disruptive? A plain installworld can be disruptive enough, without it also removing libraries that important programs might be linked to! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On Fri, 2002-07-05 at 16:24, Sheldon Hearn wrote: > On (2002/07/05 05:22), Terry Lambert wrote: > > > > This would not fit in with the rest of the world target, which doesn't > > > clean out stale headers, stale libraries or stale binaries. > > > Special-casing certain things will surprise people. > > > > Headers and libraries arguably should be removed, so as to avoid > > errors; not ports headers or libraries -- which aren't in the > > installation target paths in the first place -- but things like > > deprecated system headers, etc.. > > You and Paul are both pretty "out there" if you think -current users > will graciously accept a new world order in which ports linked > dymanically against system libraries won't work between a system upgrade > and the next port reinstall. I'm reluctant to suggest something that scares away -current developers, since I don't think enough people are really working on -current these days. However, if you are developing FreeBSD then you do need to make sure you're running -current and not -cruft. The old mantra of "-current is for developers" still holds and if the development environment becomes ineffective because people are relying on current as a work environment then maybe we should tighten the development environment so it's more suited to those people who are actually working on FreeBSD itself. On my -current box I usually rebuild ports quite regularly anyway because ports get updated pretty frequently. The only real issue with backwards compatibility is the libraries, there's nothing else that should severely impact existing installations. Libraries can easily be dealt with by just moving them to a compat dir. > If you want to clean out crap left behind by `make world', just do this: > > make world > rm -r /usr/include# Make world really should overwrite > make installincludes # header files! > find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/share \ > -type f -mtime +1 -delete That is precisely what I do periodically (along those lines anyway), and it is often the case that when I do so I find that I've been running -cruft and not -current at all. -- Paul Richards| FreeBSD Services Ltd | Order 4.6 on DVD today! http://www.freebsd-services.com | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On (2002/07/05 05:22), Terry Lambert wrote: > > This would not fit in with the rest of the world target, which doesn't > > clean out stale headers, stale libraries or stale binaries. > > Special-casing certain things will surprise people. > > Headers and libraries arguably should be removed, so as to avoid > errors; not ports headers or libraries -- which aren't in the > installation target paths in the first place -- but things like > deprecated system headers, etc.. You and Paul are both pretty "out there" if you think -current users will graciously accept a new world order in which ports linked dymanically against system libraries won't work between a system upgrade and the next port reinstall. If you want to clean out crap left behind by `make world', just do this: make world rm -r /usr/include # Make world really should overwrite make installincludes# header files! find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/share \ -type f -mtime +1 -delete If you're just annoyed by the recent perl wobble, think about how important it is to do what Paul suggests, if it means annoying users who have very good reasons to prefer the way the `make world' upgrade method works. Then, if you still think it's important, figure out a way to do it _without_ annoying those users, as suggested by Terry. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
> I think we should add a target to make world that checks for the > existence of an old base install of Perl and removes it if it exists. I agree that we may need a tool to do this, but I don't agree that it gets done automatically by "make world". > As a general principle, if we do things like remove code during -current > development then make world needs to cater for that change. The idea of > make world is that what you get at the end of it is a pristine install > of a snapshot of FreeBSD from the current branch. I disagree. This is force-feeding the user base too much. > The bootstrap target was originally added for this purpose, to deal with > issues during releases i.e. to bootstrap from one version of current to > another. It's got misunderstood along the way to mean bootstrapping > tools needed early in the build process. > > I'd like to resurrect it's original meaning and add code to clean out > old versions of Perl. Lots of things get deleted from current as time goes by; headers, libraries, applets, etc. It is the responsibility of the CURRENT builder/user to remove them as she sees fit. Our resposibility as developers goes no further than to help provide removal tools/techniques (I use "find ${DIR} -type f -ctime +1 -delete -print"), and guidance. Of course, there are counterprecedents (libtelnet is one), but these are the exception, and are unlikely to trample all over a user's carefully crafted installation. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world stops...
On Sun, Apr 14, 2002 at 07:22:33PM +0200, Jeroen Ruigrok/asmodai wrote: > -On [20020414 19:14], Matthias Schuendehuette ([EMAIL PROTECTED]) wrote: > >make: don't know how to make neqn. Stop > >*** Error code 2 > > I think David O`Brien fixed this by backing out a commit to make. > > In general, wait a couple of hours or a day before reporting a failure, > since chances are good it has already been fixed. I got hit by this on a machine that had just been updated from 4.5 to -current and then I went to buildworld again and got the above. At the same time a machine that had been -current for a while didn't get this. I'm going to try to remake make as suggested. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world stops...
On Sun, Apr 14, 2002 at 07:22:33PM +0200, Jeroen Ruigrok/asmodai wrote: > -On [20020414 19:14], Matthias Schuendehuette ([EMAIL PROTECTED]) wrote: > >make: don't know how to make neqn. Stop > >*** Error code 2 > > I think David O`Brien fixed this by backing out a commit to make. I don't think he fixed the bootstrapping issue if you've build world between 1.17 and 1.20. `make clean depend && make all install' in /usr/src/usr.bin/make fixed it for me, though. > In general, wait a couple of hours or a day before reporting a failure, > since chances are good it has already been fixed. > > -- > Jeroen Ruigrok van der Werven / asmodai / Kita no Mono > asmodai@[wxs.nl|xmach.org], finger [EMAIL PROTECTED] > http://www.softweyr.com/asmodai/ | http://www.[tendra|xmach].org/ > Like cures like... > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, TDC, IP-section. "Hey, are any of you guys out there actually *using* RFC 2549?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world stops...
-On [20020414 19:14], Matthias Schuendehuette ([EMAIL PROTECTED]) wrote: >make: don't know how to make neqn. Stop >*** Error code 2 I think David O`Brien fixed this by backing out a commit to make. In general, wait a couple of hours or a day before reporting a failure, since chances are good it has already been fixed. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono asmodai@[wxs.nl|xmach.org], finger [EMAIL PROTECTED] http://www.softweyr.com/asmodai/ | http://www.[tendra|xmach].org/ Like cures like... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world stops...
Hi everybody, because noone mentioned it so far... : c++ -O -pipe -march=k6 -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -D__FBSDID=__RCSID -fno-rtti -fno-exceptions -static -o eqn eqn.o main.o lex.o box.o limit.o list.o over.o text.o script.o mark.o other.o delim.o sqrt.o pile.o special.o /raid/obj/usr/src/i386/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/libs/libgroff/libgroff.a make: don't know how to make neqn. Stop *** Error code 2 Stop in /usr/src/gnu/usr.bin/groff/src/preproc. -- Ciao/BSD - Matthias Matthias Schuendehuette <[EMAIL PROTECTED]>, Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I broke make world
I apparently broke the build of libkvm (again) I will fix it shortly. I'm in transit right now. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: error using make world
On Thu, Sep 06, 2001 at 04:05:16PM +0200, Nick Martens wrote: > I just updated my source tree from a fresh install > then i tried to make world and got the following error: > > sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 config > /usr/obj/usr/src/i386/usr/sbin > cd /usr/src/usr.sbin/kbdcontrol; make obj; make depend; make all; make > install > /usr/obj/usr/src/i386/usr/src/usr.sbin/kbdcontrol created for > /usr/src/usr.sbin/kbdcontrol > lex -t /usr/src/usr.sbin/kbdcontrol/lex.l > lex.c > rm -f .depend > mkdep -f .depend -a-I/usr/src/usr.sbin/kbdcontrol > -I/usr/obj/usr/src/i386/usr/include > /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c lex.c > cd /usr/src/usr.sbin/kbdcontrol; make _EXTRADEPEND > echo kbdcontrol: /usr/obj/usr/src/i386/usr/lib/libc.a > /usr/obj/usr/src/i386/usr/lib/libl.a >> .depend > cc -O -pipe -I/usr/src/usr.sbin/kbdcontrol > -I/usr/obj/usr/src/i386/usr/include -c > /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c > *** Error code 1 I can't see the error here. If you're running make -j, don't do that because it hides the real error somewhere further back in the make output. Kris PGP signature
error using make world
Hi I just updated my source tree from a fresh install then i tried to make world and got the following error: sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 config /usr/obj/usr/src/i386/usr/sbin cd /usr/src/usr.sbin/kbdcontrol; make obj; make depend; make all; make install /usr/obj/usr/src/i386/usr/src/usr.sbin/kbdcontrol created for /usr/src/usr.sbin/kbdcontrol lex -t /usr/src/usr.sbin/kbdcontrol/lex.l > lex.c rm -f .depend mkdep -f .depend -a-I/usr/src/usr.sbin/kbdcontrol -I/usr/obj/usr/src/i386/usr/include /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c lex.c cd /usr/src/usr.sbin/kbdcontrol; make _EXTRADEPEND echo kbdcontrol: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libl.a >> .depend cc -O -pipe -I/usr/src/usr.sbin/kbdcontrol -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/kbdcontrol/kbdcontrol.c *** Error code 1 Stop in /usr/src/usr.sbin/kbdcontrol. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I am not sure if I should have posted it here if I shouldn't have, then where should I ?? Is there something i forgot or should have known?? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More SIG4s during make world
:Hi, : :Just a quick note to say that my -current box has started dropping :cores during make world again. : :I have a kernel from August 11 that works ok, and had one from August :18 that was causing sig 4 at random places. I accidently overwrote :my Aug 18 kernel.old, but Aug 25, 27 and 28 are still dropping cores :all over the place. : :My machine config has changed slightly since this happened in May, :It's now a P4/1.7GHz with 384Mb RAM. : :As before, I can give people access to the box if required - although :unfortunately I haven't got enough room in swap for a kernel core any :more (oops!) -- but that can be fixed if required. : :If anybody has any suggestions, I'd be glad to hear them, otherwise :I'll try rolling the sources forward from the 11th to try to discover :when the breakage occurred. : :Cheers. :-- :Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]> : http://www.freebsd-services.com/ I took a look at the diff between those dates and there were a lot of changes. If you have the time it may well be that the best way to home in on the problem is to do a date-based cvs checkout to try to narrow down the date range where the problems started to occur. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world broken in -current
On Monday 27 August 2001 05:58 pm, David O'Brien wrote: > On Mon, Aug 27, 2001 at 11:10:55AM -0700, [EMAIL PROTECTED] wrote: > > Compiling sources cvs'ed this morning (Aug 27th), I get this error: > > > > cd /auto/roy/dist/pub/FreeBSD/CURRENT/src/usr.bin/file; make build-tools > > make: don't know how to make build-tools. Stop > > *** Error code 2 > > Are you sure your src/usr.bin/file/Makefile is up to date? > > # $FreeBSD: src/usr.bin/file/Makefile,v 1.22 2001/08/17 17:21:38 obrien Exp > $ Ding! I have version 1.21. So this leads me to my next question and that is there anything wrong with anoncvs.FreeBSD.org? I am getting these messages when I try to get a new cvs version: cvs [checkout aborted]: reading from server: Connection reset by peer cvs [checkout aborted]: end of file from server (consult above messages if any) But there are no messages above. - JimP -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o [EMAIL PROTECTED] - [EMAIL PROTECTED] _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
More SIG4s during make world
Hi, Just a quick note to say that my -current box has started dropping cores during make world again. I have a kernel from August 11 that works ok, and had one from August 18 that was causing sig 4 at random places. I accidently overwrote my Aug 18 kernel.old, but Aug 25, 27 and 28 are still dropping cores all over the place. My machine config has changed slightly since this happened in May, It's now a P4/1.7GHz with 384Mb RAM. As before, I can give people access to the box if required - although unfortunately I haven't got enough room in swap for a kernel core any more (oops!) -- but that can be fixed if required. If anybody has any suggestions, I'd be glad to hear them, otherwise I'll try rolling the sources forward from the 11th to try to discover when the breakage occurred. Cheers. -- Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]> http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world broken in -current
On Mon, Aug 27, 2001 at 11:10:55AM -0700, [EMAIL PROTECTED] wrote: > Compiling sources cvs'ed this morning (Aug 27th), I get this error: > > cd /auto/roy/dist/pub/FreeBSD/CURRENT/src/usr.bin/file; make build-tools > make: don't know how to make build-tools. Stop > *** Error code 2 Are you sure your src/usr.bin/file/Makefile is up to date? # $FreeBSD: src/usr.bin/file/Makefile,v 1.22 2001/08/17 17:21:38 obrien Exp $ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world broken in -current
Compiling sources cvs'ed this morning (Aug 27th), I get this error: cd /auto/roy/dist/pub/FreeBSD/CURRENT/src/usr.bin/file; make build-tools make: don't know how to make build-tools. Stop *** Error code 2 Stop in /auto/roy/dist/pub/FreeBSD/CURRENT/src. *** Error code 1 - JimP To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world broken by STDIN_ changes
On Thu, 26 Jul 2001 15:26:27 MST, Steve Kargl wrote: > ===> usr.sbin/pcvt/vttest > cc -O -pipe -march=k6 -traditional -DUSEMYSTTY -I/usr/obj/usr/src/i386/usr/include > -c /usr/src/usr.sbin/pcvt/vttest/main.c > /usr/src/usr.sbin/pcvt/vttest/main.c: In function `readnl': > /usr/src/usr.sbin/pcvt/vttest/main.c:1942: `STDIN_FILENO' undeclared (first use in >this function) Yup. I forgot to commit my changes to header.h and Makefile. Sorry for the interruption, folks. I do appreciate how much time mistakes like this end up costing other people. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world broken by STDIN_ changes
===> usr.sbin/pcvt/vttest cc -O -pipe -march=k6 -traditional -DUSEMYSTTY -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/pcvt/vttest/main.c /usr/src/usr.sbin/pcvt/vttest/main.c: In function `readnl': /usr/src/usr.sbin/pcvt/vttest/main.c:1942: `STDIN_FILENO' undeclared (first use in this function) /usr/src/usr.sbin/pcvt/vttest/main.c:1942: (Each undeclared identifier is reported only once /usr/src/usr.sbin/pcvt/vttest/main.c:1942: for each function it appears in.) *** Error code 1 -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world hosed ?
On Wed, 18 Jul 2001, David Malone wrote: > I would have thought that any file included with > > #include <...> > > would count as a system header file, but it seems gcc has some > other criteron for deciding. I've managed to trace it back to cpp > writing out lines like: > > # 1 "/usr/include/tcpd.h" 1 3 > > where the "3" at the end seems to mean a system header file. And > in tradcpp.c it seems to set a varible system_header_p if the > include is a <...> as opposed to a "...", but I haven't found out > where the "3" comes from yet. > > Ahh - I'm looking at the wrong gcc sources. The 2.95.3 sources > (which uses the old gcc cpp) decides if something is a system > include based on examining a list which doesn't seem to get > initialised if you say "-nostdinc". The newer gcc sources (2.96.2711 > with the new cpp) seem to do the <...> vs. "..." thing. I thought that it just looks at the path prefix and knows that /usr/include is special. It seems to used -nostdinc too. I don't see how looking at <...> could be right, since double-quoted includes are not wrong for standard headers. In practice, ``#include "tcpd.h"'' gives the same lack of warnings as ``#include ''. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world hosed ?
> On Tue, Jul 17, 2001 at 07:55:18PM +0100, David Malone wrote: > > I suspect that this is my fault for not doing a buildworld after > > turning on WARNS stuff in inetd. > YES! Why are you committing these "very easy to break the build, as > we've seen" changes w/o full `make buildworld' testing?!? I should have been more careful, but I actually tested the change on the i386 and alpha and checked that it didn't produce any code changes. Unfortunately, gcc has an undocumented feature of ignoring some warnings in system C header files. (Maybe this feature has been there for years, but the fact that gcc gives out about system header files is something that's caused problems for me before.) I would have thought that any file included with #include <...> would count as a system header file, but it seems gcc has some other criteron for deciding. I've managed to trace it back to cpp writing out lines like: # 1 "/usr/include/tcpd.h" 1 3 where the "3" at the end seems to mean a system header file. And in tradcpp.c it seems to set a varible system_header_p if the include is a <...> as opposed to a "...", but I haven't found out where the "3" comes from yet. Ahh - I'm looking at the wrong gcc sources. The 2.95.3 sources (which uses the old gcc cpp) decides if something is a system include based on examining a list which doesn't seem to get initialised if you say "-nostdinc". The newer gcc sources (2.96.2711 with the new cpp) seem to do the <...> vs. "..." thing. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world hosed ?
On Tue, Jul 17, 2001 at 07:55:18PM +0100, David Malone wrote: > I suspect that this is my fault for not doing a buildworld after > turning on WARNS stuff in inetd. YES! Why are you committing these "very easy to break the build, as we've seen" changes w/o full `make buildworld' testing?!? > I'll back out the WARNS stuff and find out what's going on. Yes, please. If you guys doing the WARNS stuff cannot slow down a little and do proper build testing, I personally (and I know at least one will disagree with me here) wish you guys would stop the effort. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world hosed ?
> >I'll back out the WARNS stuff and find out what's going on. > Well, for whatever it's worth, I didn't see the complaints that phk did, > and when I built today's -CURRENT, usr.sbin/inetd/Makefile was at rev. > 1.23. The compiles for inetd look pretty normal; log excerpts (courtesy > of "script") available upon request. My recent CVSup history: Weird - 1.23 definitely has the WARNS stuff on and failed for the buildworld I left running at home this morning. I commented out the WARNS stuff and it worked fine. I can also reproduce the error by adding "-nostdinc -I/usr/include" to my regular C flags. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world hosed ?
>Date: Tue, 17 Jul 2001 19:55:18 +0100 >From: David Malone <[EMAIL PROTECTED]> >On Tue, Jul 17, 2001 at 08:38:13PM +0200, Poul-Henning Kamp wrote: >> Am I the only one who sees this ? >I suspect that this is my fault for not doing a buildworld after >turning on WARNS stuff in inetd. I think the problem must be that >-nostdinc must cause errors to be issued for files which wouldn't >usually be. >I'll back out the WARNS stuff and find out what's going on. Well, for whatever it's worth, I didn't see the complaints that phk did, and when I built today's -CURRENT, usr.sbin/inetd/Makefile was at rev. 1.23. The compiles for inetd look pretty normal; log excerpts (courtesy of "script") available upon request. My recent CVSup history: CVSup begin from cvsup14.freebsd.org at Wed Jul 11 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed Jul 11 03:51:10 PDT 2001 CVSup begin from cvsup14.freebsd.org at Fri Jul 13 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Fri Jul 13 03:52:18 PDT 2001 CVSup begin from cvsup14.freebsd.org at Mon Jul 16 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Mon Jul 16 03:55:01 PDT 2001 CVSup begin from cvsup14.freebsd.org at Tue Jul 17 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Tue Jul 17 03:52:46 PDT 2001 (I had been out of town most of last week, and my connectivity was rather spotty. And today's -CURRENT buildworld terminated via panic a couple of times, but I was in an X environment at the time. Running it in single-user mode, no X, avoided the problem -- unfortunately. The problem may have existed earlier, but for the last several builds of -CURRENT, I had been doing those in single-user mode, because I couldn't use X (xdm) or sudo (libpam -- and my "sudo" executable is shared between -CURRENT & -STABLE), and I didn't recall the root password, and was too lazy to set it to something else (until I got annoyed enough this morning -- after having re-built /usr/ports/x11-XFree86-4 under -CURRENT).) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world hosed ?
On Tue, Jul 17, 2001 at 08:38:13PM +0200, Poul-Henning Kamp wrote: > Am I the only one who sees this ? I suspect that this is my fault for not doing a buildworld after turning on WARNS stuff in inetd. I think the problem must be that -nostdinc must cause errors to be issued for files which wouldn't usually be. I'll back out the WARNS stuff and find out what's going on. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message