Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
Chromium was rebuilt Nov 28. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. In message <002301d49f01$f83c6bc0$e8b54340$@btinternet.com>, "Thomas Sparrevohn " writes: > Just rebuild Chrome from scratch same issue - I try to rebuild glib - system > upgraded both in terms and pkg as of today > > -Original Message- > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-current@freebsd > .org] On Behalf Of Cy Schubert > Sent: 28 December 2018 20:56 > To: Antoine Brodin > Cc: Graham Perrin ; FreeBSD Current freebsd.org> > Subject: Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol " > environ" > > In message il.com> > , Antoine Brodin writes: > > On Fri, Dec 28, 2018 at 8:39 PM Graham Perrin wrot > e: > > > > > > On Fri, 28 Dec 2018 at 16:31, Emiel Kollof > > > wrot > > e: > > > > > > > Confirmed with Chromium on my CURRENT box: > > > > > > ââ¬Â¦ > > > > > > Thanks folks. Should I report it as a bug with devel/glib20? > > > > Hi, > > > > I think it's a regression in the toolchain (the problem doesn't occur > > on 11.2 or 12.0), so it should be reported to freebsd-toolchain@ > > No issue here however I rebuilt glib on Dec 21. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > ___ > freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/li > stinfo/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: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
Just rebuild Chrome from scratch same issue - I try to rebuild glib - system upgraded both in terms and pkg as of today -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Cy Schubert Sent: 28 December 2018 20:56 To: Antoine Brodin Cc: Graham Perrin ; FreeBSD Current Subject: Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" In message , Antoine Brodin writes: > On Fri, Dec 28, 2018 at 8:39 PM Graham Perrin wrote: > > > > On Fri, 28 Dec 2018 at 16:31, Emiel Kollof > > wrot > e: > > > > > Confirmed with Chromium on my CURRENT box: > > > > … > > > > Thanks folks. Should I report it as a bug with devel/glib20? > > Hi, > > I think it's a regression in the toolchain (the problem doesn't occur > on 11.2 or 12.0), so it should be reported to freebsd-toolchain@ No issue here however I rebuilt glib on Dec 21. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: r342378 fails sometimes on boot mounting root (error 2)
On 28.12.18 19:45, Matthias Apitz wrote: El día viernes, diciembre 28, 2018 a las 09:07:49a. m. -0700, Ian Lepore escribió: Try setting vfs.mountroot.timeout= in loader.conf to a value long enough to let the usb drive get probed reliably. The default is 3 seconds, maybe a value like 5 or 10 would work better for you. -- Ian Thanks. I did so, but this does not help. When I does not work even after 20 secs it fails to mount. After a lot of boot attempts I have the following picture: 1. It always mounts fine when verbose message is selected. 2. It mounts fine when the line below about 'umass0:1:0: Attached to ... ' is printed, if it is not, the mount fails later after 20 secs waiting; Hm, here on my rpi3b+, with an attached usb disk I have to use this setting in loader.conf: kern.cam.boot_delay="15000" With the vfs.mountroot.timeout="xx" I end up in a shell because I'm not able to mount the partition in time. With the cam.boot_delay things are working fine. Maybe this helps? 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"
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
[Using ktrace/kdump shows an apperent oddity in the kevent use that
hang-up in cmake, not that I know it causes the hang-up.]
On 2018-Dec-28, at 00:16, Mark Millard wrote:
> [The historical notes are removed and replaced by partial trace
> information from example hang-ups, not that I've figured out
> what contributes yet.]
>
> I ran into the following while trying to get evidence
> about the hang-up for an amd64->armv7 cross-build of
> multimedia/gstreamer1-qt@qt5 .
>
> The following from trying to get evidence for the hang-up
> via a manual run of "make multimedia/gstreamer1-qt FLAVOR=qt5”
> in a poudriere bulk -i’s interactive mode for the context
> that has the hang-up in normal poudriere-devel runs.
>
>
> From top after the hang-up (to identify some context):
>
> 14528 root 2 520 100M24M0 kqread 11 0:00 0.00%
> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
> 14527 root 2 52088M13M0 select 22 0:00 0.00%
> /usr/local/bin/qemu-arm-static ninja -j1 -v all
>
> from ps -auxd as well (to identify more context):
>
> root 101140.0 0.0 10328 1756 1 I+J 13:47 0:00.01 |
>`-- make FLAVOR=qt5
> root 145260.0 0.0 10204 1792 1 I+J 13:50 0:00.00 |
> `-- /bin/sh -e -c (cd
> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
> /usr/bin/env QT_SELE
> root 145270.0 0.0 90304 13084 1 I+J 13:50 0:00.09 |
>`-- /usr/local/bin/qemu-arm-static ninja -j1 -v all
> root 145280.0 0.0 102876 25060 1 IJ 13:50 0:00.12 |
> `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E
> cmake_autogen /wrkdirs/usr/ports/multimedia/g
>
> I had made a qemu-user-static that enabled do_strace when
> it is used to run cmake or ninja.
>
> The only do_strace lines from qemu-arm-static running cmake
> or ninja mentioning process 14528 are included in the sequence:
>
> (Before the below was a long list of "14527 fstatat” lines.
> I’ll note that "'Unknown syscall 545” is from ppoll use.)
>
> 82400 sigprocmask(1,-1610620016,-191968524,-186261416,0,24) = 0
> 82400 sigaction(2,-1610620040,-191968596,-186261584,210460,0) = 0
> 82400 sigaction(15,-1610620040,-191968572,-186261584,210460,0) = 0
> 82400 sigaction(1,-1610620040,-191968548,-186261584,210460,0) = 0
> 82400 gettimeofday(-1610619984,0,4,-186261584,-1610619440,-1610619528) = 0
> 82400 gettimeofday(-1610619984,0,4,359949,1545969996,0) = 0
> 82400 gettimeofday(-1610620120,0,4,2,-184666112,-1610619520) = 0
> 82400 fstatat(-100,"elements/gstqtvideosink/CMakeFiles", 0x9fffe200, 0) = 0
> 82400 fstatat(-100,"elements/gstqtvideosink/gstqt5videosink_autogen",
> 0x9fffe200, 0) = 0
> 82400 pipe2(-1610620176,0,-1610620108,0,-1610620120,167084) = 0
> 82400 fcntl(5,1,-1610620108,-185863932,-192200556,-1610620228) = 0
> 82400 fcntl(5,2,1,-185863932,-192200556,-1610620228) = 0
> 82400 vfork(0,66450,-186876196,-1610620184,-1610620240,0) = 82401
> 82400 close(6) = 0
> = 0
> 82400 Unknown syscall 545
> 82401 setpgid(0,0,-186876196,-1610620184,-1610620240,0) = 0
> 82401 sigprocmask(3,-191586912,0,-1610620184,-1610620240,0) = 0
> 82401 close(5) = 0
> 82401 open("/dev/null",0,0) = 5
> 82401 dup2(5,0,0,-1610620184,-1610620240,0) = 0
> 82401 close(5) = 0
> 82401 fcntl(0,2,0,-1610620184,-1610620240,0) = 0
> 82401 dup2(6,1,0,-1610620184,-1610620240,0) = 1
> 82401 fcntl(1,2,0,-1610620184,-1610620240,0) = 0
> 82401 dup2(6,2,0,-1610620184,-1610620240,0)82400
> sigpending(-1610620072,1,0,-191968524,0,0) = 0
>
> The vfork then close(6) sequence for 82400 vs. the later
> use of 6 in dup2 in 82401 may be rather odd. But it looks
> like qemu-*-static uses do_freebsd_fork to implement
> do_freebsd_vfork, despite reporting vfork before
> calling do_freebsd_vfork. (Does the close(6) appear to
> indicate a race for native operation of ninja for the
> period when the address space is shared?)
>
> Ninja has Subprocess::Start code that has:
>
> #ifdef POSIX_SPAWN_USEVFORK
> flags |= POSIX_SPAWN_USEVFORK;
> #endif
>
>
> if (posix_spawnattr_setflags(&attr, flags) != 0)
>Fatal("posix_spawnattr_setflags: %s", strerror(errno));
>
> const char* spawned_args[] = { "/bin/sh", "-c", command.c_str(), NULL };
> if (posix_spawn(&pid_, "/bin/sh", &action, &attr,
> const_cast(spawned_args), environ) != 0)
>Fatal("posix_spawn: %s", strerror(errno));
>
> that is in use here. I think that this explains the vfork use.
>
>
> It turns out that putting the hung-up build in the background
> and then killing 82401 with the likes of kill -6 leads to more
> output that had apparently been buffered. It shows the use of
> the (amd64 native) /bin/sh that in turn leads to
> /usr/local/bin/cmake via qemu-arm-static. /bin/sh, being
> native, gets no do_strace output from qemu-arm-static.
>
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
In message , Antoine Brodin writes: > On Fri, Dec 28, 2018 at 8:39 PM Graham Perrin wrote: > > > > On Fri, 28 Dec 2018 at 16:31, Emiel Kollof wrot > e: > > > > > Confirmed with Chromium on my CURRENT box: > > > > ⦠> > > > Thanks folks. Should I report it as a bug with devel/glib20? > > Hi, > > I think it's a regression in the toolchain (the problem doesn't occur > on 11.2 or 12.0), so it should be reported to freebsd-toolchain@ No issue here however I rebuilt glib on Dec 21. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
On 2018-Dec-28, at 05:13, Michal Meloun wrote:
> Mark,
> this is known problem with qemu-user-static.
> Emulation of every single interruptible syscall is broken by design (it
> have signal related races). Theses races cannot be solved without major
> rewrite of syscall emulation code.
> Unfortunately, nobody actively works on this, I think.
>
Thanks for the note setting some expectations.
On the evidence that I have I expect that more is going on than that:
A) The hang-up always happens and always in the same place. So
it would appear that no race is involved.
B) (A) is true even for varying the number of builders in parallel
(so other builds also happening) and the number of jobs allowed per
builder. It also fails for only one builder allowed only one process.
(I get traces from that last kind of context.)
C) The problem started on the package-building servers for armv7
and armv6 without qemu-user-static having an update (FreeBSD and
cmake had updates, for example).
D) The problem is only observed for targeting armv7 and armv6 as
far as I can tell. I've never seen it for aarch64, neither my
own builds nor when I looked at the package-building server
history.
At least that is what got me started. (I've since learned that
qemu-user-static uses fork in place of a requested vfork.)
My ktrace/kdump experiment yesterday showed something odd for the
kevent that hangs in cmake:
93172 qemu-arm-static CALL
kevent(0x3,0x7ffe7d40,0x2,0x7ffd7d40,0x400,0)
93172 qemu-arm-static STRU struct kevent[] = { { ident=6, filter=EVFILT_READ,
flags=0x1, fflags=0, data=0, udata=0x0 }
{ ident=0x0, filter=, flags=0, fflags=0x8,
data=0x1, udata=0x0 } }
Note the 0x2 argument to kevent and the apparently-odd 2nd entry in the struct
kevent[]. The kevent use is from cmake.
So far I've not identified a signal being delivered at a time that would seem
to me to be likely to contribute. (But this is not familiar code so my judgment
is likely not the best.)
Note: I normally run FreeBSD using a non-debug kernel, even when using
head. (The kernel does have symbols.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
On Fri, Dec 28, 2018 at 8:39 PM Graham Perrin wrote: > > On Fri, 28 Dec 2018 at 16:31, Emiel Kollof wrote: > > > Confirmed with Chromium on my CURRENT box: > > … > > Thanks folks. Should I report it as a bug with devel/glib20? Hi, I think it's a regression in the toolchain (the problem doesn't occur on 11.2 or 12.0), so it should be reported to freebsd-toolchain@ Antoine ___ 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: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
On Fri, 28 Dec 2018 at 16:31, Emiel Kollof wrote: > Confirmed with Chromium on my CURRENT box: … Thanks folks. Should I report it as a bug with devel/glib20? https://www.freshports.org/devel/glib20 ___ 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: r342378 fails sometimes on boot mounting root (error 2)
El día viernes, diciembre 28, 2018 a las 09:07:49a. m. -0700, Ian Lepore escribió: > Try setting vfs.mountroot.timeout= in loader.conf to a value long > enough to let the usb drive get probed reliably. The default is 3 > seconds, maybe a value like 5 or 10 would work better for you. > > -- Ian Thanks. I did so, but this does not help. When I does not work even after 20 secs it fails to mount. After a lot of boot attempts I have the following picture: 1. It always mounts fine when verbose message is selected. 2. It mounts fine when the line below about 'umass0:1:0: Attached to ... ' is printed, if it is not, the mount fails later after 20 secs waiting; here is a working boot: ... uhub1: 2 ports with 2 removable, self powered uhub0: 13 ports with 13 removable, self powered ugen0.2: at usbus0 ugen0.3: at usbus0 ugen0.4: at usbus0 umass0 on uhub0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8000 umass0:1:0: Attached to scbus1 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number C196530955 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) ada0: Command Queueing enabled ada0: 244198MB (500118192 512 byte sectors) GEOM: new disk ada0 pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ACS-2 ATA SATA 3.x device pass0: Serial Number C196530955 pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) pass0: Command Queueing enabled pass1 at umass-sim0 bus 0 scbus1 target 0 lun 0 pass1: Fixed Direct Access SPC-4 SCSI device pass1: Serial Number 575854314134383033483150 pass1: 40.000MB/s transfers pass2 at umass-sim0 bus 0 scbus1 target 0 lun 1 da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number 575854314134383033483150 da0: 40.000MB/s transfers da0: 953837MB (1953458176 512 byte sectors) da0: quirks=0x2 pass2: Fixed Enclosure Services SPC-4 SCSI device pass2: Serial Number 575854314134383033483150 pass2: 40.000MB/s transfers ses0 at umass-sim0 bus 0 scbus1 target 0 lun 1 ses0: Fixed Enclosure Services SPC-4 SCSI device ses0: Serial Number 575854314134383033483150 ses0: 40.000MB/s transfers ses0: SCSI-3 ENC Device GEOM: new disk da0 da0: Delete methods: WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/gpt/extrootfs [rw,noatime]... atrtc0: providing initial system time start_init: trying /sbin/init ... -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ 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: efibootmgr: Cannot translate unix loader path xxx\xxx\xxx to UEFI: No error: 0
On Fri, Dec 28, 2018, 5:45 AM O. Hartmann On Thu, 27 Dec 2018 08:38:20 -0700 > Warner Losh wrote: > > > On Dec 27, 2018 7:42 AM, "O. Hartmann" wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Am Thu, 27 Dec 2018 13:29:44 +0100 > > "Hartmann, O." schrieb: > > > > > > > Updated Fujitsu Celsius M740 to its lates UEFI firmware today. > > > After this update, the box won't boot FreeBSD 12-STABLE anymore! With > > > disabled CSM, the firmware doesn't recognise the boot SSD's freebsd-efi > > > partition for UEFI boot anymore - which was no problem before. > > > > > > When trying FreeBSD 13-CURRENT (USB image from 26.12.2018 as of the > > > snapshot site) I receive a malloc arena error when trying to set boot > > > vars via efibootmgr utility. So I tried the recent 12-STABLE snapshot > > > as of 26th December 2018, the same as CURRENT USB Image, and I receive > > > a weird error: > > > > > > efibootmgr -c -l /mnt/EFI/BOOT/BOOTX64.EFI -L FreeBSD > > > > > > efibootmgr: Cannot translate unix loader path > > > '\mnt\EFI\BOOT\BOOTX64.EFI' to UEFI: No error: 0 > > > > > > What the heck is that? > > > > > > What does this error mean? No error: 0? > > > > > > The box is unusable. > > > > > > > > > Kind regards, > > > > > > O. Hartmann > > > > > > > > > > > > > I found this PR, Bug 229191, from June, 2018: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229191 > > > > It seems the problem has not been fixed. Indeed did I mount the ESP > > via a GEOM label, /dev/gpt/efiboot0. > > > > > > There is some code that tries to cope, but I ran out of time before it > was > > bulletproof. You can use nda0p9:/path/in/fs instead. Assuming the esp is > > on /dev/nda0p9. > > > > Warner > [...] > > The workaround (alternative mounting) given in the mentioned PR solved the > problem. > > This is the second time I face crude problems with Fujitsu > hardware/firmware > and if I wouldn't solved a similar problem this summer for an Esprimo > Q956, the > problem would have cost me valuable time. So, my thinking is: couldn't > there be > a short paragraph in the handbook? > Until it's fixed, sure. Labels and mirrors are not as well supported as I'd like... knowing the device + path workaround is the way we should document in the meantime. Warner Warner > ___ 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: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
Confirmed with Chromium on my CURRENT box: [ekollof@elrond /usr/home/ekollof]$ uname -a FreeBSD elrond 13.0-CURRENT FreeBSD 13.0-CURRENT r342278 GENERIC-NODEBUG amd64 [ekollof@elrond /usr/home/ekollof]$ chrome ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" Graham Perrin schreef op 2018-12-26 11:20: grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v Wed Dec 26 10:18:52 GMT 2018 FreeBSD 13.0-CURRENT r342466 GENERIC-NODEBUG grahamperrin@momh167-gjp4-8570p:~ % iridium ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' iridium-browser www/iridium 2018.5.67_6 FreeBSD grahamperrin@momh167-gjp4-8570p:~ % Any ideas? TIA ___ 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: r342378 fails sometimes on boot mounting root (error 2)
On Fri, 2018-12-28 at 15:54 +0100, Matthias Apitz wrote: > Hello, > > I've setup a new r342378 (December 23) for amd64 onto an external > disk > with this procedure: > > # grep da0 /var/log/messages > ... > Dec 28 14:20:01 c720-r314251 kernel: da0 at umass-sim0 bus 0 scbus1 > target 0 lun 0 > Dec 28 14:20:01 c720-r314251 kernel: da0: > Fixed Direct Access SPC-4 SCSI device > Dec 28 14:20:01 c720-r314251 kernel: da0: Serial Number > 575854314134383033483150 > Dec 28 14:20:01 c720-r314251 kernel: da0: 400.000MB/s transfers > Dec 28 14:20:01 c720-r314251 kernel: da0: 953837MB (1953458176 512 > byte sectors) > Dec 28 14:20:01 c720-r314251 kernel: da0: quirks=0x2 > > > # gpart destroy -F da0 > da0 destroyed > # gpart create -s gpt da0 > da0 created > # gpart add -t freebsd-boot -s 512k -a4k -l extboot da0 > da0p1 added > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 da0 > partcode written to da0p1 > bootcode written to da0 > # gpart add -t freebsd-ufs -l extrootfs -b 1m -s 256g da0 > da0p2 added > # gpart add -t freebsd-swap -l extswap -a 1m -s 2g da0 > da0p3 added > # gpart add -t freebsd-ufs -l extbackupfs -a 1m da0 > da0p4 added > > # newfs -U /dev/gpt/extrootfs > # newfs -U /dev/gpt/extbackupfs > > # gpart set -a active da0 > active set on da0 > # gpart show -l da0 > =>40 1953458096 da0 GPT (931G) > 4010241 extboot (512K) > 1064 984 - free - (492K) > 2048 5368709122 extrootfs (256G) > 536872960 41943043 extswap (2.0G) > 541067264 14123888644 extbackupfs (673G) > 19534561282008 - free - (1.0M) > > > # mount /dev/gpt/extrootfs /mnt > > # cd /usr/src > # make installworld DESTDIR=/mnt > # make installkernel DESTDIR=/mnt > # make distrib-dirs DESTDIR=/mnt > # make distribution DESTDIR=/mnt > > # cd ~guru/C720 > > # cp -p rc.conf /mnt/etc > # cp -p c720.kbd/mnt/etc > # cp -p sysctl.conf /mnt/etc > # cp -p loader.conf /mnt/boot/ > # cp -p device.hints/mnt/boot/ > > # cat > /mnt/etc/fstab < /dev/gpt/extrootfs / ufs rw,noatime 1 1 > /dev/gpt/extswap none swap sw 0 0 > EOF > > # chroot /mnt passwd root > Changing local password for root > New Password: > > # umount /mnt > > The disk now boots sometimes fine, more times it fails with: > > Trying to mount root from ufs:/dev/gpt/extroot [rw, noatime]... > Mounting from ufs:/dev/gpt/extroot failed with error 2; retrying fpr > 3 seconds > Mounting from ufs:/dev/gpt/extroot failed with error 2; retrying fpr > 2 seconds > Mounting from ufs:/dev/gpt/extroot failed with error 2; retrying fpr > 1 seconds > ... > > I can provide a 'dmesg' output from an successful boot, if this > helps. > > Any hints? Thanks > > matthias > Try setting vfs.mountroot.timeout= in loader.conf to a value long enough to let the usb drive get probed reliably. The default is 3 seconds, maybe a value like 5 or 10 would work better for you. -- 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"
r342378 fails sometimes on boot mounting root (error 2)
Hello, I've setup a new r342378 (December 23) for amd64 onto an external disk with this procedure: # grep da0 /var/log/messages ... Dec 28 14:20:01 c720-r314251 kernel: da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 Dec 28 14:20:01 c720-r314251 kernel: da0: Fixed Direct Access SPC-4 SCSI device Dec 28 14:20:01 c720-r314251 kernel: da0: Serial Number 575854314134383033483150 Dec 28 14:20:01 c720-r314251 kernel: da0: 400.000MB/s transfers Dec 28 14:20:01 c720-r314251 kernel: da0: 953837MB (1953458176 512 byte sectors) Dec 28 14:20:01 c720-r314251 kernel: da0: quirks=0x2 # gpart destroy -F da0 da0 destroyed # gpart create -s gpt da0 da0 created # gpart add -t freebsd-boot -s 512k -a4k -l extboot da0 da0p1 added # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 da0 partcode written to da0p1 bootcode written to da0 # gpart add -t freebsd-ufs -l extrootfs -b 1m -s 256g da0 da0p2 added # gpart add -t freebsd-swap -l extswap -a 1m -s 2g da0 da0p3 added # gpart add -t freebsd-ufs -l extbackupfs -a 1m da0 da0p4 added # newfs -U /dev/gpt/extrootfs # newfs -U /dev/gpt/extbackupfs # gpart set -a active da0 active set on da0 # gpart show -l da0 =>40 1953458096 da0 GPT (931G) 4010241 extboot (512K) 1064 984 - free - (492K) 2048 5368709122 extrootfs (256G) 536872960 41943043 extswap (2.0G) 541067264 14123888644 extbackupfs (673G) 19534561282008 - free - (1.0M) # mount /dev/gpt/extrootfs /mnt # cd /usr/src # make installworld DESTDIR=/mnt # make installkernel DESTDIR=/mnt # make distrib-dirs DESTDIR=/mnt # make distribution DESTDIR=/mnt # cd ~guru/C720 # cp -p rc.conf /mnt/etc # cp -p c720.kbd/mnt/etc # cp -p sysctl.conf /mnt/etc # cp -p loader.conf /mnt/boot/ # cp -p device.hints/mnt/boot/ # cat > /mnt/etc/fstab
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
On 24.12.2018 8:28, Mark Millard wrote:
> [I built a FreeBSD head -r340288 context and tried ports head
> -r484783 and the problem repeated.]
>
> On 2018-Dec-22, at 12:55, Mark Millard wrote:
>
>> [I found my E-mail records reporting successful builds using
>> qemu-user-static from ports head -r484783 under FreeBSD
>> head -r340287.]
>>
>> On 2018-Dec-22, at 00:10, Mark Millard wrote:
>>
>>> [I messed up the freebsd-emulation email address the first time I sent
>>> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>>>
>>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7}
>>> port cross
>>> builds in another message sequence. But it turns out that one thing I ran
>>> into
>>> has hung-up every time, the same way, for amd64->armv7 cross builds:
>>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a
>>> separate report
>>> with some updated notes.
>>>
>>> A little context: I had built from ports head -r484783 before under FreeBSD
>>> head
>>> -r340287 (as I remember the version). Back then it did not have this
>>> problem that it
>>> now has under FreeBSD head -r341836 . One ports-specific change was to
>>> force perl5.28
>>> as the default instead of perl5.26 originally. In fact this is what drives
>>> what is
>>> being rebuilt for my experiment that caught this. But I doubt the perl
>>> version is
>>> important to the problem. The context has a Ryzen Threadripper 1950X and
>>> has been
>>> tested both for FreeBSD under Hyper-V and for the same media native-booted.
>>> Both
>>> hang-up at the same point as seen via ps or top. The native tools for
>>> cross-build
>>> speedup were in use. Cross-builds targeting aarch64 did not get this
>>> problem but
>>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for
>>> the first
>>> armv7 try.
>>>
>>> ADDED: The qemu-user-static back with head -r340287 before installing the
>>> updated ports would likely be different than the -r484783 vintage. So both
>>> FreeBSD and qemu-user-static may have changed over the comparison.
>>
>> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
>> based on qemu-user-static from ports head -484783 --all built under FreeBSD
>> head -r340287 . So the use of the perl5.28 as the forced-default and the
>> newer FreeBSD head version -r341836 as the context are the differences here.
>>
>>> The hang-up:
>>>
>>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up
>>> and timed
>>> out. Looking during the wait in later tries shows something much like (from
>>> one of the
>>> examples):
>>>
>>> root 337190.0 0.0 12920 3528 0 I11:40 0:00.03 | |
>>> `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root 415510.0 0.0 12920 3520 0 I11:43 0:00.00 | |
>>>`-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root 415520.0 0.0 10340 1744 0 IJ 11:43 0:00.01 | |
>>> `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt
>>> FLAVOR=qt5 build
>>> root 415660.0 0.0 10236 1796 0 IJ 11:43 0:00.00 | |
>>>`-- /bin/sh -e -c (cd
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>>> /usr/bin/env QT_SELE
>>> root 415670.0 0.0 89976 12896 0 IJ 11:43 0:00.07 | |
>>> `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> root 415850.0 0.0 102848 25056 0 IJ 11:43 0:00.10 | |
>>>|-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>> root 415860.0 0.0 102852 25072 0 IJ 11:43 0:00.11 | |
>>>`-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>>
>>> or as top showed it:
>>>
>>> 41552 root 1 52010M 1744K0 wait15 0:00 0.00%
>>> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
>>> 41566 root 1 52010M 1796K0 wait 1 0:00 0.00%
>>> /bin/sh -e -c (cd
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
>>> 41567 root 2 52088M13M0 select 4 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> 41585 root 2 520 100M24M0 kqread 8 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>> 41586 root 2 520 100M24M0 kqread 22 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>>
>>> So: waitin
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
On 24.12.2018 8:28, Mark Millard wrote:
> [I built a FreeBSD head -r340288 context and tried ports head
> -r484783 and the problem repeated.]
>
> On 2018-Dec-22, at 12:55, Mark Millard wrote:
>
>> [I found my E-mail records reporting successful builds using
>> qemu-user-static from ports head -r484783 under FreeBSD
>> head -r340287.]
>>
>> On 2018-Dec-22, at 00:10, Mark Millard wrote:
>>
>>> [I messed up the freebsd-emulation email address the first time I sent
>>> this. I also forgot to indicate the qemu-user-static vintage relationship.]
>>>
>>> I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7}
>>> port cross
>>> builds in another message sequence. But it turns out that one thing I ran
>>> into
>>> has hung-up every time, the same way, for amd64->armv7 cross builds:
>>> multimedia/gstreamer1-qt@qt5 . So I extract the material here into a
>>> separate report
>>> with some updated notes.
>>>
>>> A little context: I had built from ports head -r484783 before under FreeBSD
>>> head
>>> -r340287 (as I remember the version). Back then it did not have this
>>> problem that it
>>> now has under FreeBSD head -r341836 . One ports-specific change was to
>>> force perl5.28
>>> as the default instead of perl5.26 originally. In fact this is what drives
>>> what is
>>> being rebuilt for my experiment that caught this. But I doubt the perl
>>> version is
>>> important to the problem. The context has a Ryzen Threadripper 1950X and
>>> has been
>>> tested both for FreeBSD under Hyper-V and for the same media native-booted.
>>> Both
>>> hang-up at the same point as seen via ps or top. The native tools for
>>> cross-build
>>> speedup were in use. Cross-builds targeting aarch64 did not get this
>>> problem but
>>> targeting armv7 did. 121 of 129 armv7 ports built before the hang-up for
>>> the first
>>> armv7 try.
>>>
>>> ADDED: The qemu-user-static back with head -r340287 before installing the
>>> updated ports would likely be different than the -r484783 vintage. So both
>>> FreeBSD and qemu-user-static may have changed over the comparison.
>>
>> CORRECTION to ADDED: Back on 2018-Nov-11 I reported successful cross-builds
>> based on qemu-user-static from ports head -484783 --all built under FreeBSD
>> head -r340287 . So the use of the perl5.28 as the forced-default and the
>> newer FreeBSD head version -r341836 as the context are the differences here.
>>
>>> The hang-up:
>>>
>>> In the port rebuilds targeting armv7, multimedia/gstreamer1-qt@qt5 hung-up
>>> and timed
>>> out. Looking during the wait in later tries shows something much like (from
>>> one of the
>>> examples):
>>>
>>> root 337190.0 0.0 12920 3528 0 I11:40 0:00.03 | |
>>> `-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root 415510.0 0.0 12920 3520 0 I11:43 0:00.00 | |
>>>`-- sh: poudriere[FBSDFSSDjailArmV7-default][02]: build_pkg
>>> (gstreamer1-qt5-1.2.0_14) (sh)
>>> root 415520.0 0.0 10340 1744 0 IJ 11:43 0:00.01 | |
>>> `-- /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt
>>> FLAVOR=qt5 build
>>> root 415660.0 0.0 10236 1796 0 IJ 11:43 0:00.00 | |
>>>`-- /bin/sh -e -c (cd
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>>> /usr/bin/env QT_SELE
>>> root 415670.0 0.0 89976 12896 0 IJ 11:43 0:00.07 | |
>>> `-- /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> root 415850.0 0.0 102848 25056 0 IJ 11:43 0:00.10 | |
>>>|-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>> root 415860.0 0.0 102852 25072 0 IJ 11:43 0:00.11 | |
>>>`-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake
>>> -E cmake_autogen /wrkdirs/usr/ports/multimedia/g
>>>
>>> or as top showed it:
>>>
>>> 41552 root 1 52010M 1744K0 wait15 0:00 0.00%
>>> /usr/bin/make -C /usr/ports/multimedia/gstreamer1-qt FLAVOR=qt5 build
>>> 41566 root 1 52010M 1796K0 wait 1 0:00 0.00%
>>> /bin/sh -e -c (cd
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if !
>>> /usr/bin/env QT_SELECT=qt5 QMAKEMODULES
>>> 41567 root 2 52088M13M0 select 4 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static ninja -j28 -v all
>>> 41585 root 2 520 100M24M0 kqread 8 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>> 41586 root 2 520 100M24M0 kqread 22 0:00 0.00%
>>> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
>>> /wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
>>>
>>> So: waitin
Re: /usr/src/lib/clang/libclang 'emmintrin.h' file not found
Dimitry Andric wrote: > On 28 Dec 2018, at 12:38, Julian H. Stacey wrote: > >=20 > > "Julian H. Stacey" wrote: > >> Enji Cooper wrote: > On Dec 27, 2018, at 3:48 AM, Julian H. Stacey = > wrote: > Hi current@ > Anyone else seeing make buildworld Clang failures ? > ls -l /usr/bin suggests I last made world on Dec 9, > since then I've failed twice below > Seems the UPDATING doesnt give enough to rescue this. > --- > =3D20 > cd /usr/src > cat .ctm_status # I recall src-cur 13840 > make world > ... failed approx or maybe as below I recall: > =3D20 > cat .svn_revision # 342545 > cat .ctm_status # src-cur 13841 > make buildworld > =3D20 > c++ -O2 -pipe -DBERKLIX=3D3DYES =3D > >>> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang =3D > >>> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm =3D > >>> -I/usr/src/contrib/llvm/tools/clang/lib/Basic =3D > >>> -I/usr/src/contrib/llvm/tools/clang/lib/Driver =3D > >>> -I/usr/src/contrib/llvm/tools/clang/include = > -I/usr/src/lib/clang/include =3D > >>> -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL =3D > >>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS =3D > >>> -DLLVM_DEFAULT_TARGET_TRIPLE=3D3D\"x86_64-unknown-freebsd13.0\" =3D > >>> -DLLVM_HOST_TRIPLE=3D3D\"x86_64-unknown-freebsd13.0\" =3D > >>> -DDEFAULT_SYSROOT=3D3D\"/usr/obj/usr/src/amd64.amd64/tmp\" =3D > >>> -DLLVM_TARGET_ENABLE_X86 =3D > >>> -DLLVM_NATIVE_ASMPARSER=3D3DLLVMInitializeX86AsmParser =3D > >>> -DLLVM_NATIVE_ASMPRINTER=3D3DLLVMInitializeX86AsmPrinter =3D > >>> -DLLVM_NATIVE_DISASSEMBLER=3D3DLLVMInitializeX86Disassembler =3D > >>> -DLLVM_NATIVE_TARGET=3D3DLLVMInitializeX86Target =3D > >>> -DLLVM_NATIVE_TARGETINFO=3D3DLLVMInitializeX86TargetInfo =3D > >>> -DLLVM_NATIVE_TARGETMC=3D3DLLVMInitializeX86TargetMC = > -ffunction-sections =3D > >>> -fdata-sections -gline-tables-only -MD -MF.de! > pend.Basic_SourceManager.o -MTBasic/SourceManager.o = > -Qunused-arguments =3D > >>> -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=3D3Dc++11 = > =3D > >>> -fno-exceptions -fno-rtti -gline-tables-only -stdlib=3D3Dlibc++ =3D > >>> -Wno-c++11-extensions -c =3D > >>> /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp -o =3D > >>> Basic/SourceManager.o > = > /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1196:10: =3D= > > >>> fatal error: > 'emmintrin.h' file not found > #include > ^ > 1 error generated. > *** Error code 1 > =3D20 > Stop. > bmake[4]: stopped in /usr/src/lib/clang/libclang > > Most likely, your host compiler is missing required intrinsics headers. > These are located under /usr/lib/clang/x.y.z/include, where x.y.z is the > compiler version. If they are missing, you might want to restore the > files from backup, or extract them from a release or snapshot tarball. > > -Dimitry Thanks Dimitry clang -v FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: x86_64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin cd /usr/lib/clang ; ls 7.0.1/ dmesg FreeBSD 13.0-CURRENT JHS_Lapr amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) So my current box has a mismatch. My other current box is normaly older, so I turned on to copy 6.0.1 libs & found a newer & consistent current: clang -v FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) Target: x86_64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin dmesg: FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) cd /usr/bin; ls -l Dec 20 So I'm checking the newer current box with make all, then will do a cross host recovery to the inconsistent older box. Thanks Enji & Dimitry Cheers, Julian -- Julian Stacey, Computer Consultant Sys.Eng. BSD Linux Unix, Munich Aachen Kent First referendum stole 700,000 votes from Brits in EU; 3,700,000 globaly. Lies criminal funded; jobs pound & markets down. 1.9M new voters 1.3M dead. Email MP: "A new referendum will buy UK & EU more time (Art 50.3), to avoid a hard crash, & consider all options." http://berklix.org/brexit/#mp ___ 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: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
On 27.12.2018 14:07, Gary Jennejohn wrote:
> On Thu, 27 Dec 2018 03:58:51 -0800
> Enji Cooper wrote:
>
>>> On Dec 27, 2018, at 2:17 AM, Trev wrote:
>>>
>>> Graham Perrin wrote on 26/12/2018 21:20:
grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Wed Dec 26 10:18:52 GMT 2018
FreeBSD 13.0-CURRENT r342466 GENERIC-NODEBUG
grahamperrin@momh167-gjp4-8570p:~ % iridium
ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' iridium-browser
www/iridium 2018.5.67_6 FreeBSD
grahamperrin@momh167-gjp4-8570p:~ %
Any ideas?
TIA
>>>
>>> Same problem with a freshly compiled (after 5 days, finished yesterday)
>>> www/chromium on RPi3.
>>>
>>> $ chrome
>>> ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
>>>
>>> $ uname -a
>>> FreeBSD rpi3.sentry.org 13.0-CURRENT FreeBSD 13.0-CURRENT r342189 RPI3
>>> arm64
>>
>> Hmm___ is something wonky with recent changes to rtld-elf that might be
>> impacting ARM64?
>>
>> CCing mmel@, because they might be interested in these bug reports.
>>
>
> No. I saw this with mplayer and also iridium when I installed them
> with pkg on AMD64.
>
>
> Strangely enough, mpv works, even though it shows a dependency on
> libglib-2.0.so.0 when I run ldd on it.
>
> glib-2 has "extern char **environ;" in one of its C-files.
>
I cannot talk about iridium (its i386/amd64 only and I don't want to
infect my headless build box with tons of X11 libraries).
But for multimedia/mplayer, I can say that this problem is caused by
mplayer itself.
The 'environ' is defined as global symbol in /usr/lib/crt1.o:
>readelf -s /usr/lib/crt1.o | grep environ
46: 0008 8 OBJECT GLOBAL DEFAULT COM environ
These startup objects (/usr/lib/crt*.o) are linked to each single
executable (but not to shared libraries). That means that any
dynamically linked executable exports 'environ' symbol (and many, many
others) with globally visibility.
>readelf -s /bin/ls | grep environ
78: 0024 8 OBJECT GLOBAL DEFAULT 22 environ
Because these symbols are globally visible, glib20 (and/or other
libraries) can use them.
Unfortunately, when mplayer binary gets linked, makefile uses symbol
version script '-Wl,--version-script,binary.ver' as part of link
command. And this script explicitly lowers visibility of *all* symbols
(but _IO_stdin_used) to local.
>more binary.ver
MPLAYER_1 {
# to support glibcs abhorrent backwards-compatibility hack
global: _IO_stdin_used;
local: *;
};
>readelf -s mplayer | grep environ
26: 0050 8 OBJECT LOCAL DEFAULT 24 environ
Of course, local symbols are visible only within originating object,
these are invisible for other objects.
I have no idea why mplayer authors uses this script, mainly why version
script is used for *main executable*.
>From my point of view, it's nothing but pure nonsense. This script hides
symbols provided by startup object files so resulting binary is (and
must be) invalid.
I hope that this short description is enough for maintainer to fix these.
Michal
___
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: /usr/src/lib/clang/libclang 'emmintrin.h' file not found
On 28 Dec 2018, at 12:38, Julian H. Stacey wrote: > > "Julian H. Stacey" wrote: >> Enji Cooper wrote: On Dec 27, 2018, at 3:48 AM, Julian H. Stacey wrote: Hi current@ Anyone else seeing make buildworld Clang failures ? ls -l /usr/bin suggests I last made world on Dec 9, since then I've failed twice below Seems the UPDATING doesnt give enough to rescue this. --- =20 cd /usr/src cat .ctm_status # I recall src-cur 13840 make world ... failed approx or maybe as below I recall: =20 cat .svn_revision # 342545 cat .ctm_status # src-cur 13841 make buildworld =20 c++ -O2 -pipe -DBERKLIX=3DYES = >>> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang = >>> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm = >>> -I/usr/src/contrib/llvm/tools/clang/lib/Basic = >>> -I/usr/src/contrib/llvm/tools/clang/lib/Driver = >>> -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include = >>> -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL = >>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS = >>> -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd13.0\" = >>> -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd13.0\" = >>> -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/src/amd64.amd64/tmp\" = >>> -DLLVM_TARGET_ENABLE_X86 = >>> -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeX86AsmParser = >>> -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeX86AsmPrinter = >>> -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeX86Disassembler = >>> -DLLVM_NATIVE_TARGET=3DLLVMInitializeX86Target = >>> -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeX86TargetInfo = >>> -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeX86TargetMC -ffunction-sections = >>> -fdata-sections -gline-tables-only -MD -MF.de! pend.Basic_SourceManager.o -MTBasic/SourceManager.o -Qunused-arguments = >>> -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=3Dc++11 = >>> -fno-exceptions -fno-rtti -gline-tables-only -stdlib=3Dlibc++ = >>> -Wno-c++11-extensions -c = >>> /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp -o = >>> Basic/SourceManager.o /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1196:10: = >>> fatal error: 'emmintrin.h' file not found #include ^ 1 error generated. *** Error code 1 =20 Stop. bmake[4]: stopped in /usr/src/lib/clang/libclang Most likely, your host compiler is missing required intrinsics headers. These are located under /usr/lib/clang/x.y.z/include, where x.y.z is the compiler version. If they are missing, you might want to restore the files from backup, or extract them from a release or snapshot tarball. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: /usr/src/lib/clang/libclang 'emmintrin.h' file not found
"Julian H. Stacey" wrote:
> Enji Cooper wrote:
> > > On Dec 27, 2018, at 3:48 AM, Julian H. Stacey wrote:
> > > Hi current@
> > > Anyone else seeing make buildworld Clang failures ?
> > > ls -l /usr/bin suggests I last made world on Dec 9,
> > > since then I've failed twice below
> > > Seems the UPDATING doesnt give enough to rescue this.
> > > ---
> > >=20
> > > cd /usr/src
> > > cat .ctm_status # I recall src-cur 13840
> > > make world
> > > ... failed approx or maybe as below I recall:
> > >=20
> > > cat .svn_revision # 342545
> > > cat .ctm_status # src-cur 13841
> > > make buildworld
> > >=20
> > > c++ -O2 -pipe -DBERKLIX=3DYES =
> > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang =
> > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm =
> > -I/usr/src/contrib/llvm/tools/clang/lib/Basic =
> > -I/usr/src/contrib/llvm/tools/clang/lib/Driver =
> > -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include =
> > -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL =
> > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS =
> > -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd13.0\" =
> > -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd13.0\" =
> > -DDEFAULT_SYSROOT=3D\"/usr/obj/usr/src/amd64.amd64/tmp\" =
> > -DLLVM_TARGET_ENABLE_X86 =
> > -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeX86AsmParser =
> > -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeX86AsmPrinter =
> > -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeX86Disassembler =
> > -DLLVM_NATIVE_TARGET=3DLLVMInitializeX86Target =
> > -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeX86TargetInfo =
> > -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeX86TargetMC -ffunction-sections =
> > -fdata-sections -gline-tables-only -MD -MF.de!
> > > pend.Basic_SourceManager.o -MTBasic/SourceManager.o -Qunused-arguments =
> > -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=3Dc++11 =
> > -fno-exceptions -fno-rtti -gline-tables-only -stdlib=3Dlibc++ =
> > -Wno-c++11-extensions -c =
> > /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp -o =
> > Basic/SourceManager.o
> > > /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1196:10: =
> > fatal error:
> > > 'emmintrin.h' file not found
> > > #include
> > > ^
> > > 1 error generated.
> > > *** Error code 1
> > >=20
> > > Stop.
> > > bmake[4]: stopped in /usr/src/lib/clang/libclang
> > > *** Error code 1
> > >=20
> > > src/UPDATING last has a note at 20181220 ... &
> > > 20181211:
> > >Clang, llvm, lld, lldb, compiler-rt and libc++ have been =
> > upgraded to
> > >7.0.1. Please see the 20141231 entry below for information =
> > about
> > >prerequisites and upgrading, if you are not already using clang =
> > 3.5.0
> > >or higher.
> > >=20
> > > clang -v
> > > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on =
> > LLVM 6.0.1)
> > >=20
> > > make includes
> > > mkdir -p /usr/lib/clang/7.0.1/include/sanitizer/
> > > make includes
> > > clang-tblgen -help
> > > make -i includes
> > > cd /usr/src/lib/clang/libclang
> > > make
> > > clang-tblgen -gen-clang-attr-dump -I =
> > /usr/src/contrib/llvm/tools/clang/include -d clang/AST/AttrDump.inc.d -o =
> > clang/AST/AttrDump.inc =
> > /usr/src/contrib/llvm/tools/clang/include/clang/Basic/Attr.td
> > > *** Signal 11
> > > reboot
> > > cd /usr/src/lib/clang/libclang
> > > make clean
> > > make
> > > clang-tblgen -gen-clang-attr-dump -I =
> > /usr/src/contrib/llvm/tools/clang/include -d clang/AST/AttrDump.inc.d -o =
> > clang/AST/AttrDump.inc =
> > /usr/src/contrib/llvm/tools/clang/include/clang/Basic/Attr.td
> > > *** Signal 11
> >
> > Hi Julian,
> > The handful of times I=E2=80=99ve seen this occur in the past =
> > with other compiler versions, it=E2=80=99s been caused by an incomplete =
> > buildworld and/or tainted .OBJDIR. It might be a good idea to wipe out =
> > ${OBJROOT} and start buildworld from scratch, to see if the issue =
> > persists.
> > Best of luck,
> > -Enji
>
> Thanks Enji,
> I usually do, but I might have forgotten,
> have now run:
> cd /usr/obj; rm -rf *
> cd /usr/src
> make clean
> make cleandir# prob un-necessary after obj rm
> cat .ctm_status src-cur 13842
> cat .svn_revision 342550
> & started:
> make buildworld
That failed again:
---
c++ -O2 -pipe -DBERKLIX=YES
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm
-I/usr/src/contrib/llvm/tools/clang/lib/Basic
-I/usr/src/contrib/llvm/tools/clang/lib/Driver
-I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\"
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86
-D
Re: efibootmgr: Cannot translate unix loader path xxx\xxx\xxx to UEFI: No error: 0
On Thu, 27 Dec 2018 08:38:20 -0700 Warner Losh wrote: > On Dec 27, 2018 7:42 AM, "O. Hartmann" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Am Thu, 27 Dec 2018 13:29:44 +0100 > "Hartmann, O." schrieb: > > > > Updated Fujitsu Celsius M740 to its lates UEFI firmware today. > > After this update, the box won't boot FreeBSD 12-STABLE anymore! With > > disabled CSM, the firmware doesn't recognise the boot SSD's freebsd-efi > > partition for UEFI boot anymore - which was no problem before. > > > > When trying FreeBSD 13-CURRENT (USB image from 26.12.2018 as of the > > snapshot site) I receive a malloc arena error when trying to set boot > > vars via efibootmgr utility. So I tried the recent 12-STABLE snapshot > > as of 26th December 2018, the same as CURRENT USB Image, and I receive > > a weird error: > > > > efibootmgr -c -l /mnt/EFI/BOOT/BOOTX64.EFI -L FreeBSD > > > > efibootmgr: Cannot translate unix loader path > > '\mnt\EFI\BOOT\BOOTX64.EFI' to UEFI: No error: 0 > > > > What the heck is that? > > > > What does this error mean? No error: 0? > > > > The box is unusable. > > > > > > Kind regards, > > > > O. Hartmann > > > > > > > > I found this PR, Bug 229191, from June, 2018: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229191 > > It seems the problem has not been fixed. Indeed did I mount the ESP > via a GEOM label, /dev/gpt/efiboot0. > > > There is some code that tries to cope, but I ran out of time before it was > bulletproof. You can use nda0p9:/path/in/fs instead. Assuming the esp is > on /dev/nda0p9. > > Warner [...] The workaround (alternative mounting) given in the mentioned PR solved the problem. This is the second time I face crude problems with Fujitsu hardware/firmware and if I wouldn't solved a similar problem this summer for an Esprimo Q956, the problem would have cost me valuable time. So, my thinking is: couldn't there be a short paragraph in the handbook? Regards, o.h. ___ 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: HEAD buildworld fails in libc
On Fri, Dec 28, 2018 at 10:18:12AM +0100, Gary Jennejohn wrote:
> I don't know why this hasn't already been reported, but I've been
> seeing this error since the commit was made.
>
> ===> lib/libc (obj,all,install)
> /usr/src/lib/libc/string/strerror.c:96:11: error: passing 'const char []' to
> parameter of type 'char *' discards qualifiers
> [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
> __uprefix,
> ^
> /usr/src/lib/libc/string/strerror.c:61:23: note: passing argument to
> parameter 'uprefix' here
> errstr(int num, char *uprefix, char *buf, size_t len)
> ^
> 1 error generated.
> *** [strerror.o] Error code 1
>
> I deleted /usr/obj, disabled META_MODE and ran the ``make buildworld''
> with -j1.
>
> My /usr/src is at r342569.
Do you have WITHOUT_NLS set ? If yes, then the following should fix it.
Confirm and I will commit.
diff --git a/lib/libc/string/strerror.c b/lib/libc/string/strerror.c
index be3732d5b9e..7cd984ea48f 100644
--- a/lib/libc/string/strerror.c
+++ b/lib/libc/string/strerror.c
@@ -58,7 +58,7 @@ __FBSDID("$FreeBSD$");
* statically linked binaries.
*/
static void
-errstr(int num, char *uprefix, char *buf, size_t len)
+errstr(int num, const char *uprefix, char *buf, size_t len)
{
char *t;
unsigned int uerr;
___
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"
HEAD buildworld fails in libc
I don't know why this hasn't already been reported, but I've been seeing this error since the commit was made. ===> lib/libc (obj,all,install) /usr/src/lib/libc/string/strerror.c:96:11: error: passing 'const char []' to parameter of type 'char *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] __uprefix, ^ /usr/src/lib/libc/string/strerror.c:61:23: note: passing argument to parameter 'uprefix' here errstr(int num, char *uprefix, char *buf, size_t len) ^ 1 error generated. *** [strerror.o] Error code 1 I deleted /usr/obj, disabled META_MODE and ran the ``make buildworld'' with -j1. My /usr/src is at r342569. -- Gary Jennejohn ___ 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: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved)
[The historical notes are removed and replaced by partial trace
information from example hang-ups, not that I've figured out
what contributes yet.]
I ran into the following while trying to get evidence
about the hang-up for an amd64->armv7 cross-build of
multimedia/gstreamer1-qt@qt5 .
The following from trying to get evidence for the hang-up
via a manual run of "make multimedia/gstreamer1-qt FLAVOR=qt5”
in a poudriere bulk -i’s interactive mode for the context
that has the hang-up in normal poudriere-devel runs.
From top after the hang-up (to identify some context):
14528 root 2 520 100M24M0 kqread 11 0:00 0.00%
/usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.
14527 root 2 52088M13M0 select 22 0:00 0.00%
/usr/local/bin/qemu-arm-static ninja -j1 -v all
from ps -auxd as well (to identify more context):
root 101140.0 0.0 10328 1756 1 I+J 13:47 0:00.01 |
`-- make FLAVOR=qt5
root 145260.0 0.0 10204 1792 1 I+J 13:50 0:00.00 |
`-- /bin/sh -e -c (cd
/wrkdirs/usr/ports/multimedia/gstreamer1-qt/work-qt5/.build; if ! /usr/bin/env
QT_SELE
root 145270.0 0.0 90304 13084 1 I+J 13:50 0:00.09 |
`-- /usr/local/bin/qemu-arm-static ninja -j1 -v all
root 145280.0 0.0 102876 25060 1 IJ 13:50 0:00.12 |
`-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E
cmake_autogen /wrkdirs/usr/ports/multimedia/g
I had made a qemu-user-static that enabled do_strace when
it is used to run cmake or ninja.
The only do_strace lines from qemu-arm-static running cmake
or ninja mentioning process 14528 are included in the sequence:
(Before the below was a long list of "14527 fstatat” lines.
I’ll note that "'Unknown syscall 545” is from ppoll use.)
82400 sigprocmask(1,-1610620016,-191968524,-186261416,0,24) = 0
82400 sigaction(2,-1610620040,-191968596,-186261584,210460,0) = 0
82400 sigaction(15,-1610620040,-191968572,-186261584,210460,0) = 0
82400 sigaction(1,-1610620040,-191968548,-186261584,210460,0) = 0
82400 gettimeofday(-1610619984,0,4,-186261584,-1610619440,-1610619528) = 0
82400 gettimeofday(-1610619984,0,4,359949,1545969996,0) = 0
82400 gettimeofday(-1610620120,0,4,2,-184666112,-1610619520) = 0
82400 fstatat(-100,"elements/gstqtvideosink/CMakeFiles", 0x9fffe200, 0) = 0
82400 fstatat(-100,"elements/gstqtvideosink/gstqt5videosink_autogen",
0x9fffe200, 0) = 0
82400 pipe2(-1610620176,0,-1610620108,0,-1610620120,167084) = 0
82400 fcntl(5,1,-1610620108,-185863932,-192200556,-1610620228) = 0
82400 fcntl(5,2,1,-185863932,-192200556,-1610620228) = 0
82400 vfork(0,66450,-186876196,-1610620184,-1610620240,0) = 82401
82400 close(6) = 0
= 0
82400 Unknown syscall 545
82401 setpgid(0,0,-186876196,-1610620184,-1610620240,0) = 0
82401 sigprocmask(3,-191586912,0,-1610620184,-1610620240,0) = 0
82401 close(5) = 0
82401 open("/dev/null",0,0) = 5
82401 dup2(5,0,0,-1610620184,-1610620240,0) = 0
82401 close(5) = 0
82401 fcntl(0,2,0,-1610620184,-1610620240,0) = 0
82401 dup2(6,1,0,-1610620184,-1610620240,0) = 1
82401 fcntl(1,2,0,-1610620184,-1610620240,0) = 0
82401 dup2(6,2,0,-1610620184,-1610620240,0)82400
sigpending(-1610620072,1,0,-191968524,0,0) = 0
The vfork then close(6) sequence for 82400 vs. the later
use of 6 in dup2 in 82401 may be rather odd. But it looks
like qemu-*-static uses do_freebsd_fork to implement
do_freebsd_vfork, despite reporting vfork before
calling do_freebsd_vfork. (Does the close(6) appear to
indicate a race for native operation of ninja for the
period when the address space is shared?)
Ninja has Subprocess::Start code that has:
#ifdef POSIX_SPAWN_USEVFORK
flags |= POSIX_SPAWN_USEVFORK;
#endif
if (posix_spawnattr_setflags(&attr, flags) != 0)
Fatal("posix_spawnattr_setflags: %s", strerror(errno));
const char* spawned_args[] = { "/bin/sh", "-c", command.c_str(), NULL };
if (posix_spawn(&pid_, "/bin/sh", &action, &attr,
const_cast(spawned_args), environ) != 0)
Fatal("posix_spawn: %s", strerror(errno));
that is in use here. I think that this explains the vfork use.
It turns out that putting the hung-up build in the background
and then killing 82401 with the likes of kill -6 leads to more
output that had apparently been buffered. It shows the use of
the (amd64 native) /bin/sh that in turn leads to
/usr/local/bin/cmake via qemu-arm-static. /bin/sh, being
native, gets no do_strace output from qemu-arm-static.
82400 sigpending(-1610620072,1,0,-191968524,0,0) = 0
82400 read(5,0x9fffd368,4096) = 58
82400 Unknown syscall 545
82400 sigpending(-1610620072,1,0,-191968524,0,0) = 0
82400 read(5,0x9fffd368,4096) = 0
82400 close(5) = 0
82400 wait4(82401,-1610620004,0,0,-191968640,0) = 82401
82400 mmap(0,86016,3,201330690,-1,-1610620169) = 0xf4777000
82400 gettimeofday(-1610620224,0,4,-161061994
