[gentoo-user] [SOLVED] cmake-3.18.5 build fails
My version of oops programming . I had been playing around with manual build and trying to get it running, using various versions of gcc. I had left an earlier vrsion of gcc selected. Oops. Selecting 9.3.0 fixed the problem. Sorry to have wasted everybody's time. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] cmake-3.18.5 build fails
Hello, On Fri, 12 Feb 2021, Jack wrote: >On 2021.02.12 14:49, Walter Dnes wrote: >> 64-bit Gentoo on a new 12-core machine. The build fails in the compile >> phase. Switching makeopts from -j4 to -j1 didn't help. Build log is >> attached. >The error seems to be at linking: > >/usr/lib/gcc/x86_64-pc-linux-gnu/7.5.0/../../../../x86_64-pc-linux-gnu/bin/ld: >/usr/lib64/libjsoncpp.so: undefined reference to >`std::__cxx11::basic_ostringstream, >std::allocator >::basic_ostringstream()@GLIBCXX_3.4.26' > >/usr/lib64/libjsoncpp.so belongs to dev-libs/jsoncpp. cmake depends on >>=dev-libs/jsoncpp-1.9.2-r2:0= > >I have 1.9.4 installed. (1.9.3 is the only other one I see in Portage.) Is >it possible you have an older version, and the dep needs to be updated? I needs just to be recompiled, I think. With '-std=c++11' or later. Search for 'undefined reference to std::__cxx11::basic_' (no quotes) on your least untrusted search engine, or better, if your search-engine supports the 'site:' parameter, for 'undefined reference to std::__cxx11::basic_ site:gentoo.org' AFAIR, there were both at least one news item and tons of mails/forum-posts about this issue with 'std::__cxx11::basic.*string' stuff. It's that C++ ABI change for all that string related stuff. It all basically boils down to just recompile all your C++ libs using some form of (basic_)string (and all stuff depending on those) using the new cxx11 ABI. ISTR that was rather well communicated in the news items and on this ML. And there's stuff on the wiki, e.g.: https://wiki.gentoo.org/wiki/Upgrading_GCC ISTR there's more specific stuff, but that's the gist of it. Rebuild what depends on libstdc++. IIRC: $ revdep-rebuild -v -p --library /usr/lib/libstdc++.so.5 (change /usr/lib/ to whatever matches your platform and don't forget /usr/lib32 if you do multilib ;) >Also, might it be related to gcc version? I'm currently using 10.2.0-r5 >~amd64. Nah. It's libstdc++ ;) HTH, -dnh -- The only languages that can comfortably be written with the repertoire of US-ASCII happen to be Latin, Swahili, Hawaiian and American English without most typographic frills. It is rumoured that there are more languages in the world. -- Roman Czyborra
Re: [gentoo-user] cmake-3.18.5 build fails
On 2021.02.12 14:49, Walter Dnes wrote: 64-bit Gentoo on a new 12-core machine. The build fails in the compile phase. Switching makeopts from -j4 to -j1 didn't help. Build log is attached. The error seems to be at linking: /usr/lib/gcc/x86_64-pc-linux-gnu/7.5.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libjsoncpp.so: undefined reference to `std::__cxx11::basic_ostringstream, std::allocator >::basic_ostringstream()@GLIBCXX_3.4.26' /usr/lib64/libjsoncpp.so belongs to dev-libs/jsoncpp. cmake depends on >=dev-libs/jsoncpp-1.9.2-r2:0= I have 1.9.4 installed. (1.9.3 is the only other one I see in Portage.) Is it possible you have an older version, and the dep needs to be updated? Also, might it be related to gcc version? I'm currently using 10.2.0-r5 ~amd64. Jack
[gentoo-user] cmake-3.18.5 build fails
64-bit Gentoo on a new 12-core machine. The build fails in the compile phase. Switching makeopts from -j4 to -j1 didn't help. Build log is attached. -- Walter Dnes I don't run "desktop environments"; I run useful applications buildlog.txt.bz2 Description: BZip2 compressed data
[gentoo-user] Re: Chromium Aw, Snap!
On 2021-02-12, Neil Bothwick wrote: > On Fri, 12 Feb 2021 15:10:32 - (UTC), Grant Edwards wrote: > >> What was the error message? > > You'd know if you had seen it. Chromium displays "Aw, snap!" in the > browser window when it barfs on a page. Ah. The most important bit of important bit of information was hidden in the Subject: header. > The full message is the ever so helpful "Aw snap!. something went wrong > when displaying this page". No, I don't think I've ever seen that...
Re: [gentoo-user] Re: Chromium Aw, Snap!
On Fri, 12 Feb 2021 15:10:32 - (UTC), Grant Edwards wrote: > >> > ~/.config/chromium I get this error message immediately after > >> > Chromium comes up. > >> > >> I've never seen that error message. > > > > I get it occasionally, > > What is 'it'? > > What was the error message? You'd know if you had seen it. Chromium displays "Aw, snap!" in the browser window when it barfs on a page. The full message is the ever so helpful "Aw snap!. something went wrong when displaying this page". https://www.bleepstatic.com/images/news/u/1100723/AwSnap.png -- Neil Bothwick Always proofread carefully to see if you any words out. pgpPN0f3PnjQX.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Chromium Aw, Snap!
On 2021-02-12, Neil Bothwick wrote: > On Fri, 12 Feb 2021 13:43:31 - (UTC), Grant Edwards wrote: > >> > since a few days Chromium is broken here. Even deleting >> > ~/.config/chromium I get this error message immediately after >> > Chromium comes up. >> >> I've never seen that error message. > > I get it occasionally, What is 'it'? What was the error message? -- Grant
[gentoo-user] problems with dracut
Hi. I am having problems running dracut 0.51-r2 and 0.50-r2. The problem is that I have two install_items lines like this install_items+= /etc/modprobe.d/zfs.conf install_items+= /etc/systemd/system/initrd-switch-root.service and dracut says permission denied on both of them. They are owned by root and are world readable and containing directories look good. I even did an strace, but did not find where it tried to open those files. I have been using dracut for years and never had this problem till recent versions. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: [gentoo-user] Re: Chromium Aw, Snap!
On Fri, 12 Feb 2021 13:43:31 - (UTC), Grant Edwards wrote: > > since a few days Chromium is broken here. Even deleting > > ~/.config/chromium I get this error message immediately after > > Chromium comes up. > > I've never seen that error message. I get it occasionally, usually after upgrading but not restarting chromium. killall chrome and then restarting chromium clears it up. -- Neil Bothwick / For security reasons, all text in this mail is double-rot13 encrypted. / pgph4QiaCVKHK.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Chromium Aw, Snap!
On 2021-02-12, Helmut Jarausch wrote: > since a few days Chromium is broken here. Even deleting > ~/.config/chromium I get this error message immediately after Chromium > comes up. I've never seen that error message. > I have tried the version 88.0.4324.150 , 89.0.4389.40 and > 90.0.4412.3 > > What might be the reason? Based on the error message, I'd guess your neutrino flux is too high. > Am I the only one with this problem? 7.5 -- Grant
[gentoo-user] Chromium Aw, Snap!
Hi, since a few days Chromium is broken here. Even deleting ~/.config/chromium I get this error message immediately after Chromium comes up. I have tried the version 88.0.4324.150 , 89.0.4389.40 and 90.0.4412.3 What might be the reason? Am I the only one with this problem? Thanks for a hint, Helmut
Re: [gentoo-user] Sharing printers via Cups
On Thursday, 11 February 2021 20:32:47 GMT Dan Egli wrote: > On 2/11/2021 7:05 AM, Michael wrote: > > On Wednesday, 10 February 2021 23:03:18 GMT Dan Egli wrote: > >> On 2/10/2021 4:30 AM, Michael wrote: > >>> This is how I understand the printing process ought to work in your use > >>> case: > >>> > >>> The Samba server, Athena, will use the MSWindows Network Printer > >>> identified as "Windows Printer via SAMBA" in its CUPS GUI. > >>> > >>> Printing jobs will be submitted from Athena's CUPS to the MSWindows PC & > >>> its attached printer, via the corresponding smb:// URI. CUPS which will > >>> use the Samba server on Athena to authenticate and send the data for > >>> printing to the MSWindows PC and its shared printer. > >>> > >>> The same process will need to be followed by Janus; i.e. the CUPS server > >>> on Janus will have to use the same smb:// URI to submit the data to be > >>> printed to Athena's Samba server and as long as authentication is > >>> successful Athena will forward it to the Windows PC. > >> > >> Forgive me, but if I use the SAME url, then it's not Athena acting as > >> the print server, it's the windows client that the printer is hooked up > >> to. > > > > Sorry, I meant to say on Janus use the smb://Athena/ URI and see > > if Athena then forwards the request via the shared Samba printer service > > onward to the MSWindows PC. Of course if you try to print directly to > > the MSWindows PC with smb://IRIS/ it will work, just as it works > > from Athena - but that's not what you're after. > > That may work. I guess I'm just a bit worried about back and forth. i.e. > Janus tries to print, then Athena asks for permission to let it happen, > and that request goes right back to Janus. I'm VERY unfamiliar with AD > so I can't be 100% certain this will work. I can't see any reason why it > wouldn't, but that's not the same thing as saying there ISN'T a reason > why it wouldn't work. The transaction for AD authentication to access the domain is taking place over different applications, threads, protocols and ports to those used for printing. There should be no confusion. [snip ...] > > The shared printer advertised by CUPS in Athena should pop up on > > Janus as an available printer via mDNS. > > I know nothing of mDNS. mDNS (multicast DNS) is a protocol used to resolve hostnames to IP addresses in LANs without the need to use a local DNS server. Client devices trying to resolve a name send UDP multicasts using port 5353 over the LAN subnet to ask for a named host to identify itself. The target host responds with its IP address and the client updates its mDNS cache. Linux, Apple and Windows 10 use mDNS to discover printers. If you see zeroconf, avahi, or Apple's Bonjour service, they are all referring to this mechanism. If you use IP addresses to manually configure printer server/clients, then this service is not necessary. Samba uses the native MSWindows 'Active Directory Domain Services' over TCP port 445 to resolve IP addresses when printing over Samba. > I tried IPP to no avail, but then again perhaps > I formed the URLs wrong. I tried ipp://athena/ipp/ and it > didn't work. I tried http/https mode too. That ALMOST worked. When you select the HTTP protocol it still sends IPP packets in MIME format. I'm not sure of the difference between the two - I guess IPP is native to CUPS and most/all printers. > But I get > an error on Janus saying "Filter Failed" and a lot of messages in my > error_log (debug mode) that really make no sense to me. Here's a > sample. I'll put the full log on my web server if you want to see it. > It's 77k nearly with debug turned on and that's only for trying to print > ONE test page and failing. The url is > https://www.newideatest.site/cups_error_log I had a quick look, this is what I see: Your client sends IPP commands over HTTP to Athena. CUPS server on Athena accepts these and processes them. So the comms appear to be working fine between the two. :-) Then we have this on line 292: D [11/Feb/2021:13:08:36 -0700] [Job 11] hpcups (application/vnd.cups-raster to printer/ENVY, cost 0) This is the hplip printer driver in action, using a MIME format for CUPS to transmit and print raster imaged pages. Question: Why is this driver in play? Even if the physical printer is an HP, it is neither connected to Janus, nor Athena. On lines 331 & 332: I [11/Feb/2021:13:08:36 -0700] [Job 11] Started filter /usr/libexec/cups/ filter/hpcups (PID 92258) I [11/Feb/2021:13:08:36 -0700] [Job 11] Started backend /usr/libexec/cups/ backend/smb (PID 92259) Although the CUPS back end on Athena is using SMB - as it should, the input filter is hpcups. Then on lines 461, 462 we have the outcome of using the wrong filter: D [11/Feb/2021:13:08:39 -0700] [Job 11] prnt/hpcups/HPCupsFilter.cpp 581: cupsRasterOpen failed, fd = 5 D [11/Feb/2021:13:08:39 -0700] [Job 11] PID 92258 (/usr/libexec/cups/filter/ hpcups) stopped with status
