[gentoo-user] Re: Valgrind not seeing debug symbols
> On Aug 19, 2018, at 12:21, Andrew Udvare wrote: > > Hi all, > > I have this project https://github.com/Tatsh/gcrud and it uses a very > standard build process with CMake, but for some reason Valgrind never > sees the debug symbols. I created a basic Gentoo machine with a Vagrant box and set up a mini environment to test if it is just my machine. The symbols show up on the Vagrant box. It could be a bad version of Valgrind on my end but I haven’t compared the environments. My main system has something wrong. — Andrew
Re: [gentoo-user] python-3.6.5 rebuild fails on new install
Seems to be a known issue and probably fixed in gcc-7.4.0: https://bugs.gentoo.org/662208 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83317 This error is also used in the Gentoo gcc internal compiler error reporting wiki page: https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide Am Mo., 20. Aug. 2018 um 08:23 Uhr schrieb Adam Carter < adamcart...@gmail.com>: > I just tried with MAKEOPTS="-j1" and got the same failure output at >> the same place. I normally run with the number equal to the number of >> cores. On this notebook MAKEOPTS="-j2". Are there any other >> memory-conserving tweaks available? >> > > I guess you've stopped all the non-essential services and programs. > > Does top or free -m confirm that you're running out of space? If so, you > could create a temporary swap file on an existing filesystem ( > https://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/) or make a USB > drive into some temporary swap get you through the build > >
Re: [gentoo-user] python-3.6.5 rebuild fails on new install
> > I just tried with MAKEOPTS="-j1" and got the same failure output at > the same place. I normally run with the number equal to the number of > cores. On this notebook MAKEOPTS="-j2". Are there any other > memory-conserving tweaks available? > I guess you've stopped all the non-essential services and programs. Does top or free -m confirm that you're running out of space? If so, you could create a temporary swap file on an existing filesystem ( https://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/) or make a USB drive into some temporary swap get you through the build
Re: [gentoo-user] OT: latest longterm kernel.org patches are unsigned
Hi, kernel.org won’t provide the signatures anymore. I was politely pointed to the following site via IRC but got no reason for it. https://www.kernel.org/category/site-news.html --- Quote --- No future PGP signatures on patches and changelogs For legacy purposes, we will continue to provide pre-generated changelogs and patches (both to the previous mainline and incremental patches to previous stable). However, from now on they will be generated by automated processes and will no longer carry detached PGP signatures. If you require cryptographically verified patches, please generate them directly from the stable git repository after verifying the PGP signatures on the tags using git verify-tag. --- EOQ --- Am Freitag, 17. August 2018, 18:07:13 CEST schrieb Ian Zimmerman: > If you browse this URL: > > https://cdn.kernel.org/pub/linux/kernel/v4.x/ > > you'll see that for each 4.14 patch up to 4.14.58 there is a > cooresponding GPG signature file: > > patch-4.14.58.sign 25-Jul-2018 09:28 833 > patch-4.14.58.xz 25-Jul-2018 09:28 1M > > etc. > > But starting with 4.14.59, there are no .sign files. Why? Is this a > bug, and if so, where do I report it? > > This breaks my lovingly duct-taped kernel update infrastructure ... -- GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B' Nils Freydank signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] python-3.6.5 rebuild fails on new install
On Sun, Aug 19, 2018 at 10:49:27AM +0100, Mick wrote > Some ebuilds, I have chromium in mind here, can chew up all your > RAM and then start thrashing swap continuously. To make matters > worse in pre-empting this, they only do it for a few versions, then > revert to better managed memory usage. On a box with 4G RAM I set > MAKEOPTS="-j2 -l2" for such troublesome packages and swap usage is > kept within normal limits. I just tried with MAKEOPTS="-j1" and got the same failure output at the same place. I normally run with the number equal to the number of cores. On this notebook MAKEOPTS="-j2". Are there any other memory-conserving tweaks available? > I think the message "[drm] HPD interrupt storm" refers to some old > kernel bug, but it could be a regression. Which kernel are you using? 4.14.61-gentoo [thimk][root][~] uname -a Linux thimk 4.14.61-gentoo #3 SMP Fri Aug 17 04:14:29 EDT 2018 i686 Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] kdevelop broken (llvm slot issue)
Am Sonntag, 19. August 2018, 17:57:55 CEST schrieb Andrew Udvare: > > I am not having issues with KDevelop with Clang support and I have > everything on the latest version: > > LLVM 6.0.1-r1 libffi ncurses > Clang 6.0.1 +static-analyzer LLVM_TARGETS="AMDGPU BPF NVPTX X86" > KDevelop 5.2.3 gdbui hex plasma qmake welcomepage > kDevelop-php 5.2.3 > kdevelop-python 5.2.3 > Mesa 18.* classic dri3 egl gallium gbm gles2 llvm wayland > Thanks for the quick response. Upgrading to mesa 18 solves the problem. Regards Alex
[gentoo-user] Valgrind not seeing debug symbols
Hi all, I have this project https://github.com/Tatsh/gcrud and it uses a very standard build process with CMake, but for some reason Valgrind never sees the debug symbols. The debug symbols are definitely there as GDB can see them, but I have not been able to figure out why Valgrind can't. I have the latest version of Valgrind which supports compressed debug symbols. I even created an ebuild to see if Portage does the magic I need: https://github.com/Tatsh/tatsh-overlay/blob/master/app-portage/gcrud/gcrud-.ebuild Portage does not generate the debug symbols file I expect to see. In all cases I am building with -ggdb. I have FEATURES="splitdebug compressdebug" and still no debug symbols: $ valgrind -v --leak-check=full gcrud ... ==16662== 1,120,873 bytes in 16,784 blocks are definitely lost in loss record 41 of 41 ==16662==at 0x4C30D6F: realloc (vg_replace_malloc.c:785) ==16662==by 0x5266BA5: __vasprintf_chk (vasprintf_chk.c:88) ==16662==by 0x4ECA438: vasprintf (stdio2.h:210) ==16662==by 0x4ECA438: g_vasprintf (gprintf.c:316) ==16662==by 0x4EA482C: g_strdup_vprintf (gstrfuncs.c:514) ==16662==by 0x4EA48F0: g_strdup_printf (gstrfuncs.c:540) ==16662==by 0x10AB1A: ??? (in /usr/bin/gcrud) ==16662==by 0x10C5B9: ??? (in /usr/bin/gcrud) ==16662== ==16662== LEAK SUMMARY: ==16662==definitely lost: 1,919,735 bytes in 30,221 blocks I can tell it's a call to g_strdup_printf() but I sure would like to know what line number since there are a few times it's called. I also tried the same build process but with Clang. Tried -gdwarf-4/5 and -Og -ggdb. I also don't understand why other libraries are working fine. Appreciate any help. Thanks -- Andrew signature.asc Description: OpenPGP digital signature
[gentoo-user] kdevelop broken (llvm slot issue)
On 19/08/18 11:21, Alexander Puchmayr wrote: > > This issue is covered by bug https://bugs.gentoo.org/651658, which is open > since March 2018 and no progress since also March 2018. > > It seems as if multiple slots of llvm cause the problems. mesa pulls in llvm: > 5, while other programs pull in llvm:6 (via clang:6) > > Does anyone have an idea how to get a working kdevelop again? I think you have to not have multiple LLVM/Clang installations, unfortunately. That's what the bug indicates. I am not having issues with KDevelop with Clang support and I have everything on the latest version: LLVM 6.0.1-r1 Clang 6.0.1 KDevelop 5.2.3 gdbui hex plasma qmake welcomepage kDevelop-php 5.2.3 kdevelop-python 5.2.3 I would just ensure everything is built against one version of Clang/LLVM and get rid of the other versions from the machine. If you really don't need the Clang features (if you are using KDevelop for non-C/C++), you can disable it at runtime: /usr/bin/env KDEV_DISABLE_PLUGINS=kdevclangsupport kdevelop %u I have this is in my menu because KDevelop gets dumb with QML JS vs JavaScript for me, making KDevelop nearly impossible to use with Node projec -- Andrew signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] kdevelop broken (llvm slot issue)
On 19/08/18 11:21, Alexander Puchmayr wrote: > > This issue is covered by bug https://bugs.gentoo.org/651658, which is open > since March 2018 and no progress since also March 2018. > > It seems as if multiple slots of llvm cause the problems. mesa pulls in llvm: > 5, while other programs pull in llvm:6 (via clang:6) > > Does anyone have an idea how to get a working kdevelop again? I think you have to not have multiple LLVM/Clang installations, unfortunately. That's what the bug indicates. I am not having issues with KDevelop with Clang support and I have everything on the latest version: LLVM 6.0.1-r1 libffi ncurses Clang 6.0.1 +static-analyzer LLVM_TARGETS="AMDGPU BPF NVPTX X86" KDevelop 5.2.3 gdbui hex plasma qmake welcomepage kDevelop-php 5.2.3 kdevelop-python 5.2.3 Mesa 18.* classic dri3 egl gallium gbm gles2 llvm wayland Most of the above are defaults. I would just ensure everything is built against one version of Clang/LLVM and get rid of the other versions from the machine. If you really don't need the Clang features (if you are using KDevelop for non-C/C++), you can disable it at runtime: /usr/bin/env KDEV_DISABLE_PLUGINS=kdevclangsupport kdevelop %u You have to kill all KDevelop instances completely for this to work. I have this is in my menu because KDevelop gets dumb with QML JS vs JavaScript for me, making KDevelop nearly impossible to use with Node projects. -- Andrew signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: kdevelop broken (llvm slot issue)
On 19/08/18 18:21, Alexander Puchmayr wrote: After recent upgrades of mesa, llvm, clang etc kdevelop does not work anymore. It crashes immediately after start with errors [...] It seems as if multiple slots of llvm cause the problems. mesa pulls in llvm: 5, while other programs pull in llvm:6 (via clang:6) Does anyone have an idea how to get a working kdevelop again? Have you tried disabling the llvm USE flag of mesa? AFAIK it's only used for the software rendering backend, which you probably don't need. Try disabling it, and then do: emerge -auDN --changed-deps --with-bdeps=y @world followed by: emerge -a --depclean which should unmerge llvm:5.
[gentoo-user] kdevelop broken (llvm slot issue)
Hi there, After recent upgrades of mesa, llvm, clang etc kdevelop does not work anymore. It crashes immediately after start with errors : CommandLine Error: Option 'help-list' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options This issue is covered by bug https://bugs.gentoo.org/651658, which is open since March 2018 and no progress since also March 2018. It seems as if multiple slots of llvm cause the problems. mesa pulls in llvm: 5, while other programs pull in llvm:6 (via clang:6) Does anyone have an idea how to get a working kdevelop again? Regards Alex
Re: [gentoo-user] python-3.6.5 rebuild fails on new install
On Sunday, 19 August 2018 02:56:13 BST Walter Dnes wrote: > On Sat, Aug 18, 2018 at 03:27:27PM -0400, Mike Gilbert wrote > > > On Fri, Aug 17, 2018 at 8:58 PM Walter Dnes wrote: > > > I'm re-purposing a Lenovo T400 notebook (CORE2 and 3 gigs ram) with a > > > > > > 32-bit Gentoo install. I try to do "emerge -e @system" early in the > > > install, when there's under 200 packages. Anyhow, python 3.6.5 is not > > > rebuilding. I've put in all the "final" USE flags for the system. The > > > buildlog is attached (gzipped). > > > > The compiler was killed with signal SIGSEGV. You probably ran out of > > memory or some similar problem. Check dmesg. > > That would be worrisome. This is an off-lease Lenovo with 3 gigs of > ram, and 6.8 gigs of swap. At this point of the install, I haven't even > built X, so there's no GUI running. dmesg output is attached. The last > line mentions something about python3.6m. This is an informational message and would only be worrisome if it reported 0 bytes left. You can switch if off by disabling CONFIG_DEBUG_STACK_USAGE in the kernel. Some ebuilds, I have chromium in mind here, can chew up all your RAM and then start thrashing swap continuously. To make matters worse in pre-empting this, they only do it for a few versions, then revert to better managed memory usage. On a box with 4G RAM I set MAKEOPTS="-j2 -l2" for such troublesome packages and swap usage is kept within normal limits. I think the message "[drm] HPD interrupt storm" refers to some old kernel bug, but it could be a regression. Which kernel are you using? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] python-3.6.5 rebuild fails on new install
I think the memory is only used in the context of OpenGL (or when it's used for computing like with OpenCL). I am sure you won't run out of memory when compiling on a pure text console because of the grahics driver. Am So., 19. Aug. 2018 um 05:27 Uhr schrieb Walter Dnes < waltd...@waltdnes.org>: > One interesting item early on in dmesg... > > [0.173494] [drm] Memory usable by graphics device = 2048M > [0.173591] [drm] Replacing VGA console driver > > Would the "graphics driver" be capable of using up 2 gigs of ram in > a pure text console? On a 3-gig machine, that would be very bad. > > -- > Walter Dnes > I don't run "desktop environments"; I run useful applications > >
