I was using a script (with the rbind and make-rslave mounts) to get into the chroot. I used to have a 32bit chroot and forgot I have linux32 in the script!
This works for me: menuentry "gentoo-install-i686" { # set cmdline="dokeymap looptype=squashfs loop=/image.squashfs cdroot" set iso=/boot/gin.iso bootoptions="isoboot=$iso root=/dev/ram0 init=/linuxrc dokeymap looptype=squashfs loop=/image.squashfs cdroot vga=791" loopback ...
Actually, I think I may have a theory why some packages don't create binary packages. It's specifically caused by the a bit special configuration of the host serving the packages I have.
Possibly those non-@system packages which depend directly on packages in @system will not create binary packages ...
You mentioned a fakeroot. Do you mean you are building in a chroot environment? If yes, then the Portage configuration in the chroot is what matters, but you showed us the host configuration. To clarify, the host is the fakeroot machine (the client is not). I do not want to run Gentoo on the host ...
Thanks for your suggestion but glibc certainly is not (only) a build dependency. Neither are any of the packages I've mentioned individually, they are all required also as run-time dependencies (or at least pulled in on the client).
There might be some pattern relating to what is / is not in ...
I have a binary package host (in a fakeroot) to create packages for a slow machine. For some reason, binary packages are often not created after running emerge.
Of course I should have posted emerge --info: Portage 2.3.99 (python 3.7.7-final-0, default/linux/x86/17.0, gcc-9.3.0, glibc-2.30-r8, 5.7.6-zen1-1-zen i686) ================================================================= System uname: Linux-5.7.6-zen1-1-zen-i686-Intel-R-_Core-TM-_i7-4790K_CPU_@_4 ...
portage and quickpkg create the files as root:root and with permissions -rw-r---. How are you using quickpkg? Mostly I don't use quickpkg. I just emerge the packages and have "buildpkg" in the FEATURES. I just mentioned it in case it would be expected them to have different behavior. I'm not aware ...
I've set up a binary package host according to this page .
In /etc/profile umask is set to: /etc/profile:19:umask 022
I access the packages via SSH. This works fine, except portage and quickpkg create the files as root:root and with permissions -rw-r---. Of course, this won't work with a ...
It would be good to nail down the illegal instruction and at what line of code it appears for the bug report. It would be a good exercise for the OP to re-compile eix with -O0 and debug support, verify that the bug still exists (trivially running "eix -e eix" on ...
Both the build lines for the failing file are the same. i486-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -DSYSCONFDIR="/etc" -DLOCALEDIR="/usr/share/locale" -fdata-sections -ffunction-sections -mindirect-branch=thunk -mfunction-return=thunk -fcf-protection=full -fstack-clash-protection -D_FORTIFY ...
Ideally, a trivial test case is required. You have a file in a program. That's a great help to debugging. A function would be even better and a line of code better still.
Include in your bug report the entire content of the file that causes the fail. Also ...
Your results are identical to mine (just confirming)!
I believe I could of course install 7.3.0 (on all of the boxes), and rebuild relevant toolchain (from the top of my head, I'm not sure do I need bootstrap.sh or is emerge -1 bintools glibc enough... reading trough https://wiki ...
Didn't you say above that building on the k6 box worked? What was your compiler, binutils, and glibc versions and exact CFLAGS, if you didn't give them above. IIRC, all building on the k6 worked and all building off the k-6 didn't work. Unfortunately I don't have an Intel chip to work with. My only ...
Thanks for your input. I will remove -fomit-frame-pointer and try debugging again, and get back to this.
I'm suspecting a bug in qemu or the qemu setup. If you will read my previous post, you'll notice this has been reproduced in various different environments, such as a 32 bit chroot ...
#3 0x08064771 in _start () at eixTk/stringutils.cc:645 That file contains 646 lines, so I'm not sure that it points to the function that's failing, just the file.
Yes, I know. I was assuming gdb is working as intended, are you saying it should print something else? That line is ...
From the slave and the target compiling locally . Also, environment the slave .
FWIW, I've also compared the environments of the resulting binary packages of eix to locally (on target) compiled, and I've seen nothing out of order ...
Ok, I still haven't given up on this, although got other things to do so things are progressing (if you can call this progress) slowly!
Since my last post, I've installed Gentoo in a Pentium MMX VM in Qemu (to rule out a real or a virtual i686 polluting the environment). However, I still get ...
EDIT: Nevermind this post! I was confused by virtual/* -etc and some packages just emerge crazy fast on an i7. Leaving it here just for completeness sake...
Ok, I've noticed something peculiar. Not sure how I didn't notice this before!
I missed that yours was not. I probably missed a hyperlink in one of your posts because I need eye surgery and for me, the contrast on hyperlinks in this forum is very poor.
These kind of threads are difficult to follow as it is. The state the problem was at the beginning is not the same anomore ...