daily CVS update output
Updating src tree: P src/sbin/fsck_ffs/pass2.c P src/sys/dev/pci/if_vioif.c P src/sys/dev/pci/virtio.c P src/usr.bin/systat/disks.c P src/usr.bin/systat/vmstat.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 47538403 Mar 28 03:03 ls-lRA.gz
Re: error installing libiconv-1.17
> I think this is a bug, since it prevents a proper upgrade. Certainly it is. These bugs are not that rare. There is typically a link line to make a binary that needs libs that are part of the package and libs that are in pkgsrc (in dependencies). So it ends up being something that sort of is like this cc -o prog prog.o foo.o bar.o -L../libs -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -lproglib -lotherlib and that is probably ok but if the -L get tangled up in the wrong order because it's 10 times more complicated than that with multiple stages of substitution, you can see how it would go wrong. My guess is that these bugs are 90% upstream bugs. So if you can figure it out, and how to fix, and report upstream if that's where the bug is, that would be helpful. But it's hard.
Re: error installing libiconv-1.17
Hi Thomas, Thomas Klausner wrote: > On Mon, Mar 27, 2023 at 10:03:18AM +, Riccardo Mottola wrote: >> I am trying to upgrade current pkgsrc packages on current. >> >> Current installed version: >> libiconv-1.14nb3Character set conversion library > IIRC libiconv doesn't build if a different version is already > installed - is that the case in your setup? > Thomas yes, I have Current installed version: libiconv-1.14nb3 and am trying to upgrade to libiconv-1.17 which is in current pkgsrc. Since you hinted an issue, I uninstalled libiconv. It had no reverse dependencies. After that, "make install" of libiconv succeeded (of course, not make replace). I think this is a bug, since it prevents a proper upgrade. Riccardo
Re: clang-built NetBSD and rust
Havard Eidnes writes: > I've looked at > > ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD-llvm/latest/amd64/binary/sets/ > > and specifically the base.tar.xz file, and it doesn't look like it has > libgcc_s at all, but apparently MKGCC=yes will build it, but that > doesn't appear to be the default (which is probably intentional). > > So ... what should I/we do about this? Do we need a separate rust > bootstrap kit built with clang and built with a clang-built "target > root"? It looks like there's no netbsd-9 nor netbsd-10 built with > clang, only HEAD? Basically binary packages are built for some environment, and you then can't change the environment and expect them to work. So yes, for NetBSD with LLVM and not GCC, I think we need different bootstraps, and that's work to generate and awkward to implement. I don't think you should feel any duty to accomodate this, which I say even if I'm a clang fan. The big question to me is if a system with HAVE_LLVM can also build with MKGCC. The wiki says no: https://wiki.netbsd.org/tutorials/clang/ but that was likely adopted by me from list traffic and may be wrong. I am unclear on whether NetBSD which 1) builds clang and 2) uses clang to build the system can sanely also have GCC available, and whether we should turn that on in public builds. That's a bigger question than rust, surely. The real issue is that it's a bug that rust needs binary bootstraps, and that there's no path from source with a base system. This is exacerbated by the rust.org implementation's practice of reuquiring the previous rust version. But other than the eventual gcc, and maybe mrustc, I don't see that getting fixed, since they seem to view the current situation as ok.
Re: clang-built NetBSD and rust
On Mon, 27 Mar 2023 14:18:30 +0200 (CEST) Havard Eidnes wrote: > a user contacted me about having a freshly installed version of > NetBSD-current for amd64 built with clang, and a failure to run > the provided "bootstrap kit" for rust, with the following error: > > /usr/lib/libgcc_s.so.1: version GCC_3.3 required by > /tmp/pkgsrc/wip/rust/work/rust-bootstrap/bin/cargo not found NetBSD from HEAD-llvm does not ship with libgcc_s.so.1, so one has to manually provide it in order to run foreign binaries built with GCC. Where did the user get libgcc_s.so.1 from? I have rust-1.66.1 (not the latest) on my HEAD-llvm amd64 system. Base is 9.99.107 (again not the latest) and libgcc_so.so.1 is from 9.99.99. So if this broke it did so fairly recently. > So ... what should I/we do about this? Do we need a separate rust > bootstrap kit built with clang and built with a clang-built "target > root"? It looks like there's no netbsd-9 nor netbsd-10 built with > clang, only HEAD? Until clang ships as part of a formal release (with NetBSD release binaries) I think it is OK to require users to manually provide libgcc_s.so.1.
clang-built NetBSD and rust
Hi,
a user contacted me about having a freshly installed version of
NetBSD-current for amd64 built with clang, and a failure to run
the provided "bootstrap kit" for rust, with the following error:
/usr/lib/libgcc_s.so.1: version GCC_3.3 required by
/tmp/pkgsrc/wip/rust/work/rust-bootstrap/bin/cargo not found
Now, the NetBSD/amd64 bootstrap is built "upstream", i.e. it is
not one of the kits I maintain for NetBSD, and I'm pretty certain
that bootstrap kit is built on NetBSD 8.x:
: {115} pwd
/usr/pkgsrc/wip/rust/work/rust-bootstrap/bin
: {116} file cargo
: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter /usr/libexec/ld.elf_so, for NetBSD 8.0, with debug_info, not
stripped
: {117} ldd cargo
cargo:
-lpthread.1 => /usr/lib/libpthread.so.1
-lc.12 => /usr/lib/libc.so.12
-lgcc_s.1 => /usr/lib/libgcc_s.so.1
-lm.0 => /usr/lib/libm.so.0
: {118} uname -ps
NetBSD x86_64
: {119}
(That's the 1.67.1 bootstrap kit, used for 1.68.*.)
Now, I'm pretty sure this "bootstrap kit" has already been built with
the equivalent of "CONFIGURE_ARGS+= --enable-cargo-native-static"
(which is in our options.mk), which links nghttp2 and curl statically,
but this does not eliminate the dynamic reference to libgcc_s.so.1.
I've looked at
ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD-llvm/latest/amd64/binary/sets/
and specifically the base.tar.xz file, and it doesn't look like it has
libgcc_s at all, but apparently MKGCC=yes will build it, but that
doesn't appear to be the default (which is probably intentional).
So ... what should I/we do about this? Do we need a separate rust
bootstrap kit built with clang and built with a clang-built "target
root"? It looks like there's no netbsd-9 nor netbsd-10 built with
clang, only HEAD?
Regards,
- Håvard
Re: error installing libiconv-1.17
On Mon, 27 Mar 2023 10:03:18 + Riccardo Mottola wrote: > I am trying to upgrade current pkgsrc packages on current. > > Any ideas? > -Wl,-rpath,/usr/pkg/lib > ld: cannot find -liconv: No such file or directory > *** Error code 1 PR pkg/57222. One way to work around the problem without having to resort to pkg_delete -f is: libiconv# mv /usr/pkg/lib/libiconv.so* /root libiconv# make clean replace
Re: error installing libiconv-1.17
On Mon, Mar 27, 2023 at 10:03:18AM +, Riccardo Mottola wrote: > I am trying to upgrade current pkgsrc packages on current. > > Current installed version: > libiconv-1.14nb3Character set conversion library IIRC libiconv doesn't build if a different version is already installed - is that the case in your setup? Thomas
error installing libiconv-1.17
Hello, I am trying to upgrade current pkgsrc packages on current. Current installed version: libiconv-1.14nb3Character set conversion library Any ideas? Riccardo libtool: install: chmod 644 /usr/pkgsrc/converters/libiconv/work/.destdir/usr/pkg/lib/libiconv.a libtool: install: ranlib /usr/pkgsrc/converters/libiconv/work/.destdir/usr/pkg/lib/libiconv.a libtool: warning: remember to run 'libtool --finish /usr/pkg/lib' case "netbsd" in aix*) (cd /usr/pkgsrc/converters/libiconv/work/.destdir/usr/pkg/lib && objects=`ar t libiconv.a`" "`ar t /lib/libiconv.a` && ar x libiconv.a && ar x /lib/libiconv.a && ar q libiconv.new.a $objects && rm -f $objects && mv -f libiconv.new.a libiconv.a) ;; esac cd srclib && /usr/bin/make install prefix='/usr/pkg' exec_prefix='/usr/pkg' libdir='/usr/pkg/lib' /usr/bin/make install-am cd src && /usr/bin/make install prefix='/usr/pkg' exec_prefix='/usr/pkg' libdir='/usr/pkg/lib' test `ls -ld . | sed -e 's/^d\(.\).*/\1/'` = rwxrwxrwx || chmod 777 . if [ ! -d /usr/pkgsrc/converters/libiconv/work/.destdir/usr/pkg/bin ] ; then /bin/sh ../build-aux/mkinstalldirs /usr/pkgsrc/converters/libiconv/work/.destdir/usr/pkg/bin ; fi case "netbsd" in hpux*) gcc -Wl,-zrelro -Wl,-R/usr/pkg/lib -O2 -march=core2 -fPIC -D_FORTIFY_SOURCE=2 `if test -n ''; then /usr/pkg/bin; fi` iconv.o ../srclib/libicrt.a -L/usr/pkgsrc/converters/libiconv/work/.destdir/usr/pkg/lib -liconv `if test -n '/usr/pkgsrc/converters/libiconv/work/.destdir'; then echo " -Wl,+b -Wl,/usr/pkg/lib"; fi` -o iconv;; *) /bin/sh ../libtool --mode=link gcc -Wl,-zrelro -Wl,-R/usr/pkg/lib -O2 -march=core2 -fPIC -D_FORTIFY_SOURCE=2 `if test -n ''; then /usr/pkg/bin; fi` iconv.o ../srclib/libicrt.a /usr/pkgsrc/converters/libiconv/work/.destdir/usr/pkg/lib/libiconv.la -o iconv;; esac libtool: link: gcc -Wl,-zrelro -Wl,-rpath -Wl,/usr/pkg/lib -O2 -march=core2 -fPIC -D_FORTIFY_SOURCE=2 iconv.o -o iconv -pie ../srclib/libicrt.a -L/usr/pkg/lib -liconv -Wl,-rpath,/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib ld: cannot find -liconv: No such file or directory *** Error code 1
Re: 10.0_BETA intelfb/drm on x220 thinkpad
On 3/27/23 10:19 AM, RVP wrote: On Sun, 26 Mar 2023, Staffan Thomen wrote: Add something like this in /etc/wscons.conf to get the smaller (8x16) built-in font: setvar ttyE0 font Boldface I see, thank you. Staffan
Re: 10.0_BETA intelfb/drm on x220 thinkpad
On Sun, 26 Mar 2023, Staffan Thomen wrote:
intelfb0: framebuffer at 0xe0005000, size 1366x768, depth 32, stride 5504
{drm:netbsd:intel_cpu_fifo_underrun_irq_handler+0x64} *ERROR* CPU pipe A FIFO
underrun
{drm:netbsd:intel_set_pch_fifo_underrun_reporting+0x14e} *ERROR* uncleared pch
fifo underrun on pch transcoder A
{drm:netbsd:cpt_irq_handler+0x1dd} *ERROR* PCH transcoder A FIFO underrun
I see the same message on Linux (Ubuntu 19.04) too, so I don't think this
is a critical error.
...and wsdisplay resets to a tiny resolution (huge text). X11 works just fine
and seems accelerated.
No, that just the 16x32 built-in font being used after intelfb takes over.
Your resolution is 1366x768 as you can see in that framebuffer info. line.
Add something like this in /etc/wscons.conf to get the smaller (8x16)
built-in font:
setvar ttyE0 fontBoldface
setvar ttyE1 fontBoldface
setvar ttyE2 fontBoldface
setvar ttyE3 fontBoldface
-RVP
