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 from kernel; already loaded from
if_wi.ko
Module pccard/
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. ___ freebsd-current@f
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: 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
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
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
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 ohart...@mail.zedat.fu-berlin.de 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
On Mon, 2 Apr 2012 10:06:38 -0400 Alexander Kabaev kab...@gmail.com wrote: On Mon, 02 Apr 2012 14:32:51 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de 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
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
Am 04/02/12 16:06, schrieb Alexander Kabaev: On Mon, 02 Apr 2012 14:32:51 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de 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
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
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
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
Re: Build failure during 9-CURRENT make world
On 26 June 2011 19:55, Dimitry Andric d...@freebsd.org 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: 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
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, 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 21 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
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 21 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
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 21 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]
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: 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]
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, 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]
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: 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]
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)
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)
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)
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)
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)
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]
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]
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 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]
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]
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]
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]
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: 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
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]
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
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. shrug -- Matthias Andree ___ [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]
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
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
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
** 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: ** 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
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 !!!
hmm. I just up'd three -CURRENT machines from 22 Sept to 10 Oct. buildworld; cd sys/i386/conf config blah, 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 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: 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 Makefile.world
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 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
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 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
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 (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, 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
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
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
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
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: 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
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
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
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
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
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
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
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
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
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. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org 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
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
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
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
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
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 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. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org 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
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: 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
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/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org 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
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/brian@[uk.]FreeBSD.org 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
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
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 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 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 tcpd.h''. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Make world hosed ?
Am I the only one who sees this ? === usr.sbin/inetd cc -nostdinc -O -pipe -DINET6 -DIPSEC -DLOGIN_CAP -I/usr/obj/flat/src/i386/usr/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpoin ter-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /flat/src/usr.sbin/inetd/inetd.c gzip -cn /flat/src/usr.sbin/inetd/inetd.8 inetd.8.gz cc -nostdinc -O -pipe -DINET6 -DIPSEC -DLOGIN_CAP -I/usr/obj/flat/src/i386/usr/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpoin ter-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /flat/src/usr.sbin/inetd/builtins.c cc1: warnings being treated as errors In file included from /usr/obj/flat/src/i386/usr/include/rpc/rpc.h:50, from /flat/src/usr.sbin/inetd/inetd.c:125: /usr/obj/flat/src/i386/usr/include/rpc/xdr.h:141: warning: function declaration isn't a prototype In file included from /flat/src/usr.sbin/inetd/inetd.c:139: /usr/obj/flat/src/i386/usr/include/tcpd.h:34: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:35: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:36: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:37: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:75: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:76: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:77: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:78: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:79: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:80: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:81: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:82: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:83: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:126: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:127: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:128: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:129: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:130: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:131: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:137: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:138: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:139: warning: function declaration isn't a prototype /usr/obj/flat/src/i386/usr/include/tcpd.h:187: warning: function declaration isn't a prototype -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 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
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
more make world problems on alpha.
rarpd fails to compile (again the WARNS?=2 problem. - JimP beta2 6# make cc -O -pipe -mcpu=ev4 -DTFTP_DIR=\/tftpboot\ -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /usr/src/usr.sbin/rarpd/rarpd.c cc1: warnings being treated as errors /usr/src/usr.sbin/rarpd/rarpd.c: In function `expand_syslog_m': /usr/src/usr.sbin/rarpd/rarpd.c:1027: warning: field width is not type int (arg 4) *** Error code 1 -- --- @(#) $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
Re: more make world problems on alpha.
Yes, I found fixed that, but I haven't checked it in yet. On Thu, 5 Jul 2001, Jim Pirzyk wrote: rarpd fails to compile (again the WARNS?=2 problem. - JimP beta2 6# make cc -O -pipe -mcpu=ev4 -DTFTP_DIR=\/tftpboot\ -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Werror -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -c /usr/src/usr.sbin/rarpd/rarpd.c cc1: warnings being treated as errors /usr/src/usr.sbin/rarpd/rarpd.c: In function `expand_syslog_m': /usr/src/usr.sbin/rarpd/rarpd.c:1027: warning: field width is not type int (arg 4) *** Error code 1 -- --- @(#) $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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cross-platform make world/release?
Greetings, Short question: is FreeBSD capable of cross-platform make world and release (e.g. build of Alpha world/release on x86 and vice versa)? TIA, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cross-platform make world/release?
On Wed, May 16, 2001 at 08:52:44AM -0700, Eugene M. Kim wrote: Greetings, Short question: is FreeBSD capable of cross-platform make world and release (e.g. build of Alpha world/release on x86 and vice versa)? Hello, Cross-platform world should work rather easily. (have not tried it since I don't have an Alpha lying around here:-P) See in particular the Makefiles right under src/ there is a good explanation on top in comments of what vars you can set and what they do. As for release, well that's tricky. In theory it should work also but in praxis the study of src/release/Makefile has proven to be some pain at times... note that I have not tried this one either... what I *did* try was however to build 4.3-RELEASE on a -CURRENT box (same platform) and to my great dismay I had to discover that even after loading the bin distribution from the ftp into the release chroot(2), it took heavy amounts of tinkering to get things going... the make world succeeded though, so I assume that most anything would have gone well from that point... in any case, if you want to do a release, study the Makefiles closely and understand what they do. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make world börked ?
=== ld echo extern ld_emulation_xfer_type ld_elf_i386_emulation; ldemul-list.h echo #define EMULATION_LIST ld_elf_i386_emulation, 0 ldemul-list.h ln -sf /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/emultempl/astring.sed stringify.sed yacc -d -o ldgram.c /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldgram.y lex -t /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlex.l ldlex.c sh /flat/src/gnu/usr.bin/binutils/ld/genscripts.sh /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld \/usr/l ib\ i386-unknown-freebsd i386-unknown-freebsd i386-unknown-freebsd elf_i386 elf_i386 i386-unknown-freebsd rm -f .depend mkdep -f .depend -a-D_GNU_SOURCE -I- -I. -I/flat/src/gnu/usr.bin/binutils/ld/i386 -I/flat/src/gnu/usr.bin/binutils/ld -I/ flat/src/gnu/usr.bin/binutils/ld/../libbfd/i386 -I/flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include -DDE FAULT_EMULATION=\elf_i386\ -DTARGET=\i386-unknown-freebsd\ -DSCRIPTDIR=\/usr/obj/flat/src/i386/usr/libdata\ -I/flat/src /gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld -DVERSION=\2.10.1\ -DBFD_VERSION=\2.10.1\ -I/usr/obj/flat/src/i3 86/usr/include eelf_i386.c /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldcref.c /flat/src/gnu/usr.bin/ binutils/ld/../../../../contrib/binutils/ld/ldctor.c /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldemul .c /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldexp.c /flat/src/gnu/usr.bin/binutils/ld/../../../../co ntrib/binutils/ld/ldfile.c ldgram.c /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c ldlex.c /flat/ src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/bi nutils/ld/ldmisc.c /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldver.c /flat/src/gnu/usr.bin/binutils/l d/../../../../contrib/binutils/ld/ldwrite.c /flat/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/lexsup.c /flat/ src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/mri.c eelf_i386.c:158: elf-hints.h: No such file or directory mkdep: compile failed *** Error code 1 1 error *** Error code 2 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
