Re: Howto complete(!) install a world?
On Mon, 27 Mar 2017 15:20:57 +0200 Dimitry Andric wrote: > On 27 Mar 2017, at 15:10, O. Hartmann wrote: > > > > On Mon, 27 Mar 2017 03:12:42 -0700 > > Mark Millard wrote: > >> On 2017-Mar-27, at 2:53 AM, O. Hartmann > >> wrote: > >>> On Mon, 27 Mar 2017 01:54:18 -0700 > >>> Mark Millard wrote: > O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC > 2017 of: > > /usr/bin/ssh: Undefined symbol "msetlocale" > ... > > ldd `which ssh` > > /usr/bin/ssh: > >libprivatessh.so.5 => /lib/libprivatessh.so.5 (0x800853000) > >libgssapi.so.10 => /lib/libgssapi.so.10 (0x800af2000) > >libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e0) > >libc.so.7 => /lib/libc.so.7 (0x801272000) > >libprivateldns.so.5 => /lib/libprivateldns.so.5 (0x80163a000) > >libcrypt.so.5 => /lib/libcrypt.so.5 (0x801897000) > >libz.so.6 => /lib/libz.so.6 (0x801ab5000) > > That is very weird. Private libs such as libprivatessh.so.5 should be > in /usr/lib, never in /lib. Likely, this is what is tripping you up. > > > > objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlocale > > | more 00021690 push %rbp > > Now you are dumping a different libprivatessh.so.5 than /usr/bin/ssh is > actually using. Try checking the copy in /lib: > > nm -D /lib/libprivatessh.so.5 | grep msetlocale > > That said, I would carefully check your make.conf settings related to > installworld. If you override LIBDIR, for instance, I think libraries > might be put in the wrong location. > > -Dimitry > Repairing /lib did it! All libs in /lib were from Feb 3rd and had symbolic links. Thanks for the help! Kind regards, Oliver ___ 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: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]
On 2017-Mar-21, at 7:21 PM, Mark Millard wrote: > On 2017-Mar-18, at 9:10 PM, Mark Millard wrote: > >> >> On 2017-Mar-18, at 5:53 PM, Mark Millard wrote: >> >>> A new, significant discovery follows. . . >>> >>> While checking out use of procstat -v I ran >>> into the following common property for the 3 >>> programs that I looked at: >>> >>> A) My small test program that fails for >>> a dynamically allocated space. >>> >>> B) sh reporting Failed assertion: "tsd_booted". >>> >>> C) su reporting Failed assertion: "tsd_booted". >>> >>> Here are example addresses from the area of >>> incorrectly zeroed memory (A then B then C): >>> >>> (lldb) print dyn_region >>> (region *volatile) $0 = 0x40616000 >>> >>> (lldb) print &__je_tsd_booted >>> (bool *) $0 = 0x40618520 >>> >>> (lldb) print &__je_tsd_booted >>> (bool *) $0 = 0x40618520 >> >> That last above was a copy/paste error. Correction: >> >> (lldb) print &__je_tsd_booted >> (bool *) $0 = 0x4061d520 >> >>> The first is from dynamic allocation ending up >>> in the area. The other two are from libc.so.7 >>> globals/statics ending up in the general area. >>> >>> It looks like something is trashing a specific >>> memory area for some reason, rather independently >>> of what the program specifics are. > > I probably should have noted that the processes > involved were: child/parent then grandparent > and then great grandparent. The grandparent > was sh and the great grandparent was su. > > The ancestors in the process tree are being > damaged, not just the instances of the > program that demonstrates the problem. > >>> Other notes: >>> >>> At least for my small program showing failure: >>> >>> Being explicit about the combined conditions for failure >>> for my test program. . . >>> >>> Both tcache enabled and allocations fitting in SMALL_MAXCLASS >>> are required in order to make the program fail. >>> >>> Note: >>> >>> lldb) print __je_tcache_maxclass >>> (size_t) $0 = 32768 >>> >>> which is larger than SMALL_MAXCLASS. I've not observed >>> failures for sizes above SMALL_MAXCLASS but not exceeding >>> __je_tcache_maxclass. >>> >>> Thus tcache use by itself does not seen sufficient for >>> my program to get corruption of its dynamically allocated >>> memory: the small allocation size also matters. >>> >>> >>> Be warned that I can not eliminate the possibility that >>> the trashing changed what region of memory it trashed >>> for larger allocations or when tcache is disabled. >> >> The pine64+ 2GB eventually got into a state where: >> >> /etc/malloc.conf -> tcache:false >> >> made no difference and the failure kept occurring >> with that symbolic link in place. >> >> But after a reboot of the pin46+ 2GB >> /etc/malloc.conf -> tcache:false was again effective >> for my test program. (It was still present from >> before the reboot.) >> >> I checked the .core files and the allocated address >> assigned to dyn_region was the same in the tries >> before and after the reboot. (I had put in an >> additional raise(SIGABRT) so I'd always have >> a core file to look at.) >> >> Apparently /etc/malloc.conf -> tcache:false was >> being ignored before the reboot for some reason? > > I have also discovered that if the child process > in an example like my program does a: > > (void) posix_madvise(dyn_region, region_size, POSIX_MADV_WILLNEED); > > after the fork but before the sleep/swap-out/wait > then the problem does not happen. This is without > any read or write access to the memory between the > fork and sleep/swap-out/wait. > > By contrast such POSIX_MADV_WILLNEED use in the parent > process does not change the failure behavior. I've added another test program to bugzilla 217239 and 217138, one with thousands of 14 KiByte allocations. The test program usually ends up with them all being zeroed in the parent and child of the fork. But I've had a couple of runs where a much smaller prefix was messed up and then there were normal, expected values. #define region_size (14u*1024u) . . . #define num_regions (256u*1024u*1024u/region_size) So num_regions==18724, using up most of 256 MiBytes. Note: each region has its own 14 KiByte allocation. But dyn_regions[1296].array[0] in one example was the first normal value. In another example dyn_regions[2180].array[4096] was the first normal value. The last is interesting for being part way through an allocation's space. That but aligning with a 4 KiByte page size would seem odd for a pure-jemalloc issue. === Mark Millard markmi at dsl-only.net ___ 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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On 27 Mar 2017, at 23:11, Mark Millard wrote:
>
> On 2017-Mar-27, at 5:53 AM, Dimitry Andric wrote:
>> On 27 Mar 2017, at 12:25, Mark Millard wrote:
>>>
>>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote:
On 26 Mar 2017, at 23:36, Mark Millard wrote:
>> ...
> Installed packages to be REMOVED:
> llvm40-4.0.0.r4
>
> Number of packages to be removed: 1
>
> The operation will free 49 GiB.
Yes, this is big. But there is no real need to build the llvm ports
with debug information, unless you want to hack on llvm itself. And
in that case, you are better served by a Subversion checkout or Git
clone from upstream instead.
>> ...
>>> Historically unless something extreme like this ends up
>>> involved I build everything using WITH_DEBUG= or explicit
>>> -g's in order to have better information on any failure.
>>
>> The problem with the ports implementation of WITH_DEBUG is that it
>> always disables all optimizations, without a possibility to override.
>> Which bloats the resulting object files, libraries and executables, and
>> especially so for large C++ projects such as LLVM.
>>
>> I can recommend the following workaround. If you want to build a port
>> with optimizations disabled, you can always pass -O0 in CFLAGS.
>>
>> -Dimitry
>>
>> Index: Mk/bsd.port.mk
>> ===
>> --- Mk/bsd.port.mk (revision 436685)
>> +++ Mk/bsd.port.mk (working copy)
>> @@ -1646,7 +1646,7 @@ MAKE_ENV+= DONTSTRIP=yes
>> STRIP_CMD= ${TRUE}
>> .endif
>> DEBUG_FLAGS?=-g
>> -CFLAGS:=${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
>> +CFLAGS:=${CFLAGS} ${DEBUG_FLAGS}
>> .if defined(INSTALL_TARGET)
>> INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
>> .endif
>
> Interesting. WITH_DEBUG's description in the file does not
> mention that stripping of optimization flags:
>
> # WITH_DEBUG- If set, debugging flags are added to CFLAGS and the
> # binaries don't get stripped by INSTALL_PROGRAM or
> # INSTALL_LIB. Besides, individual ports might
> # add their specific to produce binaries for debugging
> # purposes. You can override the debug flags that are
> # passed to the compiler by setting DEBUG_FLAGS. It is
> # set to "-g" at default.
>
> I'll probably give myself an override that I can specify in
> /etc/make.conf , such as:
>
> # svnlite diff /usr/ports/Mk/bsd.port.mk
> Index: /usr/ports/Mk/bsd.port.mk
> ===
> --- /usr/ports/Mk/bsd.port.mk (revision 436747)
> +++ /usr/ports/Mk/bsd.port.mk (working copy)
> @@ -1646,7 +1646,11 @@
> STRIP_CMD=${TRUE}
> .endif
> DEBUG_FLAGS?= -g
> +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG)
> +CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS}
> +.else
> CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
> +.endif
> .if defined(INSTALL_TARGET)
> INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
> .endif
Effectively, this gives some sort of support for three of CMake's build
types, e.g:
* Debug, which disables optimization, and obviously adds debuginfo
* Release, which optimizes for speed, and does not add debuginfo
* RelWithDebInfo, similar to Release but does add debuginfo
It would be nice if there was some way of directly utilizing these. The
RelWithDebInfo target is very useful with the LLVM projects.
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On 2017-Mar-27, at 5:53 AM, Dimitry Andric wrote:
> On 27 Mar 2017, at 12:25, Mark Millard wrote:
>>
>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote:
>>> On 26 Mar 2017, at 23:36, Mark Millard wrote:
> ...
Installed packages to be REMOVED:
llvm40-4.0.0.r4
Number of packages to be removed: 1
The operation will free 49 GiB.
>>>
>>> Yes, this is big. But there is no real need to build the llvm ports
>>> with debug information, unless you want to hack on llvm itself. And
>>> in that case, you are better served by a Subversion checkout or Git
>>> clone from upstream instead.
> ...
>> Historically unless something extreme like this ends up
>> involved I build everything using WITH_DEBUG= or explicit
>> -g's in order to have better information on any failure.
>
> The problem with the ports implementation of WITH_DEBUG is that it
> always disables all optimizations, without a possibility to override.
> Which bloats the resulting object files, libraries and executables, and
> especially so for large C++ projects such as LLVM.
>
> I can recommend the following workaround. If you want to build a port
> with optimizations disabled, you can always pass -O0 in CFLAGS.
>
> -Dimitry
>
> Index: Mk/bsd.port.mk
> ===
> --- Mk/bsd.port.mk(revision 436685)
> +++ Mk/bsd.port.mk(working copy)
> @@ -1646,7 +1646,7 @@ MAKE_ENV+= DONTSTRIP=yes
> STRIP_CMD=${TRUE}
> .endif
> DEBUG_FLAGS?= -g
> -CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
> +CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS}
> .if defined(INSTALL_TARGET)
> INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
> .endif
Interesting. WITH_DEBUG's description in the file does not
mention that stripping of optimization flags:
# WITH_DEBUG- If set, debugging flags are added to CFLAGS and the
# binaries don't get stripped by INSTALL_PROGRAM or
# INSTALL_LIB. Besides, individual ports might
# add their specific to produce binaries for debugging
# purposes. You can override the debug flags that are
# passed to the compiler by setting DEBUG_FLAGS. It is
# set to "-g" at default.
I'll probably give myself an override that I can specify in
/etc/make.conf , such as:
# svnlite diff /usr/ports/Mk/bsd.port.mk
Index: /usr/ports/Mk/bsd.port.mk
===
--- /usr/ports/Mk/bsd.port.mk (revision 436747)
+++ /usr/ports/Mk/bsd.port.mk (working copy)
@@ -1646,7 +1646,11 @@
STRIP_CMD= ${TRUE}
.endif
DEBUG_FLAGS?= -g
+.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG)
+CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS}
+.else
CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+.endif
.if defined(INSTALL_TARGET)
INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
.endif
===
Mark Millard
markmi at dsl-only.net
___
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: Howto complete(!) install a world?
Am Mon, 27 Mar 2017 15:20:57 +0200 Dimitry Andric schrieb: > On 27 Mar 2017, at 15:10, O. Hartmann wrote: > > > > On Mon, 27 Mar 2017 03:12:42 -0700 > > Mark Millard wrote: > >> On 2017-Mar-27, at 2:53 AM, O. Hartmann > >> wrote: > >>> On Mon, 27 Mar 2017 01:54:18 -0700 > >>> Mark Millard wrote: > O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC > 2017 > of: > > /usr/bin/ssh: Undefined symbol "msetlocale" > ... > > ldd `which ssh` > > /usr/bin/ssh: > >libprivatessh.so.5 => /lib/libprivatessh.so.5 (0x800853000) > >libgssapi.so.10 => /lib/libgssapi.so.10 (0x800af2000) > >libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e0) > >libc.so.7 => /lib/libc.so.7 (0x801272000) > >libprivateldns.so.5 => /lib/libprivateldns.so.5 (0x80163a000) > >libcrypt.so.5 => /lib/libcrypt.so.5 (0x801897000) > >libz.so.6 => /lib/libz.so.6 (0x801ab5000) > > That is very weird. Private libs such as libprivatessh.so.5 should be > in /usr/lib, never in /lib. Likely, this is what is tripping you up. After you stated this fact, I also see that I have some weird symbolic links in /lib - and I recall some strange thing I did: I used prior to the flash mem drive as stated above one that has been released on Feb, 3rd! Therefore, I think, the weird date. All my boxes I have investigated after your comment here do have /lib updated accordingly to the last "make installworld". Except the box that is suffering the problems! I think my little stupid "pax" manouvre in the first place corrupted something and after I failed, I swapped to a more recent FreeBSD image (23rd March) and fullfilled - with hidden consequences :-( The question of how to install a FreeBSD completely (means: force a complete install of a world except configuration files, I was having the libs in mind) arose from this problem. Once in my office again, I'll check that and somehow I need a plan how to update/exchange /lib without corrupting the system. Now /rescue with statically linked binaries come into play. Maybe a "DESTDIR=" driven shadow installation should suffice. The /lib folder on healthy systems do not show symbolic links ... > > > > objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlocale > > | > > more 00021690 push %rbp > > Now you are dumping a different libprivatessh.so.5 than /usr/bin/ssh is > actually using. Try checking the copy in /lib: > > nm -D /lib/libprivatessh.so.5 | grep msetlocale > > That said, I would carefully check your make.conf settings related to > installworld. If you override LIBDIR, for instance, I think libraries > might be put in the wrong location. > > -Dimitry > -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpgXWCcBQAPa.pgp Description: OpenPGP digital signature
Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current
> > I've got another report about this problem, but I can not reproduce it here > with > a clean kernel build of GENERIC. > I am not sure what the problem is. > Do you have anything unusual in make.conf, src.conf or your kernel > configuration? > > -- > Andriy Gapon > Here is my src.conf: WITHOUT_DYNAMICROOT=yes WITHOUT_UNBOUND=yes WITHOUT_CASPER=yes WITHOUT_CAPSICUM=yes WITHOUT_DMAGENT=yes WITHOUT_PROFILE=yes WITHOUT_TESTS=yes WITHOUT_KERNEL_SYMBOLS=yes WITHOUT_DEBUG_FILES=1 WITHOUT_LIB32=yes INSTALL_NODEBUG=yes NO_WERROR= WERROR= KERNCONF=pozo WITH_CCACHE_BUILD=yes Here is make.conf: MODULES_OVERRIDE= BOOT_COMCONSOLE_PORT=0x3F8 BOOT_COMCONSOLE_SPEED=57600 DOC_LANG=en_US.ISO8859-1 SENDMAIL_MC=/root/config-files/pozo-hp-8000-sff/sendmail/pozo.mc SENDMAIL_SUBMIT_MC=/root/config-files/pozo-hp-8000-sff/sendmail/pozo-submit.mc SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base MALLOC_PRODUCTION=yes WITH_BDB_VERSION=5 I have the same thing happen on another machine wth custom kernel and modules. Could it be ccache ? for now i do: cd /sys/amd64/conf config pozo cd /sys/amd64/compile/pozo make device_if.h make bus_if.h make depend make -j8 make install and it builds fine -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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: Howto complete(!) install a world?
On 27 Mar 2017, at 15:10, O. Hartmann wrote: > > On Mon, 27 Mar 2017 03:12:42 -0700 > Mark Millard wrote: >> On 2017-Mar-27, at 2:53 AM, O. Hartmann wrote: >>> On Mon, 27 Mar 2017 01:54:18 -0700 >>> Mark Millard wrote: O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC 2017 of: > /usr/bin/ssh: Undefined symbol "msetlocale" ... > ldd `which ssh` > /usr/bin/ssh: >libprivatessh.so.5 => /lib/libprivatessh.so.5 (0x800853000) >libgssapi.so.10 => /lib/libgssapi.so.10 (0x800af2000) >libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e0) >libc.so.7 => /lib/libc.so.7 (0x801272000) >libprivateldns.so.5 => /lib/libprivateldns.so.5 (0x80163a000) >libcrypt.so.5 => /lib/libcrypt.so.5 (0x801897000) >libz.so.6 => /lib/libz.so.6 (0x801ab5000) That is very weird. Private libs such as libprivatessh.so.5 should be in /usr/lib, never in /lib. Likely, this is what is tripping you up. > objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlocale | > more 00021690 push %rbp Now you are dumping a different libprivatessh.so.5 than /usr/bin/ssh is actually using. Try checking the copy in /lib: nm -D /lib/libprivatessh.so.5 | grep msetlocale That said, I would carefully check your make.conf settings related to installworld. If you override LIBDIR, for instance, I think libraries might be put in the wrong location. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: Opteron 6100-series "Magny-Cours"
On 27/03/2017 15:06, Piotr Kubaj wrote: > Does it have to be specifically 61xx series? I have a server running 2 > 6262HE's. > Yes. I have the info that I need for 62xx Opterons. Thanks. -- Andriy Gapon ___ 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: Howto complete(!) install a world?
On Mon, 27 Mar 2017 03:12:42 -0700 Mark Millard wrote: > On 2017-Mar-27, at 2:53 AM, O. Hartmann wrote: > > > On Mon, 27 Mar 2017 01:54:18 -0700 > > Mark Millard wrote: > > > >> O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC 2017 > >> of: > >> > >>> /usr/bin/ssh: Undefined symbol "msetlocale" > >> > >> > >> I do not know if this will help or not. . . > >> (Notes based on head -r315914 for amd64.) > >> > >> Looking around: > >> > >> # grep -R msetlocale /usr/src/*/ | more > >> /usr/src/crypto/openssh/ssh.c: msetlocale(); > >> /usr/src/crypto/openssh/utf8.h:void msetlocale(void); > >> /usr/src/crypto/openssh/sftp.c: msetlocale(); > >> /usr/src/crypto/openssh/scp.c: msetlocale(); > >> /usr/src/crypto/openssh/utf8.c:msetlocale(void) > >> > >> It looks like msetlocale is local to openssh itself and is > >> tied to utf8 support. > >> > >> # ldd `which ssh` > >> /usr/bin/ssh: > >>libprivatessh.so.5 => /usr/lib/libprivatessh.so.5 (0x800851000) > >>libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800af2000) > >>libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e0) > >>libc.so.7 => /lib/libc.so.7 (0x801269000) > >>libprivateldns.so.5 => /usr/lib/libprivateldns.so.5 (0x801624000) > >>libcrypt.so.5 => /lib/libcrypt.so.5 (0x801882000) > >> > >> # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | more > >> > >> /usr/lib/libprivatessh.so.5: file format elf64-x86-64-freebsd > >> . . . > >> 00020e40 push %rbp > >> 00020e41 mov%rsp,%rbp > >> 00020e44 push %rbx > >> 00020e45 push %rax > >> 00020e46 lea0x4c4e2(%rip),%rdi# > >> 0006d32f <_fini+0x1c67> . . . > >> > >> So it is /usr/lib/libprivateshh.so.5 that should have > >> msetlocale in it. > > > > I've already deleted that lib manually and "make installworld" did reinstall > > the lib again. > > > > No effect. > > > > The problem occurs only on that crashed box :-( > > > > Do commands similar to what I showed agree with what I shown? I think, yes, see belwo: > > # grep -R msetlocale /usr/src/*/ | more grep -R msetlocale /usr/src/*/ | more /usr/src/crypto/openssh/scp.c: msetlocale(); /usr/src/crypto/openssh/sftp.c: msetlocale(); /usr/src/crypto/openssh/ssh.c: msetlocale(); /usr/src/crypto/openssh/utf8.h:void msetlocale(void); /usr/src/crypto/openssh/utf8.c:msetlocale(void) > > # ldd `which ssh` ldd `which ssh` /usr/bin/ssh: libprivatessh.so.5 => /lib/libprivatessh.so.5 (0x800853000) libgssapi.so.10 => /lib/libgssapi.so.10 (0x800af2000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e0) libc.so.7 => /lib/libc.so.7 (0x801272000) libprivateldns.so.5 => /lib/libprivateldns.so.5 (0x80163a000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x801897000) libz.so.6 => /lib/libz.so.6 (0x801ab5000) > > # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlocale > | more objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlocale | more 00021690 push %rbp 00021691 mov%rsp,%rbp 00021694 push %rbx 00021695 push %rax 00021696 lea0x59dd2(%rip),%rdi# 0007b46f <_fini@@Base+0x1c77> 0002169d callq 00019f9c 000216a2 mov%rax,%rbx 000216a5 test %rbx,%rbx 000216a8 jne000216d2 000216aa lea 0x59dc5(%rip),%rdi# 0007b476 <_fini@@Base+0x1c7e> 000216b1 callq 00019f9c 000216b6 mov%rax,%rbx 000216b9 test %rbx,%rbx 000216bc jne000216d2 000216be lea0x59dba(%rip),%rdi# 0007b47f <_fini@@Base+0x1c87> 000216c5 callq 00019f9c 000216ca mov%rax,%rbx 000216cd test %rbx,%rbx 000216d0 je 000216ea 000216d2 lea 0x59dab(%rip),%rsi# 0007b484 <_fini@@Base+0x1c8c> 000216d9 mov$0x2,%edx 000216de mov%rbx,%rdi 000216e1 callq 00019c3c 000216e6 test %eax,%eax 000216e8 je 00021701 000216ea lea0x5af18(%rip),%rsi# 0007c609 <_fini@@Base+0x2e11> 000216f1 mov$0x2,%edi 000216f6 add$0x8,%rsp 000216fa pop%rbx 000216fb pop%rbp 000216fc jmpq 000198ac 00021701 lea0x59d86(%rip),%rsi# 0007b48e <_fini@@Base+0x1c96> 00021708 mov%rbx,%rdi 0002170b callq 0001a69c 00021710 test %rax,%rax 00021713 jne00021729 00021715 lea 0x59d6b(%rip),%rsi# 0007b487 <_fini@@Base+0x1c8f> 0002171c mov%rbx,%rdi 0002171f callq 0001a69c 00021724 test %rax,%rax 00021727 je 0002175
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On 27 Mar 2017, at 12:25, Mark Millard wrote:
>
> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote:
>> On 26 Mar 2017, at 23:36, Mark Millard wrote:
...
>>> Installed packages to be REMOVED:
>>> llvm40-4.0.0.r4
>>>
>>> Number of packages to be removed: 1
>>>
>>> The operation will free 49 GiB.
>>
>> Yes, this is big. But there is no real need to build the llvm ports
>> with debug information, unless you want to hack on llvm itself. And
>> in that case, you are better served by a Subversion checkout or Git
>> clone from upstream instead.
...
> Historically unless something extreme like this ends up
> involved I build everything using WITH_DEBUG= or explicit
> -g's in order to have better information on any failure.
The problem with the ports implementation of WITH_DEBUG is that it
always disables all optimizations, without a possibility to override.
Which bloats the resulting object files, libraries and executables, and
especially so for large C++ projects such as LLVM.
I can recommend the following workaround. If you want to build a port
with optimizations disabled, you can always pass -O0 in CFLAGS.
-Dimitry
Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk (revision 436685)
+++ Mk/bsd.port.mk (working copy)
@@ -1646,7 +1646,7 @@ MAKE_ENV+=DONTSTRIP=yes
STRIP_CMD= ${TRUE}
.endif
DEBUG_FLAGS?= -g
-CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS}
.if defined(INSTALL_TARGET)
INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
.endif
signature.asc
Description: Message signed with OpenPGP
Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current
Am 27.03.2017 um 13:07 schrieb Andriy Gapon: On 03/27/2017 14:35, Rainer Hurling wrote: Am 27.03.2017 um 10:31 schrieb Andriy Gapon: On 03/26/2017 00:21, Manfred Antar wrote: Recent change to genassym.c breaks building a current kernel: -- stage 3.1: building everything -- cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=4 COMPILER_TYPE=clang COMPILER_FREEBSD_VERSION=126 MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="/usr/local/bin/ccache c++ -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ machine -> /usr/src/sys/amd64/include x86 -> /usr/src/sys/x86/include /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9 899:1999 /usr/src/sys/amd64/amd64/genassym.c In file included from /usr/src/sys/amd64/amd64/genassym.c:47: /usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error generated. *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/pozo *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src cd /usr/obj/usr/src/sys/pozo ; make device_if.h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h also bus_if.h is missing: (pozo)5023}make /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 /usr/src/sys/amd64/amd64/genassym.c In file included from /usr/src/sys/amd64/amd64/genassym.c:47: /usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found so: make bus_if.h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h then the build works: MAKE=make sh /usr/src/sys/conf/newvers.sh pozo --- vers.o --- /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf_
Re: Opteron 6100-series "Magny-Cours"
Does it have to be specifically 61xx series? I have a server running 2 6262HE's. signature.asc Description: PGP signature
Re: Opteron 6100-series "Magny-Cours"
On 03/25/17 19:02, Andriy Gapon wrote: Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with FreeBSD? Will an equivalent Athlon do or is this Opteron specific? What would that Athlon be? bye av. ___ 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: Howto complete(!) install a world?
On Mon, 27 Mar 2017 01:54:18 -0700 Mark Millard wrote: > O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC 2017 > of: > > > /usr/bin/ssh: Undefined symbol "msetlocale" > > > I do not know if this will help or not. . . > (Notes based on head -r315914 for amd64.) > > Looking around: > > # grep -R msetlocale /usr/src/*/ | more > /usr/src/crypto/openssh/ssh.c: msetlocale(); > /usr/src/crypto/openssh/utf8.h:void msetlocale(void); > /usr/src/crypto/openssh/sftp.c: msetlocale(); > /usr/src/crypto/openssh/scp.c: msetlocale(); > /usr/src/crypto/openssh/utf8.c:msetlocale(void) > > It looks like msetlocale is local to openssh itself and is > tied to utf8 support. > > # ldd `which ssh` > /usr/bin/ssh: > libprivatessh.so.5 => /usr/lib/libprivatessh.so.5 (0x800851000) > libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800af2000) > libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e0) > libc.so.7 => /lib/libc.so.7 (0x801269000) > libprivateldns.so.5 => /usr/lib/libprivateldns.so.5 (0x801624000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x801882000) > > # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | more > > /usr/lib/libprivatessh.so.5: file format elf64-x86-64-freebsd > . . . > 00020e40 push %rbp > 00020e41 mov%rsp,%rbp > 00020e44 push %rbx > 00020e45 push %rax > 00020e46 lea0x4c4e2(%rip),%rdi# > 0006d32f <_fini+0x1c67> . . . > > So it is /usr/lib/libprivateshh.so.5 that should have > msetlocale in it. I've already deleted that lib manually and "make installworld" did reinstall the lib again. No effect. The problem occurs only on that crashed box :-( > > > === > Mark Millard > markmi at dsl-only.net > > ___ > 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" ___ 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: r315900: /usr/bin/ssh: Undefined symbol "msetlocale"
On Fri, 24 Mar 2017 15:28:31 +0100 Andreas Nilsson wrote: > On Fri, Mar 24, 2017 at 2:37 PM, O. Hartmann wrote: > > > Having just updated CURRENT to CURRENT 12.0-CURRENT FreeBSD 12.0-CURRENT #1 > > r315900: Fri Mar 24 14:17:22 CET 2017 amd64, I can not connect to remote > > systems via ssh anymore: > > > > /usr/bin/ssh: Undefined symbol "msetlocale" > > > > Google suggests for this kind of error a miscompilation of the binary. > > > > I had a crash, again (SSDs and CURRENT have a serious problem!), had to > > improvise with the USB flash ISO image of CURRENT found on FreeBSD.org from > > 23.03.2017, ~ 18 o'clock, but have rebuilt and installed world and kernel > > from a > > clean /usr/obj two times. Still being bugged by this mysterious error. > > > > Can somebody help, please? > > > > Thanks in advance, > > Oliver > > ___ > > 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" > > > > > I haven't upgraded myself yet, but I fetched the sources. > > Could you check ldd /usr/bin/ssh ? > If you have libprivatessh in there, could you do nm -D > /usr/lib/libprivatessh.so | grep msetlocale and see if you get any output ( > I think you should get one line ) > > Otherwise it would seem that either libprivatessh is not built correctly or > that it is not installed correctly. But these are just my guesses. > > Best regards > Andreas > ___ > 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" The answer to nm -D is: 00021690 T msetlocale I have finished a buildworld from a fresh (clean/empty /usr/obj/ ) start and give that a try as soon I can installworkd/installkernel and reboot. Thank you very much, Oliver ___ 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: Howto complete(!) install a world?
On Mon, 27 Mar 2017 10:10:29 +0200, "O. Hartmann" wrote: > After a crash in which repeatedly portions of the base tree of FreeBSD has > nullified on a SSD system "disk" (UFS), I had to save and repair on Friday, > 24th March anno 2017 the broken infrastructure by copying (via pax -rw -p e) > the binaries from the recent USB (memstick) image of 23rd provided by > freebsd.org download site. > > After rebuilding and installing a complete "world" (make buildworld on a > delete /usr/obj, so to ensure it is empty), I still face a nasty ssh problem > (/usr/bin/ssh: Undefined symbol "msetlocale"). > > I checked the age of the libraries, especially the libraries, which has > supposedly been installed and although I did in the past update/buildworld on > a > daily base, /lib is populated with libraries dated on February, 3rd, > and /libexec still has the ld-elf.so libs from 23rd/24th. > > Using "kldload filemon" in conjuction with /etc/src-env.conf containing > WITH_META_MODE= YES I'd expect such a thing, but I got confused with > "/lib". Since Feb 3rd, LLVM 4.0 has been introduced and all libs should > definitely have been recompiled, haven't they? > > After rebuilding a "clean" world, I'd like to know how I can force a complete > and radical installation of ALL what's in /usr/src and /usr/obj - meaning: how > to force the installation process to install even those libs/files/bins which > the installer suppose to be not necessary to be installed? > > After two times rebuilding now world and installing it I can not get rid of > this nasty ssh problem which prevents me from login onto remote systems and I > suspect a faulty library to be the culprit. libprivatessh.so is installed on > every rund of installworld accordingly to its date/ctime, I also delete the > *.a > and *_p.a archives and had them reinstalled, but without success. > > Help! > > Kind regards and thanks in advance, > > Oliver > ___ > 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" This highlights what I think is one of my foremost concerns as to 'why not is part of FreeBSD yet' namely the proof that an installworld can complete [think 'foolproof staging' ] before the installworld is actually 'ENTER' keyed... b... fallback /var/db/pkg flat file pkg equivalent re-done and CARP-like failover c... 2005 era install bsd ncurses menus allowing setting partitions and type d... pkg updates to allow 'beastie boot menu 'choose options' style fixing of each line in each FreeBSD.conf and pkg.conf so that they are what pkg expects to be there, vs what are there... if you grasp that. e... lint >> GENERIC heavily commented to allow... f...e1... an ncurses-build-line-by-line-completion of a kernel file so that each line omit/include is understood as to consequence AKA bios menus. g...flow chart [ 8 sided raw disk >> 8 side which raid do you want huge 2 meter by two meter ZFS decision tree aka shareware 1998 style inclusions, some of them so one does not depend upon guides from, say, Solaris h more, but that should do. Just tacking on gossip, sorry... please read the three lines above this list so I do not de-emphasize the point of this reply, and thank you so very kindly for reading. Sort of like a 'me too...' ___ 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: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current
On 03/27/2017 14:35, Rainer Hurling wrote: > Am 27.03.2017 um 10:31 schrieb Andriy Gapon: >> On 03/26/2017 00:21, Manfred Antar wrote: >>> Recent change to genassym.c breaks building a current kernel: >>> >>> -- >> stage 3.1: building everything >>> -- >>> cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=4 COMPILER_TYPE=clang >>> COMPILER_FREEBSD_VERSION=126 MAKEOBJDIRPREFIX=/usr/obj >>> MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= >>> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin >>> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font >>> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac >>> CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 >>> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" >>> CXX="/usr/local/bin/ccache c++ -target x86_64-unknown-freebsd12.0 >>> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp >>> -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp >>> -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm >>> OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh >>> /usr/src/tools/install.sh" >>> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr >>> >> /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m >> /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ >>> machine -> /usr/src/sys/amd64/include >>> x86 -> /usr/src/sys/x86/include >>> /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 >>> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe >>> -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys >>> -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS >>> -include >>> opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD >>> -MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx >>> -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv >>> -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs >>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline >>> -Wcast-qual >>> -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ >>> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas >>> -Wno-error-tautological-compare -Wno-error-empty-body >>> -Wno-error-parentheses-equality -Wno-error-unused-function >>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>> -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9 >> 899:1999 /usr/src/sys/amd64/amd64/genassym.c >>> In file included from /usr/src/sys/amd64/amd64/genassym.c:47: >>> /usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found >>> #include "device_if.h" >>> ^ >>> 1 error generated. >>> *** Error code 1 >>> >>> Stop. >>> make[2]: stopped in /usr/obj/usr/src/sys/pozo >>> *** Error code 1 >>> >>> Stop. >>> make[1]: stopped in /usr/src >>> *** Error code 1 >>> >>> Stop. >>> make: stopped in /usr/src >>> >>> >>> cd /usr/obj/usr/src/sys/pozo ; make device_if.h >>> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h >>> >>> also bus_if.h is missing: >>> (pozo)5023}make >>> /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. >>> -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL >>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer >>> -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o >>> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float >>> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector >>> -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >>> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs >>> -fdiagnostics-show-option -Wno-unknown-pragmas >>> -Wno-error-tautological-compare -Wno-error-empty-body >>> -Wno-error-parentheses-equality -Wno-error-unused-function >>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>> -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 >>> /usr/src/sys/amd64/amd64/genassym.c >>> In file included from /usr/src/sys/amd64/amd64/genassym.c:47: >>> /usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found >>> >>> so: >>> make bus_if.h >>> awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h >>> then the build works: >>> >>> MAKE=make sh /usr/src/sys/conf/newvers.sh pozo >>> --- vers.o --- >>> /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc >>> -I. >>> -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL >>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer >>> -mno-omit-leaf-fram
Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current
Am 27.03.2017 um 10:31 schrieb Andriy Gapon: On 03/26/2017 00:21, Manfred Antar wrote: Recent change to genassym.c breaks building a current kernel: -- stage 3.1: building everything -- cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=4 COMPILER_TYPE=clang COMPILER_FREEBSD_VERSION=126 MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="/usr/local/bin/ccache c++ -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/us r /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ machine -> /usr/src/sys/amd64/include x86 -> /usr/src/sys/x86/include /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso 9 899:1999 /usr/src/sys/amd64/amd64/genassym.c In file included from /usr/src/sys/amd64/amd64/genassym.c:47: /usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found #include "device_if.h" ^ 1 error generated. *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/pozo *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src cd /usr/obj/usr/src/sys/pozo ; make device_if.h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h also bus_if.h is missing: (pozo)5023}make /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 /usr/src/sys/amd64/amd64/genassym.c In file included from /usr/src/sys/amd64/amd64/genassym.c:47: /usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found so: make bus_if.h awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h then the build works: MAKE=make sh /usr/src/sys/conf/newvers.sh pozo --- vers.o --- /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On 2017-Mar-27, at 3:25 AM, Mark Millard wrote: > On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: > >> On 26 Mar 2017, at 23:36, Mark Millard wrote: >>> >>> I upgraded from llvm40 r4 to final. An interesting result was >>> its creation of a backup package for llvm40-4.0.0.r4: >>> >>> about 13 cpu-core-hours running pkg create >>> >>> (Remember: I've been building with WITH_DEBUG= ) Its >>> single-threaded status stands out via elapsed time >>> approximately matching. >>> >>> I'll note that it was somewhat under 6 elapsed hours for >>> staging to have been populated (-j4 with 4 cores present >>> helps for this part). >>> >>> (Of course these elapsed-time figures are rather system >>> dependent, although the ratio might be more stable.) >>> >>> >>> >>> Also interesting was: >>> >>> Installed packages to be REMOVED: >>> llvm40-4.0.0.r4 >>> >>> Number of packages to be removed: 1 >>> >>> The operation will free 49 GiB. >> >> Yes, this is big. But there is no real need to build the llvm ports >> with debug information, unless you want to hack on llvm itself. And >> in that case, you are better served by a Subversion checkout or Git >> clone from upstream instead. >> >> -Dimitry > > FYI: > > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG= or explicit > -g's in order to have better information on any failure. > > This is extreme enough that next time I synchronize > /usr/ports and it has a devel/llvm40 update I'll > likely rebuild devel/llvm40 without using WITH_DEBUG= . > I'm more concerned with the time it takes than with > the file system space involved. [Bad example of a incomplete thought. . .] That last presumes a hardware environment with lots of RAM (such as 16 GiBytes) --which I usually do not have access to. Having such is why the report was from a powerpc64 context: that is where I've access to that much RAM for FreeBSD. === Mark Millard markmi at dsl-only.net ___ 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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote: > On 26 Mar 2017, at 23:36, Mark Millard wrote: >> >> I upgraded from llvm40 r4 to final. An interesting result was >> its creation of a backup package for llvm40-4.0.0.r4: >> >> about 13 cpu-core-hours running pkg create >> >> (Remember: I've been building with WITH_DEBUG= ) Its >> single-threaded status stands out via elapsed time >> approximately matching. >> >> I'll note that it was somewhat under 6 elapsed hours for >> staging to have been populated (-j4 with 4 cores present >> helps for this part). >> >> (Of course these elapsed-time figures are rather system >> dependent, although the ratio might be more stable.) >> >> >> >> Also interesting was: >> >> Installed packages to be REMOVED: >> llvm40-4.0.0.r4 >> >> Number of packages to be removed: 1 >> >> The operation will free 49 GiB. > > Yes, this is big. But there is no real need to build the llvm ports > with debug information, unless you want to hack on llvm itself. And > in that case, you are better served by a Subversion checkout or Git > clone from upstream instead. > > -Dimitry FYI: Historically unless something extreme like this ends up involved I build everything using WITH_DEBUG= or explicit -g's in order to have better information on any failure. This is extreme enough that next time I synchronize /usr/ports and it has a devel/llvm40 update I'll likely rebuild devel/llvm40 without using WITH_DEBUG= . I'm more concerned with the time it takes than with the file system space involved. === Mark Millard markmi at dsl-only.net ___ 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: Howto complete(!) install a world?
On 2017-Mar-27, at 2:53 AM, O. Hartmann wrote: > On Mon, 27 Mar 2017 01:54:18 -0700 > Mark Millard wrote: > >> O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC 2017 >> of: >> >>> /usr/bin/ssh: Undefined symbol "msetlocale" >> >> >> I do not know if this will help or not. . . >> (Notes based on head -r315914 for amd64.) >> >> Looking around: >> >> # grep -R msetlocale /usr/src/*/ | more >> /usr/src/crypto/openssh/ssh.c: msetlocale(); >> /usr/src/crypto/openssh/utf8.h:void msetlocale(void); >> /usr/src/crypto/openssh/sftp.c: msetlocale(); >> /usr/src/crypto/openssh/scp.c: msetlocale(); >> /usr/src/crypto/openssh/utf8.c:msetlocale(void) >> >> It looks like msetlocale is local to openssh itself and is >> tied to utf8 support. >> >> # ldd `which ssh` >> /usr/bin/ssh: >>libprivatessh.so.5 => /usr/lib/libprivatessh.so.5 (0x800851000) >>libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800af2000) >>libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e0) >>libc.so.7 => /lib/libc.so.7 (0x801269000) >>libprivateldns.so.5 => /usr/lib/libprivateldns.so.5 (0x801624000) >>libcrypt.so.5 => /lib/libcrypt.so.5 (0x801882000) >> >> # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | more >> >> /usr/lib/libprivatessh.so.5: file format elf64-x86-64-freebsd >> . . . >> 00020e40 push %rbp >> 00020e41 mov%rsp,%rbp >> 00020e44 push %rbx >> 00020e45 push %rax >> 00020e46 lea0x4c4e2(%rip),%rdi# >> 0006d32f <_fini+0x1c67> . . . >> >> So it is /usr/lib/libprivateshh.so.5 that should have >> msetlocale in it. > > I've already deleted that lib manually and "make installworld" did reinstall > the lib again. > > No effect. > > The problem occurs only on that crashed box :-( Do commands similar to what I showed agree with what I shown? # grep -R msetlocale /usr/src/*/ | more # ldd `which ssh` # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | grep msetlocale | more (That last presumes that ldd's output points to that file instead of some alternative.) === Mark Millard markmi at dsl-only.net ___ 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: Opteron 6100-series "Magny-Cours"
On 03/25/2017 23:26, Jack L. wrote: > I have a few still sitting in a corner with FreeBSD 7 or 8 on them. Someday i > might put them back on with FreeBSD but not anytime soon Apologies for not qualifying my question. I would like to obtain some information from such a system and possibly to ask to test a patch. Looks like you won't be able to help with that. At least, until that some day :-). >> On Mar 25, 2017, at 11:02 AM, Andriy Gapon wrote: >> >> >> Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with >> FreeBSD? -- Andriy Gapon ___ 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: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
On 26 Mar 2017, at 23:36, Mark Millard wrote: > > I upgraded from llvm40 r4 to final. An interesting result was > its creation of a backup package for llvm40-4.0.0.r4: > > about 13 cpu-core-hours running pkg create > > (Remember: I've been building with WITH_DEBUG= ) Its > single-threaded status stands out via elapsed time > approximately matching. > > I'll note that it was somewhat under 6 elapsed hours for > staging to have been populated (-j4 with 4 cores present > helps for this part). > > (Of course these elapsed-time figures are rather system > dependent, although the ratio might be more stable.) > > > > Also interesting was: > > Installed packages to be REMOVED: > llvm40-4.0.0.r4 > > Number of packages to be removed: 1 > > The operation will free 49 GiB. Yes, this is big. But there is no real need to build the llvm ports with debug information, unless you want to hack on llvm itself. And in that case, you are better served by a Subversion checkout or Git clone from upstream instead. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: Howto complete(!) install a world?
O. Hartmann ohartmann at walstatt.org wrote on Mon Mar 27 08:10:39 UTC 2017 of: > /usr/bin/ssh: Undefined symbol "msetlocale" I do not know if this will help or not. . . (Notes based on head -r315914 for amd64.) Looking around: # grep -R msetlocale /usr/src/*/ | more /usr/src/crypto/openssh/ssh.c: msetlocale(); /usr/src/crypto/openssh/utf8.h:void msetlocale(void); /usr/src/crypto/openssh/sftp.c: msetlocale(); /usr/src/crypto/openssh/scp.c: msetlocale(); /usr/src/crypto/openssh/utf8.c:msetlocale(void) It looks like msetlocale is local to openssh itself and is tied to utf8 support. # ldd `which ssh` /usr/bin/ssh: libprivatessh.so.5 => /usr/lib/libprivatessh.so.5 (0x800851000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x800af2000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x800e0) libc.so.7 => /lib/libc.so.7 (0x801269000) libprivateldns.so.5 => /usr/lib/libprivateldns.so.5 (0x801624000) libcrypt.so.5 => /lib/libcrypt.so.5 (0x801882000) # objdump -d --prefix-addresses /usr/lib/libprivatessh.so.5 | more /usr/lib/libprivatessh.so.5: file format elf64-x86-64-freebsd . . . 00020e40 push %rbp 00020e41 mov%rsp,%rbp 00020e44 push %rbx 00020e45 push %rax 00020e46 lea0x4c4e2(%rip),%rdi# 0006d32f <_fini+0x1c67> . . . So it is /usr/lib/libprivateshh.so.5 that should have msetlocale in it. === Mark Millard markmi at dsl-only.net ___ 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: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current
On 03/26/2017 00:21, Manfred Antar wrote: > Recent change to genassym.c breaks building a current kernel: > > -- stage 3.1: building everything > -- > cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=4 COMPILER_TYPE=clang > COMPILER_FREEBSD_VERSION=126 MAKEOBJDIRPREFIX=/usr/obj > MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font > GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac > CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 > --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" > CXX="/usr/local/bin/ccache c++ -target x86_64-unknown-freebsd12.0 > --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp > -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp > -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm > OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh > /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -m /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ > machine -> /usr/src/sys/amd64/include > x86 -> /usr/src/sys/x86/include > /usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 > --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe > -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD > -MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx > -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv > -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9 899:1999 /usr/src/sys/amd64/amd64/genassym.c > In file included from /usr/src/sys/amd64/amd64/genassym.c:47: > /usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found > #include "device_if.h" > ^ > 1 error generated. > *** Error code 1 > > Stop. > make[2]: stopped in /usr/obj/usr/src/sys/pozo > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > > > cd /usr/obj/usr/src/sys/pozo ; make device_if.h > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h > > also bus_if.h is missing: > (pozo)5023}make > /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. > -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o > -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector > -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 > /usr/src/sys/amd64/amd64/genassym.c > In file included from /usr/src/sys/amd64/amd64/genassym.c:47: > /usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found > > so: > make bus_if.h > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h > then the build works: > > MAKE=make sh /usr/src/sys/conf/newvers.sh pozo > --- vers.o --- > /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. > -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv > -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -W
Howto complete(!) install a world?
After a crash in which repeatedly portions of the base tree of FreeBSD has nullified on a SSD system "disk" (UFS), I had to save and repair on Friday, 24th March anno 2017 the broken infrastructure by copying (via pax -rw -p e) the binaries from the recent USB (memstick) image of 23rd provided by freebsd.org download site. After rebuilding and installing a complete "world" (make buildworld on a delete /usr/obj, so to ensure it is empty), I still face a nasty ssh problem (/usr/bin/ssh: Undefined symbol "msetlocale"). I checked the age of the libraries, especially the libraries, which has supposedly been installed and although I did in the past update/buildworld on a daily base, /lib is populated with libraries dated on February, 3rd, and /libexec still has the ld-elf.so libs from 23rd/24th. Using "kldload filemon" in conjuction with /etc/src-env.conf containing WITH_META_MODE= YES I'd expect such a thing, but I got confused with "/lib". Since Feb 3rd, LLVM 4.0 has been introduced and all libs should definitely have been recompiled, haven't they? After rebuilding a "clean" world, I'd like to know how I can force a complete and radical installation of ALL what's in /usr/src and /usr/obj - meaning: how to force the installation process to install even those libs/files/bins which the installer suppose to be not necessary to be installed? After two times rebuilding now world and installing it I can not get rid of this nasty ssh problem which prevents me from login onto remote systems and I suspect a faulty library to be the culprit. libprivatessh.so is installed on every rund of installworld accordingly to its date/ctime, I also delete the *.a and *_p.a archives and had them reinstalled, but without success. Help! Kind regards and thanks in advance, Oliver ___ 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"
