Re: libstdc++.so.7 is missing
Spot on! Midori is running now. No errors or missing libs when launching it from the terminal. Accessed a couple of web pages just to try without any issues. That's great, Thx! /Pedro P.S.: Will the fix be pushed to the repo? Or are you still looking for a permanent fix? Den sön 20 jan. 2019 21:25 skrev Leonardo Taccari : > Greg Troxel writes: > > [...] > > Overall, just randomly trying things isn't going to help. We need to > > find the bug so we can fix it. > > > > > > How are other people doing with these packages and netbsd-8? > > > > Is it just midori? Are there other packages that have binaries that try > > to load stdc++.so.8? > > [...] > > I think that the root case is the following: > webkit-gtk needs gcc 6.0 or newer and that's required via GCC_REQD > both in in www/webkit-gtk/Makefile and www/webkit-gtk/buildlink3.mk. > This leads to build webkit-gtk and its dependencies (at least > midori!) fine but fails at run time as noticed by Pedro. > > I think that libstdc++.so.7 is actually provided by lang/gcc6-libs > and I think that webkit-gtk probably also needs > `USE_GCC_RUNTIME= yes' too (but I'm pretty unfamiliar with that and > I hope that someone can comment on that after we double-check that's > actually the issue!). > > Pedro, can you please try to install gcc6-libs package and let us > know if that fixes the problem? > > > Thanks! >
Re: libstdc++.so.7 is missing
Sometimes it's a bit strange with mailing lists ;) I've installed gcc6-libs and that fixed the problem. I'm really happy for it and would like to thank you all for bearing with me. I've been testing the browser for 15min and its working. Although, I have to figure out why its eating ~70% of my cpu, i5 quad-core on some pages. Den sön 20 jan. 2019 22:12 skrev David H. Gutteridge : > On Sun, 2019-01-20 at 17:34 +0100, Pedro Pinho wrote: > > The symlink was just a test, I've removed it as I got another missing > library. > > > > Here's the output of ldd /usr/pkg/bin/midori > https://pastebin.com/h6wbXvBu > > and the output of ldd /usr/pkg/lib/lib*.so https://pastebin.com/UPT68xaw > > the last one, i.e. ldd /usr/pkg/bin gives just read error: Operation not > supported by device > > > > I see if I get the time to compile midori from pkgsrc later today. > > I looked at the midori package that was uploaded on or after January > 14th, and it has "@blddep gcc6-6.5.0nb2" noted. If you don't have the > package gcc6-libs-6.5.0nb3.tgz from the Q4 build installed, please add > it and report the results. (If that fixes your problem, then there's a > package that needs to be corrected.) > > If not, separately, as Greg noted, we need to disentangle what requires > what. Looking at your ldd output for midori, we see both libstdc++.7 > and .8 get referenced. That on its own isn't enough, because some of > the non-pkgsrc libraries that are referenced there definitely require > .8, e.g. it's pulling in libGL from xbase, which links against .8. > > And, separately again, yes, I see gimp is missing from the Q4 packages. > I guess either it didn't build for some reason or the uploaded packages > are incomplete. Whoever supports those binary pkg builds would have to > comment here. > > Dave > > >
Re: libstdc++.so.7 is missing
I wonder if the absence of some packages in the archives (like gimp in 2018Q4) are related to what I’m seeing in my builds. Some packages build successfully as individual builds, but fail to build when part of a pbulk build. Both done inside a sandbox. The one I’m trying to figure out right now is go111 in current pkgsrc. If builds fine as an individual build, but fails within a pbulk build with an error trying to execute some go14 commands. When I monitor the build progress of the pbulk build it appears to correctly install go14 since it’s listed as a BUILD_DEPENDS in the go111 Makefile, but then quickly removes it. I’m assuming it gets deinstalled before the go111 build script gets to the point of needing it. I suspected that it might be related to having MAKE_JOBS set to 4 for pbulk, but setting it to 1 didn’t solve the problem. Anyway, I’m pretty sure it has to be some setup in my pbulk that’s causing the problem, but I’m at a loss to figure out what it is. Maybe the same thing is happening for some of the bulk builds that get posted on the server causing some packages to not be available? I did set up my pbulk environment following the instructions posted on the Wiki. -bob On Jan 20, 2019, at 3:11 PM, David H. Gutteridge wrote: > On Sun, 2019-01-20 at 17:34 +0100, Pedro Pinho wrote: >> The symlink was just a test, I've removed it as I got another missing >> library. >> >> Here's the output of ldd /usr/pkg/bin/midori https://pastebin.com/h6wbXvBu >> and the output of ldd /usr/pkg/lib/lib*.so https://pastebin.com/UPT68xaw >> the last one, i.e. ldd /usr/pkg/bin gives just read error: Operation not >> supported by device >> >> I see if I get the time to compile midori from pkgsrc later today. > > I looked at the midori package that was uploaded on or after January > 14th, and it has "@blddep gcc6-6.5.0nb2" noted. If you don't have the > package gcc6-libs-6.5.0nb3.tgz from the Q4 build installed, please add > it and report the results. (If that fixes your problem, then there's a > package that needs to be corrected.) > > If not, separately, as Greg noted, we need to disentangle what requires > what. Looking at your ldd output for midori, we see both libstdc++.7 > and .8 get referenced. That on its own isn't enough, because some of > the non-pkgsrc libraries that are referenced there definitely require > .8, e.g. it's pulling in libGL from xbase, which links against .8. > > And, separately again, yes, I see gimp is missing from the Q4 packages. > I guess either it didn't build for some reason or the uploaded packages > are incomplete. Whoever supports those binary pkg builds would have to > comment here. > > Dave > >
Re: libstdc++.so.7 is missing
On Sun, 2019-01-20 at 22:26 +0100, Pedro Pinho wrote: > Sometimes it's a bit strange with mailing lists ;) > I've installed gcc6-libs and that fixed the problem. I'm really happy for it > and would like to thank you all for bearing with me. > I've been testing the browser for 15min and its working. Although, I have to > figure out why its eating ~70% of my cpu, i5 quad-core on some pages. Good to hear. So that implies there's an issue where midori or one of its dependencies requires a pkgsrc version of gcc-libs, but this isn't noted in a way that makes package installation tools aware. I'll have a look at this when I have a moment. Dave
Re: libstdc++.so.7 is missing
On Sun, 2019-01-20 at 17:34 +0100, Pedro Pinho wrote: > The symlink was just a test, I've removed it as I got another missing library. > > Here's the output of ldd /usr/pkg/bin/midori https://pastebin.com/h6wbXvBu > and the output of ldd /usr/pkg/lib/lib*.so https://pastebin.com/UPT68xaw > the last one, i.e. ldd /usr/pkg/bin gives just read error: Operation not > supported by device > > I see if I get the time to compile midori from pkgsrc later today. I looked at the midori package that was uploaded on or after January 14th, and it has "@blddep gcc6-6.5.0nb2" noted. If you don't have the package gcc6-libs-6.5.0nb3.tgz from the Q4 build installed, please add it and report the results. (If that fixes your problem, then there's a package that needs to be corrected.) If not, separately, as Greg noted, we need to disentangle what requires what. Looking at your ldd output for midori, we see both libstdc++.7 and .8 get referenced. That on its own isn't enough, because some of the non-pkgsrc libraries that are referenced there definitely require .8, e.g. it's pulling in libGL from xbase, which links against .8. And, separately again, yes, I see gimp is missing from the Q4 packages. I guess either it didn't build for some reason or the uploaded packages are incomplete. Whoever supports those binary pkg builds would have to comment here. Dave
Re: libstdc++.so.7 is missing
Leonardo Taccari writes: > Greg Troxel writes: >> [...] >> Overall, just randomly trying things isn't going to help. We need to >> find the bug so we can fix it. >> >> >> How are other people doing with these packages and netbsd-8? >> >> Is it just midori? Are there other packages that have binaries that try >> to load stdc++.so.8? >> [...] > > I think that the root case is the following: > webkit-gtk needs gcc 6.0 or newer and that's required via GCC_REQD > both in in www/webkit-gtk/Makefile and www/webkit-gtk/buildlink3.mk. > This leads to build webkit-gtk and its dependencies (at least > midori!) fine but fails at run time as noticed by Pedro. > > I think that libstdc++.so.7 is actually provided by lang/gcc6-libs > and I think that webkit-gtk probably also needs > `USE_GCC_RUNTIME= yes' too (but I'm pretty unfamiliar with that and > I hope that someone can comment on that after we double-check that's > actually the issue!). > > Pedro, can you please try to install gcc6-libs package and let us > know if that fixes the problem? I think there are actually two bugs, and we need to fix both. 1) gcc*-libs packages have stdc++.so.7 -rw-r--r-- 1 pkgmastr netbsd 2560144 Oct 5 21:45 gcc48-libs-4.8.5nb7.tgz -rw-r--r-- 1 pkgmastr netbsd 5107668 Oct 6 05:49 gcc7-libs-7.3.0nb4.tgz -rw-r--r-- 1 pkgmastr netbsd 2784192 Oct 6 08:53 gcc49-libs-4.9.4nb8.tgz -rw-r--r-- 1 pkgmastr netbsd 4096904 Dec 28 08:02 gcc6-libs-6.5.0nb3.tgz -rw-r--r-- 1 pkgmastr netbsd 7611972 Jan 14 05:02 gcc8-libs-8.2.0nb3.tgz -rw-r--r-- 1 pkgmastr netbsd 3724904 Jan 14 05:02 gcc5-libs-5.5.0nb5.tgz ftp gdt 45 /pub/pkgsrc/packages/NetBSD/amd64/8.0_2018Q4/All > pkg_info -L gcc6-libs-6.5.0nb3.tgz | egrep stdc++ /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7 /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22 /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22-gdb.py But this is not about them being old. gcc6-libs on my netbsd-8 system, built on January 8, is also .so.7. It is not going to work to build things with different compilers unless they all have the same ABI. Which isn't really the case, and it really really isn't ther case with different shlib versions. 2) separately from the above, anything that ends up linking to a gccN-libs package has to have this end up as a dependency. Perhaps anything that uses a GCC_REQ-induced compiler and has USE_LANGUAGES=c++, but setting it manually sounds fine. Maybe Roland can figure out how to make pkglint also process binary packages and look for a REQUIRES from another package without a matching dependency :-) To fix the first problem, I think we need to either really deal with compiler selection, which I think now means build gcc6 use gcc6 for everything and this is sort of written up on the wiki make the shlib version of stdc++ consistent across base and all compilers, and then hope whatever ABI fuzz there is doesn't hurt.
Re: libstdc++.so.7 is missing
Greg Troxel writes: > [...] > Overall, just randomly trying things isn't going to help. We need to > find the bug so we can fix it. > > > How are other people doing with these packages and netbsd-8? > > Is it just midori? Are there other packages that have binaries that try > to load stdc++.so.8? > [...] I think that the root case is the following: webkit-gtk needs gcc 6.0 or newer and that's required via GCC_REQD both in in www/webkit-gtk/Makefile and www/webkit-gtk/buildlink3.mk. This leads to build webkit-gtk and its dependencies (at least midori!) fine but fails at run time as noticed by Pedro. I think that libstdc++.so.7 is actually provided by lang/gcc6-libs and I think that webkit-gtk probably also needs `USE_GCC_RUNTIME= yes' too (but I'm pretty unfamiliar with that and I hope that someone can comment on that after we double-check that's actually the issue!). Pedro, can you please try to install gcc6-libs package and let us know if that fixes the problem? Thanks!
Re: libstdc++.so.7 is missing
Good luck building midori from source. I have tried at least three times on recent -current with current and updated pkgsrc with no luck whatsoever. The latest is this afternoon - webkit-gtk does not build: [ 92%] Building CXX object Source/WebKit/CMakeFiles/WebKit.dir/__/__/DerivedSources/WebKit/unified-sources/UnifiedSource61.cpp.o [ 92%] Building CXX object Source/WebKit/CMakeFiles/WebKit.dir/__/__/DerivedSources/WebKit/unified-sources/UnifiedSource62.cpp.o [ 92%] Building CXX object Source/WebKit/CMakeFiles/WebKit.dir/WebProcess/WebPage/gtk/AcceleratedSurfaceX11.cpp.o [ 92%] Building CXX object Source/WebKit/CMakeFiles/WebKit.dir/__/__/DerivedSources/WebKit/unified-sources/UnifiedSource63.cpp.o [ 92%] Building CXX object Source/WebKit/CMakeFiles/WebKit.dir/__/__/DerivedSources/WebKit/unified-sources/UnifiedSource64.cpp.o [ 92%] Building CXX object Source/WebKit/CMakeFiles/WebKit.dir/__/__/DerivedSources/WebKit/unified-sources/UnifiedSource65.cpp.o [ 92%] Linking CXX shared library ../../lib/libwebkit2gtk-4.0.so [ 92%] Built target WebKit Scanning dependencies of target WebKit2-4-gir gmake[2]: *** No rule to make target 'JavaScriptCore-4.0.gir', needed by 'WebKit2-4.0.gir'. Stop. gmake[1]: *** [CMakeFiles/Makefile2:1318: Source/WebKit/CMakeFiles/WebKit2-4-gir.dir/all] Error 2 gmake: *** [Makefile:152: all] Error 2 *** Error code 2 . Last time I was able to build it, perhaps six months ago, it just crashed, so I left it for later. Then again, I run -current, doing updates usually twice a week, also following -current pkgsrc, doing usually monthly pkg_rolling-replace, so problems are to be expected. However, while earlier versions of firefox used to be, shall I say, flaky, and crash in random places, the last 2-3 updates have been very stable for me, right now on 64.0.2. Rust takes a long to build, for sure, and is updated way too often, but at the end firefox seems fine. On Sun, 20 Jan 2019 at 19:00, Pedro Pinho wrote: > > Just found another missing package from 2018Q4, gimp is not available as a > binary package. > > Den sön 20 jan. 2019 kl 17:34 skrev Pedro Pinho : > > > The symlink was just a test, I've removed it as I got another missing > > library. > > > > Here's the output of ldd /usr/pkg/bin/midori https://pastebin.com/h6wbXvBu > > and the output of ldd /usr/pkg/lib/lib*.so https://pastebin.com/UPT68xaw > > the last one, i.e. ldd /usr/pkg/bin gives just read error: Operation not > > supported by device > > > > I see if I get the time to compile midori from pkgsrc later today. > > > > Den sön 20 jan. 2019 kl 14:58 skrev Greg Troxel : > > > >> Pedro Pinho writes: > >> > >> > Back at home! > >> > I've just erased my disk using gpsrted-live usb and made a fresh install > >> > from the image here, > >> > > >> http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/ > >> > > >> > NetBSD 8.0 STABLE arch amd64 > >> > > >> > Pointed pkgin to > >> > http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ > >> > > >> > and pulled my binary packages. Launching midori from xterm outputs > >> > libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to > >> > libstdc++.so.7 to no avail. Can't launch midori. > >> > >> Don't add symlinks like that. It's just going to make a mess. > >> > >> Somebody -- perhaps it will be you -- has to understand what is going on --
Re: libstdc++.so.7 is missing
The symlink was just a test, I've removed it as I got another missing library. Here's the output of ldd /usr/pkg/bin/midori https://pastebin.com/h6wbXvBu and the output of ldd /usr/pkg/lib/lib*.so https://pastebin.com/UPT68xaw the last one, i.e. ldd /usr/pkg/bin gives just read error: Operation not supported by device I see if I get the time to compile midori from pkgsrc later today. Den sön 20 jan. 2019 kl 14:58 skrev Greg Troxel : > Pedro Pinho writes: > > > Back at home! > > I've just erased my disk using gpsrted-live usb and made a fresh install > > from the image here, > > http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/ > > > > NetBSD 8.0 STABLE arch amd64 > > > > Pointed pkgin to > > http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ > > > > and pulled my binary packages. Launching midori from xterm outputs > > libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to > > libstdc++.so.7 to no avail. Can't launch midori. > > Don't add symlinks like that. It's just going to make a mess. > > Somebody -- perhaps it will be you -- has to understand what is going on. > > So: > > option 1) > > ldd /usr/pkg/lib/lib*.so > /tmp/LDD.lib > ldd /usr/pkg/bin > /tmp/LDD.bin > > look in those files and find the entire set of programs and libs that have > libstdc++.so.7 > From that find the root cause, which is something that directly includes > it, vs including a library that includes it. ldd makes this not that > easy. > > option 2) > > on each library and each binary, use objdump -x and look for a line that > says NEEDED and libstdc++.so.7. > > Overall, just randomly trying things isn't going to help. We need to > find the bug so we can fix it. > > > How are other people doing with these packages and netbsd-8? > > Is it just midori? Are there other packages that have binaries that try > to load stdc++.so.8? >
Re: libstdc++.so.7 is missing
Just found another missing package from 2018Q4, gimp is not available as a binary package. Den sön 20 jan. 2019 kl 17:34 skrev Pedro Pinho : > The symlink was just a test, I've removed it as I got another missing > library. > > Here's the output of ldd /usr/pkg/bin/midori https://pastebin.com/h6wbXvBu > and the output of ldd /usr/pkg/lib/lib*.so https://pastebin.com/UPT68xaw > the last one, i.e. ldd /usr/pkg/bin gives just read error: Operation not > supported by device > > I see if I get the time to compile midori from pkgsrc later today. > > Den sön 20 jan. 2019 kl 14:58 skrev Greg Troxel : > >> Pedro Pinho writes: >> >> > Back at home! >> > I've just erased my disk using gpsrted-live usb and made a fresh install >> > from the image here, >> > >> http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/ >> > >> > NetBSD 8.0 STABLE arch amd64 >> > >> > Pointed pkgin to >> > http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ >> > >> > and pulled my binary packages. Launching midori from xterm outputs >> > libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to >> > libstdc++.so.7 to no avail. Can't launch midori. >> >> Don't add symlinks like that. It's just going to make a mess. >> >> Somebody -- perhaps it will be you -- has to understand what is going on
Re: libstdc++.so.7 is missing
On Sun 20 Jan 2019 at 08:58:55 -0500, Greg Troxel wrote:
> From that find the root cause, which is something that directly includes
> it, vs including a library that includes it. ldd makes this not that
> easy.
FreeBSD's ldd has an option to show just the libraries that are required
directly (and recurses, so it shows it more nicely separated). I made a
perl script that does more or less the same, but it also prints the
reverse relationships, the search path of each library, and any
conflicts between different versions of the same library.
#!/usr/pkg/bin/perl
#
# A ldd-replacement which clearly indicates which libraries are needed
# by which object.
#
my %map;
my %needed_by;
my @todo;
sub do_one_file {
my $file = shift;
my @needed;
my @path;
open OBJDUMP, "objdump -x $file |";
while () {
chomp;
if (/NEEDED/) {
s/\s*NEEDED\s*//;
push @needed, $_;
}
if (/RPATH/) {
s/\s*RPATH\s*//;
@path = split /:/;
print "path = @path\n";
break;
}
}
close OBJDUMP;
push @path, "/usr/lib";
push @path, "/lib";
print "$file needs:\n";
for my $lib (@needed) {
# Find $lib in @path
my $found = 0;
PATH:
for my $dir (@path) {
my $candidate = $dir."/".$lib;
if (-e $candidate) {
print "\t$lib => $candidate\n";
$found = 1;
if (exists $map{$lib}) {
# $candidate was already processed before
} else {
push @todo, $candidate;
$map{$lib} = $candidate;
}
if (!exists $needed_by{$candidate}) {
$needed_by{$candidate} = undef;
# then the next push will use autovivivication
}
push @{$needed_by{$candidate}}, $file;
last PATH;
}
}
if (!$found) {
print "\t$lib not found\n";
}
}
if (@needed == 0) {
print "\t(nothing)\n";
}
print "\n";
}
push @todo, @ARGV;
while (@todo) {
do_one_file(pop @todo);
}
# Dump reverse requirements:
my %fullib;
for my $lib (sort keys %needed_by) {
print "$lib <=\n";
for my $by (@{$needed_by{$lib}}) {
print "\t$by\n";
}
print "\n";
# Create a mapping of short lib name to full file name
# to detect potential conflicts
my $short = $lib;
$short =~ s=.*/==;
$short =~ s=\.so[.0-9]*==;
if (!exists $fullib{$short}) {
$fullib{$short} = undef;
# then the next push will use autovivivication
}
push @{$fullib{$short}}, $lib;
}
# Dump conflicts
print "Conflicting libraries:\n";
for my $lib (sort keys %fullib) {
my @longnames = @{$fullib{$lib}};
if (@longnames > 1) {
print "$lib ==\n";
for my $longname (@longnames) {
print "\t", $longname, "\n";
for my $by (@{$needed_by{$longname}}) {
print "\t\t$by\n";
}
print "\n";
}
}
}
signature.asc
Description: PGP signature
Re: libstdc++.so.7 is missing
Pedro Pinho writes: > Back at home! > I've just erased my disk using gpsrted-live usb and made a fresh install > from the image here, > http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/ > > NetBSD 8.0 STABLE arch amd64 > > Pointed pkgin to > http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ > > and pulled my binary packages. Launching midori from xterm outputs > libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to > libstdc++.so.7 to no avail. Can't launch midori. Don't add symlinks like that. It's just going to make a mess. Somebody -- perhaps it will be you -- has to understand what is going on. So: option 1) ldd /usr/pkg/lib/lib*.so > /tmp/LDD.lib ldd /usr/pkg/bin > /tmp/LDD.bin look in those files and find the entire set of programs and libs that have libstdc++.so.7 >From that find the root cause, which is something that directly includes it, vs including a library that includes it. ldd makes this not that easy. option 2) on each library and each binary, use objdump -x and look for a line that says NEEDED and libstdc++.so.7. Overall, just randomly trying things isn't going to help. We need to find the bug so we can fix it. How are other people doing with these packages and netbsd-8? Is it just midori? Are there other packages that have binaries that try to load stdc++.so.8?
Re: libstdc++.so.7 is missing
Hi all, A bit short of time today, but... I'll try to post the output from ldd later today. It was rather long, so maybe a link to pastebin or similar is better. I think both of you (Dave, Robert and Martin) are probably right about how the binary was built. I could use another browser, but I want to use midori to test, it was me that issued the request on pkgsrc-WIP and it would be nice to give the guys overthere some feedback. When I have time, I'll remove midori from pkgin and autoremove the pulled dependencies. Then I'll try building it locally using pkgsrc stable to see if that works. Thanks guys. Den sön 20 jan. 2019 09:16 skrev Martin Husemann : > On Sat, Jan 19, 2019 at 06:45:16PM -0500, David H. Gutteridge wrote: > > Though I don't think this is the most likely answer here, another > > possibility is that the problem packages have been built on a machine > > running an 8.0_BETA release from prior to Oct. 12, 2017. Because prior > > to that, libstdc++.so.7 existed, and then it was replaced with .8.[1] > > That is not a very unlikely answer and probably even the correct one. > This is a problem with the binary pkgs for sure and might be overlooked > by the relevant people here. > > Martin >
Re: libstdc++.so.7 is missing
On Sat, Jan 19, 2019 at 06:45:16PM -0500, David H. Gutteridge wrote: > Though I don't think this is the most likely answer here, another > possibility is that the problem packages have been built on a machine > running an 8.0_BETA release from prior to Oct. 12, 2017. Because prior > to that, libstdc++.so.7 existed, and then it was replaced with .8.[1] That is not a very unlikely answer and probably even the correct one. This is a problem with the binary pkgs for sure and might be overlooked by the relevant people here. Martin
Re: libstdc++.so.7 is missing
Back at home! I've just erased my disk using gpsrted-live usb and made a fresh install from the image here, http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/ NetBSD 8.0 STABLE arch amd64 Pointed pkgin to http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ and pulled my binary packages. Launching midori from xterm outputs libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to libstdc++.so.7 to no avail. Can't launch midori. It would be ok with firefox but, as mentioned already, firefox is not there!! Any suggestions?! Thx! Den fre 18 jan. 2019 21:48 skrev Rhialto : > On Fri 18 Jan 2019 at 13:00:09 -0600, Robert Nestor wrote: > > , because perl-5.28.1 doesn?t build. > > > It errors out with an internal gcc compiler error using the gcc that > > comes with NetBSD 8.0_STABLE. > > I built perl-5.28.1 on NetBSD/amd64 8.0, as released (so nothing later > than that), and for me it built... So maybe there is some difference > between those versions that matters here somehow. > > -Olaf. > -- > ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power > \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent > Elrond >
Re: libstdc++.so.7 is missing
On Sat, 2019-01-19 at 17:58 -0500, David H. Gutteridge wrote: > On Sat, 2019-01-19 at 23:43 +0100, Pedro Pinho wrote: > > Back at home! > > I've just erased my disk using gpsrted-live usb and made a fresh > > install from the image here, > > http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/ > > > > NetBSD 8.0 STABLE arch amd64 > > > > Pointed pkgin to > > http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ > > > > and pulled my binary packages. Launching midori from xterm outputs > > libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to > > libstdc++.so.7 to no avail. Can't launch midori. > > It would be ok with firefox but, as mentioned already, firefox is > > not > > there!! > > > > Any suggestions?! > > Please post the output of ldd against the midori binary. > > Dave To clarify, you'll presumably get "-lstdc++.7 => not found", which isn't too helpful of itself. I wanted to see in totality what it links against on your system, and if there is anything else missing it needs. It would be more helpful, actually, to see what the @blddep and @pkgdep entries in its pkgdb +CONTENTS file are. Dave
Re: libstdc++.so.7 is missing
On Sat, 2019-01-19 at 23:43 +0100, Pedro Pinho wrote: > Back at home! > I've just erased my disk using gpsrted-live usb and made a fresh install from > the image here, > http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/ > > NetBSD 8.0 STABLE arch amd64 > > Pointed pkgin to > http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ > > and pulled my binary packages. Launching midori from xterm outputs > libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to libstdc++.so.7 > to no avail. Can't launch midori. > It would be ok with firefox but, as mentioned already, firefox is not there!! > > Any suggestions?! > Thx! Though I don't think this is the most likely answer here, another possibility is that the problem packages have been built on a machine running an 8.0_BETA release from prior to Oct. 12, 2017. Because prior to that, libstdc++.so.7 existed, and then it was replaced with .8.[1] This may be the reason I see things like this with the builds found for powerpc/8.0_2018Q3: blackbox: -lSM.7 => /usr/X11R7/lib/libSM.so.7 -lICE.7 => /usr/X11R7/lib/libICE.so.7 -lc.12 => /usr/lib/libc.so.12 -lX11.7 => /usr/X11R7/lib/libX11.so.7 -lxcb.2 => /usr/X11R7/lib/libxcb.so.2 -lXau.7 => /usr/X11R7/lib/libXau.so.7 -lXdmcp.7 => /usr/X11R7/lib/libXdmcp.so.7 -lXext.7 => /usr/X11R7/lib/libXext.so.7 -lstdc++.7 => not found -lm.0 => /usr/lib/libm.so.0 -lgcc_s.1 => /usr/lib/libgcc_s.so.1 1. http://cvsweb.netbsd.org/bsdweb.cgi/src/distrib/sets/lists/base/shl.mi?rev=1.817.2.2=text/x-cvsweb-markup_with_tag=netbsd-8 Dave
Re: libstdc++.so.7 is missing
On Sat, 2019-01-19 at 23:43 +0100, Pedro Pinho wrote: > Back at home! > I've just erased my disk using gpsrted-live usb and made a fresh > install from the image here, > http://ftp.fr.netbsd.org/pub/NetBSD-daily/netbsd-8/201901151910Z/images/ > > NetBSD 8.0 STABLE arch amd64 > > Pointed pkgin to > http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ > > and pulled my binary packages. Launching midori from xterm outputs > libstdc++.so.7 is missing. Tried symlinking libsrdc++.so.8 to > libstdc++.so.7 to no avail. Can't launch midori. > It would be ok with firefox but, as mentioned already, firefox is not > there!! > > Any suggestions?! Please post the output of ldd against the midori binary. Dave
Re: libstdc++.so.7 is missing
On Fri 18 Jan 2019 at 13:00:09 -0600, Robert Nestor wrote: > , because perl-5.28.1 doesn?t build. > It errors out with an internal gcc compiler error using the gcc that > comes with NetBSD 8.0_STABLE. I built perl-5.28.1 on NetBSD/amd64 8.0, as released (so nothing later than that), and for me it built... So maybe there is some difference between those versions that matters here somehow. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: libstdc++.so.7 is missing
Did a clean checkout of pkgsrc-2018Q4 and tried building a few of the packages, mainly xfce4. If fails, along with about 122 others in my build, because perl-5.28.1 doesn’t build. but perl-5.28.1 is in the binary archives for amd64/8.0_2018Q4 on the server. So it had to build for someone, just doesn’t build from the checked out pkgsrc source. It errors out with an internal gcc compiler error using the gcc that comes with NetBSD 8.0_STABLE. I’m guessing the builds on the server were done with a different version of gcc but that’s not reflected in the package options for perl in the 2018Q4 source.
Re: libstdc++.so.7 is missing
I'm away from home for a few days and will try to fix my system as soon as possible. Still, I believe that something went wrong with the builds for the Q4 release. This a screenshot over firefox for the Q3 list of packages, https://imgur.com/GV71xgT and here is the same for Q4, https://imgur.com/0VOXYik So it might be that when I removed firefox and installed midori the refered lib was removed as an orphan package, but I can't re-install firefox simply because its not there
Re: libstdc++.so.7 is missing
Thank you for the heads-up. Building everything from source on this machine is not viable. I have a 32GB SSD and the building directories would probably "eat that up". I had no issue moving from 2018Q1 to Q2 (well except for a sync delay and a lost symlink to 8 quickly solved by posting here) or from Q2 to Q3. As mentioned, I just love minimalism and this system is a keeper, currently 2.6GB used disk space and I hardly need anything else. I can, and most probably will, roll back to 2018Q3, or even to current but, the thing is that something is wrong with 2018Q4 binaries,again firefox was just an example, as I happen to come across it when midori failed to launch but, there could be more. Den tors 17 jan. 2019 kl 20:15 skrev Robert Nestor : > I’ve noticed inconsistencies with the pre-built package archives since > about the time of NetBSD 6.2. Whenever I’ve done a clean install of NetBSD > (7.x , 8.x or -current) and then try to install some packages from almost > any corresponding package archive, I usually run into issues with > incompatible libraries. I’m not sure how it happens that packages in the > archive end up this way. > > One solution I’ve been trying with some success is to checkout the pkgsrc > that corresponds to the archive I want to use and build the packages that > are of interest to me using a pbulk build setup. However, that exposes > another issues that has me completely stumped - some packages that exist in > the package archive fail to build on my system. One good example is if I > check out the sources for pkgsrc-2018Q4 and try building the meta-pkg xfce4 > it fails, but the binary archive for it exists on the server. Assuming the > sources are the same for both my build and the one that was posted on the > server then the question becomes, what’s different in the two build > setups? I’m beginning to suspect that maybe the packages in the 2018Q4 > archive on the server were not built under a stock NetBSD 8.0 system, or > there are some special setups used that aren’t reflected in the pkg build > setup. It might be interesting to compare the contents of mk.conf for > example it see if that might explain the differences.
Re: libstdc++.so.7 is missing
On Thu, 17 Jan 2019, at 14:43:18 +0100, Marc Baudoin wrote: > Martin Husemann écrit : > > On Thu, Jan 17, 2019 at 02:35:34PM +0100, Pedro Pinho wrote: > > > Nope, this was/is 8.0 from the start. > > > > And you did not have any pkgs pre-installed? > > > > The problem is that 8.0 had libstdc++.so.8.0, and nothing compiled for 8.0 > > should ever refer to libstdc++.so.7. > > It depends where this libstdc++.so.7 is. On my system (8.0 from > the start also), gcc packages install several versions of > libstdc++.so.7: > > /usr/pkg/gcc6/lib/libstdc++.so.7 > /usr/pkg/gcc6/lib/libstdc++.so.7.22 > /usr/pkg/gcc6/lib/libstdc++.so.7.22-gdb.py > /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7 > /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22 > /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22-gdb.py > /usr/pkg/gcc8/lib/libstdc++.so.7 > /usr/pkg/gcc8/lib/libstdc++.so.7.25 > /usr/pkg/gcc8/lib/libstdc++.so.7.25-gdb.py Yes, for NetBSD 7 and 8, firefox needs a newer version of GCC than the base system provides, so you will end up with something like: ldd /usr/pkg/lib/firefox/firefox /usr/pkg/lib/firefox/firefox: -lpthread.1 => /usr/lib/libpthread.so.1 -lc.12 => /usr/lib/libc.so.12 -lstdc++.7 => /usr/pkg/gcc6/x86_64--netbsd/lib/./libstdc++.so.7 -lm.0 => /usr/lib/libm.so.0 -lgcc_s.1 => /usr/pkg/gcc6/x86_64--netbsd/lib/./libgcc_s.so.1 So perhaps what happened is the necessary gcc-libs package (e.g., in my example above, gcc6-libs) didn't get pulled in for some reason. Dave
Re: libstdc++.so.7 is missing
On Thu, 17 Jan 2019, at 11:57:36 -0600, Robert Nestor wrote: >[...] >One good example is if I check out the sources for pkgsrc-2018Q4 and >try building the meta-pkg xfce4 it fails, but the binary archive for it >exists on the server. Assuming the sources are the same for both my >build and the one that was posted on the server then the question >becomes, what’s different in the two build setups? [...] Could you provide the specific error you're seeing when trying to build meta-pkgs/xfce4? Dave
Re: libstdc++.so.7 is missing
On Fri, Jan 18, 2019 at 09:26:48AM +1100, Simon Burge wrote:
> Edgar Pettijohn wrote:
>
> > On Jan 17, 2019 7:35 AM, Pedro Pinho wrote:
> > >
> > > While we are at it... is there a pkgin command to remove every installed
> > package?
> >
> > I don't think so. I do it like so:
> >
> > pkg_info | awk '{print $1}' > pkgs.txt
> >
> > remove pkgin from the list
> >
> > while read -r pkg; do
> > pkgin remove $pkg
> > done < pkgs.txt
> >
> > forgive errors. I'm writing from memory on my phone.
>
> Do you need to use pkgin (which I've never used) or can you use
No.
> pkg_delete? This will remove all installed packages:
>
> pkg_delete -r '*'
I didn't realize that it could take a glob. Definantly easier.
Edgar
>
> Cheers,
> Simon.
Re: libstdc++.so.7 is missing
Edgar Pettijohn wrote:
> On Jan 17, 2019 7:35 AM, Pedro Pinho wrote:
> >
> > While we are at it... is there a pkgin command to remove every installed
> package?
>
> I don't think so. I do it like so:
>
> pkg_info | awk '{print $1}' > pkgs.txt
>
> remove pkgin from the list
>
> while read -r pkg; do
> pkgin remove $pkg
> done < pkgs.txt
>
> forgive errors. I'm writing from memory on my phone.
Do you need to use pkgin (which I've never used) or can you use
pkg_delete? This will remove all installed packages:
pkg_delete -r '*'
Cheers,
Simon.
Re: libstdc++.so.7 is missing
I’ve noticed inconsistencies with the pre-built package archives since about the time of NetBSD 6.2. Whenever I’ve done a clean install of NetBSD (7.x , 8.x or -current) and then try to install some packages from almost any corresponding package archive, I usually run into issues with incompatible libraries. I’m not sure how it happens that packages in the archive end up this way. One solution I’ve been trying with some success is to checkout the pkgsrc that corresponds to the archive I want to use and build the packages that are of interest to me using a pbulk build setup. However, that exposes another issues that has me completely stumped - some packages that exist in the package archive fail to build on my system. One good example is if I check out the sources for pkgsrc-2018Q4 and try building the meta-pkg xfce4 it fails, but the binary archive for it exists on the server. Assuming the sources are the same for both my build and the one that was posted on the server then the question becomes, what’s different in the two build setups? I’m beginning to suspect that maybe the packages in the 2018Q4 archive on the server were not built under a stock NetBSD 8.0 system, or there are some special setups used that aren’t reflected in the pkg build setup. It might be interesting to compare the contents of mk.conf for example it see if that might explain the differences.
Re: libstdc++.so.7 is missing
Ok!
Step by step...
My repo conf line points to
http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/
it has been like this since I installed the system.
I know .../8.0/... is a symlink to the corresponding .../8.0_2018Q/...
Yesterday, I did
pkgin update
pkgin upgrade
pkgin full-upgrade
I was running firefox 62 on the 2018Q3 and now the latest version is 52.
I removed firefox and installed Midori.
When launching Midori from xterm I get the mentioned error. But, now I
can't go back to firefox simply because it doesn't exist.
Something with the builds must have gone wrong.
Here, http://mail-index.netbsd.org/pkgsrc-users/2018/12/30/msg027871.html
it clearly stated firefox 64...
Den tor 17 jan. 2019 14:48 skrev Edgar Pettijohn :
>
> On Jan 17, 2019 7:35 AM, Pedro Pinho wrote:
> >
> > Nope, this was/is 8.0 from the start.
> > I've done a full upgrade from Q3 to Q4 that's all. I know I shouldn't
> mix quaternary releases.
> > Please, have a look at
> http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ and you
> will see that packages are missing, firefox was an example.
> >
> > While we are at it... is there a pkgin command to remove every installed
> package?
>
> I don't think so. I do it like so:
>
> pkg_info | awk '{print $1}' > pkgs.txt
>
> remove pkgin from the list
>
> while read -r pkg; do
> pkgin remove $pkg
> done < pkgs.txt
>
> forgive errors. I'm writing from memory on my phone.
>
> It's been awhile since I've done this so can't make any guarantee.
>
> Edgar
> I have a feeling this may be needed if I would need to go back to the Q3
> release.
> > Although, I would prefer if Q4 would work as I would like to use Midori
> as main browser. After all, I've requested it on WIP a month or so ago.
> >
> > Den 17 jan. 2019 14:24 skrev "Greg Troxel" :
> >>
> >> What version of NetBSD are you running? If 7, you will almost certainly
> >> be better off upgrading to 8.
> >>
> >> Generally, all packages need to be from a consistent build. If you
> >> have seme from one branch and some from another, that can be trouble.
> >> But, your problem sounds like upgrading from netbsd-7 to netbsd-8 and
> >> having some packages from netbsd-7. Or maybe all; did you change your
> >> pkgin repo line?
> >>
> >>
> >>
> >
>
Re: libstdc++.so.7 is missing
On Jan 17, 2019 7:35 AM, Pedro Pinho wrote:
>
> Nope, this was/is 8.0 from the start.
> I've done a full upgrade from Q3 to Q4 that's all. I know I shouldn't mix quaternary releases.
> Please, have a look at http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ and you will see that packages are missing, firefox was an example.
>
> While we are at it... is there a pkgin command to remove every installed package?
I don't think so. I do it like so:
pkg_info | awk '{print $1}' > pkgs.txt
remove pkgin from the list
while read -r pkg; do
pkgin remove $pkg
done < pkgs.txt
forgive errors. I'm writing from memory on my phone.
It's been awhile since I've done this so can't make any guarantee.
Edgar
I have a feeling this may be needed if I would need to go back to the Q3 release.
> Although, I would prefer if Q4 would work as I would like to use Midori as main browser. After all, I've requested it on WIP a month or so ago.
>
> Den 17 jan. 2019 14:24 skrev "Greg Troxel" :
>>
>> What version of NetBSD are you running? If 7, you will almost certainly
>> be better off upgrading to 8.
>>
>> Generally, all packages need to be from a consistent build. If you
>> have seme from one branch and some from another, that can be trouble.
>> But, your problem sounds like upgrading from netbsd-7 to netbsd-8 and
>> having some packages from netbsd-7. Or maybe all; did you change your
>> pkgin repo line?
>>
>>
>>
>
Re: libstdc++.so.7 is missing
Martin Husemann écrit : > On Thu, Jan 17, 2019 at 02:35:34PM +0100, Pedro Pinho wrote: > > Nope, this was/is 8.0 from the start. > > And you did not have any pkgs pre-installed? > > The problem is that 8.0 had libstdc++.so.8.0, and nothing compiled for 8.0 > should ever refer to libstdc++.so.7. It depends where this libstdc++.so.7 is. On my system (8.0 from the start also), gcc packages install several versions of libstdc++.so.7: /usr/pkg/gcc6/lib/libstdc++.so.7 /usr/pkg/gcc6/lib/libstdc++.so.7.22 /usr/pkg/gcc6/lib/libstdc++.so.7.22-gdb.py /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7 /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22 /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22-gdb.py /usr/pkg/gcc8/lib/libstdc++.so.7 /usr/pkg/gcc8/lib/libstdc++.so.7.25 /usr/pkg/gcc8/lib/libstdc++.so.7.25-gdb.py
Re: libstdc++.so.7 is missing
On Thu, Jan 17, 2019 at 02:35:34PM +0100, Pedro Pinho wrote: > Nope, this was/is 8.0 from the start. And you did not have any pkgs pre-installed? The problem is that 8.0 had libstdc++.so.8.0, and nothing compiled for 8.0 should ever refer to libstdc++.so.7. So some pkg you got must have been comipled on an older version of NetBSD. Martin
Re: libstdc++.so.7 is missing
Nope, this was/is 8.0 from the start. I've done a full upgrade from Q3 to Q4 that's all. I know I shouldn't mix quaternary releases. Please, have a look at http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All/ and you will see that packages are missing, firefox was an example. While we are at it... is there a pkgin command to remove every installed package? I have a feeling this may be needed if I would need to go back to the Q3 release. Although, I would prefer if Q4 would work as I would like to use Midori as main browser. After all, I've requested it on WIP a month or so ago. Den 17 jan. 2019 14:24 skrev "Greg Troxel" : What version of NetBSD are you running? If 7, you will almost certainly be better off upgrading to 8. Generally, all packages need to be from a consistent build. If you have seme from one branch and some from another, that can be trouble. But, your problem sounds like upgrading from netbsd-7 to netbsd-8 and having some packages from netbsd-7. Or maybe all; did you change your pkgin repo line?
Re: libstdc++.so.7 is missing
What version of NetBSD are you running? If 7, you will almost certainly be better off upgrading to 8. Generally, all packages need to be from a consistent build. If you have seme from one branch and some from another, that can be trouble. But, your problem sounds like upgrading from netbsd-7 to netbsd-8 and having some packages from netbsd-7. Or maybe all; did you change your pkgin repo line?
Re: libstdc++.so.7 is missing
Sorry about that! amd64 See also this other thread, https://mail-index.netbsd.org/netbsd-users/2019/01/17/msg021986.html Although, on the french mirror (the one I'm using) the pkg list continues after gimp. Still, firefox is at version 52. I was running version 62 from Q3 previously. Thanks Den tor 17 jan. 2019 08:46 skrev Martin Husemann : > On Thu, Jan 17, 2019 at 07:03:33AM +0100, Pedro Pinho wrote: > > Reply to myself and another problem. > > Actually, there's no firefox package with version >52!? > > Wonder if I should point my repo conf back to Q3? Does anyone know what > > went wrong with the package build? > > Give us a hint: what architecture are you using? > > Martin >
Re: libstdc++.so.7 is missing
On Thu, Jan 17, 2019 at 07:03:33AM +0100, Pedro Pinho wrote: > Reply to myself and another problem. > Actually, there's no firefox package with version >52!? > Wonder if I should point my repo conf back to Q3? Does anyone know what > went wrong with the package build? Give us a hint: what architecture are you using? Martin
Re: libstdc++.so.7 is missing
Reply to myself and another problem. Actually, there's no firefox package with version >52!? Wonder if I should point my repo conf back to Q3? Does anyone know what went wrong with the package build? Thanks Den ons 16 jan. 2019 23:12 skrev Pedro Pinho : > Hi all, > I've been waiting for this since pkgsrc Q4 was released... the binaries > are through now! > Now to the problem... > Can't launch a web browser (Firefox or Midori) after updating and > upgrading through pkgin, libstdc++.so.7 not found. > Was this an (too early) update and the package will, eventually, come > through or should I remove and re-install all my packages? > Thx! >
