[gentoo-user] sys-libs/e2fsprogs-libs causing sandbox violation in /root/.ccache?

[P Levine]

Th
​is has been going on for the last few months.  It only seems to happen for
sys-libs/e2fsprogs-libs.  I haven't filed a bug yet as I'm unsure if there
is something I'm overlooking on my end.  I can delete /root/.ccache and
remerge and it seems to be fine after that, but while updating the world a
few weeks later it sporadically returns.

The relevant part of the build:

make[1]: 'compile_et' is up to date.
> make[1]: Leaving directory
> '/var/tmp/portage/sys-libs/e2fsprogs-libs-1.44.1/work/e2fsprogs-libs-1.44.1-ab
> i_x86_64.amd64/lib/et'
> making all in lib/et
> * ACCESS DENIED:  utimes:   /root/.ccache
> * ACCESS DENIED:  mkdir:/root/.ccache/3
> make[1]: Entering directory
> '/var/tmp/portage/sys-libs/e2fsprogs-libs-1.44.1/work/e2fsprogs-libs-1.44.1-a
> bi_x86_64.amd64/lib/et'
> make[1]: Nothing to be done for 'all'.
> make[1]: Leaving directory
> '/var/tmp/portage/sys-libs/e2fsprogs-libs-1.44.1/work/e2fsprogs-libs-1.44.1-ab
> i_x86_64.amd64/lib/et'


​And the sandbox report:​

* --- ACCESS VIOLATION SUMMARY
> ---
> * LOG FILE: "/var/log/sandbox/sandbox-28430.log"
> *
> VERSION 1.0
> FORMAT: F - Function called
> FORMAT: S - Access Status
> FORMAT: P - Path as passed to function
> FORMAT: A - Absolute Path (not canonical)
> FORMAT: R - Canonical Path
> FORMAT: C - Command Line
>
> F: utimes
> S: deny
> P: /root/.ccache
> A: /root/.ccache
> R: /root/.ccache
> C: x86_64-pc-linux-gnu-gcc -x c -v -c /dev/null -o /dev/null
> F: mkdir
> S: deny
> P: /root/.ccache/3
> A: /root/.ccache/3
> R: /root/.ccache/3
> C: x86_64-pc-linux-gnu-gcc -x c -v -c /dev/null -o /dev/null
> *
> 


Has anyone else run into sporadic build failures like this?

[gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Ian Zimmerman]

On 2018-03-28 16:09, Grant Taylor wrote:

> The point being, NBD / AoE / iSCSI are SAN technologies and not
> conducive for multiple clients to access at the same time (without a
> clustered file system).  Unlike NFS which is safe for multiple clients
> to access at the same time.  So, having multiple distributed build
> machines sort of necessitates NFS (or a clustered file system).

That's quite true.  As I wrote, in my case the build is not distributed,
just the storage; and the server has enough storage for me to dedicate
another part of it to serve as a remote device for another client,
should it be needed.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Grant Taylor]

On 03/28/2018 03:53 PM, Ian Zimmerman wrote:
Well, that's too many 3-letter acronyms for me   It is lower level, yes. 
All the filesystem code is on the client; the server only handles requests 
of the form "here's the new contents of block 1234, and be sure to tell 
me when it's safely on disk".


Fair enough.

The point being, NBD / AoE / iSCSI are SAN technologies and not 
conducive for multiple clients to access at the same time (without a 
clustered file system).  Unlike NFS which is safe for multiple clients 
to access at the same time.  So, having multiple distributed build 
machines sort of necessitates NFS (or a clustered file system).




--
Grant. . . .
unix || die

[gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Ian Zimmerman]

On 2018-03-28 15:08, Grant Taylor wrote:

> Doesn't NBD (iSCSI and ATA over Ethernet) show up more like SAN
> compared to NFS which is NAS?

Well, that's too many 3-letter acronyms for me ;-)  It is lower level,
yes.  All the filesystem code is on the client; the server only handles
requests of the form "here's the new contents of block 1234, and be sure
to tell me when it's safely on disk".

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Grant Taylor]

On 03/28/2018 02:51 PM, Ian Zimmerman wrote:

NBD (Network Block Device) may be an alternative to NFS in some situations.


Doesn't NBD (iSCSI and ATA over Ethernet) show up more like SAN compared 
to NFS which is NAS?




--
Grant. . . .
unix || die

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[thelma]

On 03/28/2018 12:08 PM, the...@sys-concept.com wrote:
> On 03/28/2018 10:40 AM, Peter Humphrey wrote:
>> On Wednesday, 28 March 2018 16:14:49 BST the...@sys-concept.com wrote:
>>> On 03/28/2018 01:32 AM, Peter Humphrey wrote:
>> [...]
 I have a similar system, but Atom N270. I wouldn't want to compile much on
 it, and certainly not GCC. I NFS-export its $PORTDIR to this much more
 powerful box, do the emerging here and then just install packages on the
 Atom. Still not exactly fast, but incomparably better.
>>>
>>> I should have done it as well, it is a bit too late I have only
>>> 45-packages left to compile out of 710.
>>> Is it better use NFS or distcc?
>>> Do you have a good link how to do it with: "NFS-export  $PORTDIR"
>>
>> I think NFS may be simpler to operate, but that may be because I'm more
>> familiar with it. You just need something like this in the Atom's /etc/
>> exports: /usr/portage 
>> 192.168.1.5(rw,no_subtree_check,anonuid=250,anongid=250,no_wdelay)
>>
>> That IP address is the big beast host, and of course 250 is the portage user.
>>
>> I don't know of a guide on the web, but basically, the method is to construct
>> a 32-bit chroot on your host system and install a mirror of your Atom system
>> in it. Copy your Atom's /etc/portage directory into the chroot and adjust
>> things like --jobs to suit the chroot host, but make sure all the USE flags
>> are the same as on the Atom. It'll take an hour or two to build the system,
>> but you only have to do it once, and of course it'll be done at the speed of
>> your host machine. You don't need to keep running etc-update or equivalent;
>> just build the binaries.
>>
>> My chroot is /mnt/atom and this script starts it ready to chroot into:
>>
>> $ cat /etc/init.d/atom
>> #!/sbin/openrc-run
>>
>> depend() {
>>need localmount
>>need bootmisc
>> }
>>
>> start() {
>> ebegin "Mounting 32-bit chroot dirs under /mnt/atom"
>> mount -t proc /proc /mnt/atom/proc
>> mount --rbind /dev /mnt/atom/dev
>> mount --rbind /sys /mnt/atom/sys
>> mount -t tmpfs tmpfs -o noatime,nosuid,nodev,noexec,mode=1777 
>> /mnt/atom/tmp
>> mount -t tmpfs tmpfs -o noatime,uid=portage,gid=portage,mode=0775 
>> /mnt/atom/var/tmp/portage
>> mount -t nfs -o vers=3 192.168.1.2:/usr/portage /mnt/atom/usr/portage
>> rm -f /mnt/atom/etc/mtab
>> cp /etc/mtab.atom /mnt/atom/etc/mtab
>> eend $? "Error mounting 32-bit chroot directories"
>> }
>>
>> stop() {
>> ebegin "Unmounting 32-bit /mnt/atom chroot dirs"
>> rm /mnt/atom/etc/mtab
>> ln -s /proc/self/mounts /mnt/atom/etc/mtab
>> umount -R /mnt/atom
>> mount /mnt/atom
>> }
>>
>> You may prefer not to bother with tmpfs, but I have 32GB RAM on my host, so
>> it's efficient here. That IP address is the Atom machine.
>>
>> No doubt someone more skilled than me at bash scripting could improve on my
>> script; suggestions welcome.
>>
>> After updating the chroot you can emerge -k or -K on your Atom machine, after
>> syncing which will now be the most time-consuming part of the operation.
>>
>> Let me know if anything isn't clear.
>>
>> Thanks to Neil Bothwick, who showed me how to do this several years ago.
> 
> I will try do it but I'm trying to decipher the code your wrote :-)
> My atom-330 is 64-bit.
> I think your approach was discussed in this forum topic:
> https://forums.gentoo.org/viewtopic-p-6817608.html#6817608
> 
> ---copy
> #!/bin/sh
> 
> HOST=${0##*/}
> HOST=${HOST#*-}
> 
> mkdir -p --mode=0755 /mnt/${HOST}
> 
> mount -t nfs -o rw,intr,noatime,actimeo=60,vers=4,fsc ${HOST}:/ /mnt/${HOST}
> mount --bind /dev /mnt/${HOST}/dev
> mount --bind /dev/shm /mnt/${HOST}/dev/shm
> mount --bind /proc /mnt/${HOST}/proc
> mount --bind /sys /mnt/${HOST}/sys
> mount --bind /usr/portage /mnt/${HOST}/usr/portage
> mount --bind /usr/local/portage /mnt/${HOST}/usr/local/portage
> mount --bind /var/tmp/portage /mnt/${HOST}/var/tmp/portage
> 
> env -i - HOME="/root" TERM="$TERM" chroot /mnt/${HOST} /bin/bash -l
> 
> umount /mnt/${HOST}/dev/shm
> umount /mnt/${HOST}/dev
> umount /mnt/${HOST}/proc
> umount /mnt/${HOST}/sys
> umount /mnt/${HOST}/usr/portage
> umount /mnt/${HOST}/usr/local/portage
> umount /mnt/${HOST}/var/tmp/portage
> umount /mnt/${HOST}
> --end copy--

Can anybody explain what these two line do in the above script?
HOST=${0##*/}
HOST=${HOST#*-}

--
Thelma

[gentoo-user] Re: gcc-6.4.0-r1::gentoo failed (compile phase)

[Ian Zimmerman]

On 2018-03-28 17:40, Peter Humphrey wrote:

> I think NFS may be simpler to operate, but that may be because I'm
> more familiar with it. You just need something like this in the Atom's
> /etc/ exports: /usr/portage
> 192.168.1.5(rw,no_subtree_check,anonuid=250,anongid=250,no_wdelay)

NBD (Network Block Device) may be an alternative to NFS in some situations.

I now use it for /var/tmp/portage on my storage-poor machine.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[thelma]

On 03/28/2018 10:40 AM, Peter Humphrey wrote:
> On Wednesday, 28 March 2018 16:14:49 BST the...@sys-concept.com wrote:
>> On 03/28/2018 01:32 AM, Peter Humphrey wrote:
> [...]
>>> I have a similar system, but Atom N270. I wouldn't want to compile much on
>>> it, and certainly not GCC. I NFS-export its $PORTDIR to this much more
>>> powerful box, do the emerging here and then just install packages on the
>>> Atom. Still not exactly fast, but incomparably better.
>>
>> I should have done it as well, it is a bit too late I have only
>> 45-packages left to compile out of 710.
>> Is it better use NFS or distcc?
>> Do you have a good link how to do it with: "NFS-export  $PORTDIR"
> 
> I think NFS may be simpler to operate, but that may be because I'm more
> familiar with it. You just need something like this in the Atom's /etc/
> exports: /usr/portage 
> 192.168.1.5(rw,no_subtree_check,anonuid=250,anongid=250,no_wdelay)
> 
> That IP address is the big beast host, and of course 250 is the portage user.
> 
> I don't know of a guide on the web, but basically, the method is to construct
> a 32-bit chroot on your host system and install a mirror of your Atom system
> in it. Copy your Atom's /etc/portage directory into the chroot and adjust
> things like --jobs to suit the chroot host, but make sure all the USE flags
> are the same as on the Atom. It'll take an hour or two to build the system,
> but you only have to do it once, and of course it'll be done at the speed of
> your host machine. You don't need to keep running etc-update or equivalent;
> just build the binaries.
> 
> My chroot is /mnt/atom and this script starts it ready to chroot into:
> 
> $ cat /etc/init.d/atom
> #!/sbin/openrc-run
> 
> depend() {
>need localmount
>need bootmisc
> }
> 
> start() {
> ebegin "Mounting 32-bit chroot dirs under /mnt/atom"
> mount -t proc /proc /mnt/atom/proc
> mount --rbind /dev /mnt/atom/dev
> mount --rbind /sys /mnt/atom/sys
> mount -t tmpfs tmpfs -o noatime,nosuid,nodev,noexec,mode=1777 
> /mnt/atom/tmp
> mount -t tmpfs tmpfs -o noatime,uid=portage,gid=portage,mode=0775 
> /mnt/atom/var/tmp/portage
> mount -t nfs -o vers=3 192.168.1.2:/usr/portage /mnt/atom/usr/portage
> rm -f /mnt/atom/etc/mtab
> cp /etc/mtab.atom /mnt/atom/etc/mtab
> eend $? "Error mounting 32-bit chroot directories"
> }
> 
> stop() {
> ebegin "Unmounting 32-bit /mnt/atom chroot dirs"
> rm /mnt/atom/etc/mtab
> ln -s /proc/self/mounts /mnt/atom/etc/mtab
> umount -R /mnt/atom
> mount /mnt/atom
> }
> 
> You may prefer not to bother with tmpfs, but I have 32GB RAM on my host, so
> it's efficient here. That IP address is the Atom machine.
> 
> No doubt someone more skilled than me at bash scripting could improve on my
> script; suggestions welcome.
> 
> After updating the chroot you can emerge -k or -K on your Atom machine, after
> syncing which will now be the most time-consuming part of the operation.
> 
> Let me know if anything isn't clear.
> 
> Thanks to Neil Bothwick, who showed me how to do this several years ago.

I will try do it but I'm trying to decipher the code your wrote :-)
My atom-330 is 64-bit.
I think your approach was discussed in this forum topic:
https://forums.gentoo.org/viewtopic-p-6817608.html#6817608

---copy
#!/bin/sh

HOST=${0##*/}
HOST=${HOST#*-}

mkdir -p --mode=0755 /mnt/${HOST}

mount -t nfs -o rw,intr,noatime,actimeo=60,vers=4,fsc ${HOST}:/ /mnt/${HOST}
mount --bind /dev /mnt/${HOST}/dev
mount --bind /dev/shm /mnt/${HOST}/dev/shm
mount --bind /proc /mnt/${HOST}/proc
mount --bind /sys /mnt/${HOST}/sys
mount --bind /usr/portage /mnt/${HOST}/usr/portage
mount --bind /usr/local/portage /mnt/${HOST}/usr/local/portage
mount --bind /var/tmp/portage /mnt/${HOST}/var/tmp/portage

env -i - HOME="/root" TERM="$TERM" chroot /mnt/${HOST} /bin/bash -l

umount /mnt/${HOST}/dev/shm
umount /mnt/${HOST}/dev
umount /mnt/${HOST}/proc
umount /mnt/${HOST}/sys
umount /mnt/${HOST}/usr/portage
umount /mnt/${HOST}/usr/local/portage
umount /mnt/${HOST}/var/tmp/portage
umount /mnt/${HOST}
--end copy--

In the link above I think the Moderator suggested the change:
...
mkdr /var/tmp/portage/$HOST
mount --bind /var/tmp/portage/$HOST /mnt/${HOST}/var/tmp/portage
---

I'm still searching for a good guid howto over NFS.
It is till not clear to me what to do before or after.  I need to start
with emerging NFS :-/

On my Atom-330 with MAKEOPTS="-j1" it took me over 12-hours to compile
just gcc-6.4.0-r1 :-/
and I have server on that network 8-core AMD with 32-GB or RAM (so I
might as well put it into a good use).

--
Thelma

Re: [gentoo-user] The return of the dreaded "Cannot run C compiled programs"

[Peter Humphrey]

On Wednesday, 28 March 2018 17:15:38 BST Todd Goodman wrote:
> What does 'gcc-config -l' show?

That I have just the one version of GCC installed. But see my reply to Floyd.

-- 
Regards
Peter

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[Peter Humphrey]

On Wednesday, 28 March 2018 16:14:49 BST the...@sys-concept.com wrote:
> On 03/28/2018 01:32 AM, Peter Humphrey wrote:
[...]
> > I have a similar system, but Atom N270. I wouldn't want to compile much on
> > it, and certainly not GCC. I NFS-export its $PORTDIR to this much more
> > powerful box, do the emerging here and then just install packages on the
> > Atom. Still not exactly fast, but incomparably better.
> 
> I should have done it as well, it is a bit too late I have only
> 45-packages left to compile out of 710.
> Is it better use NFS or distcc?
> Do you have a good link how to do it with: "NFS-export  $PORTDIR"

I think NFS may be simpler to operate, but that may be because I'm more
familiar with it. You just need something like this in the Atom's /etc/
exports: /usr/portage 
192.168.1.5(rw,no_subtree_check,anonuid=250,anongid=250,no_wdelay)

That IP address is the big beast host, and of course 250 is the portage user.

I don't know of a guide on the web, but basically, the method is to construct
a 32-bit chroot on your host system and install a mirror of your Atom system
in it. Copy your Atom's /etc/portage directory into the chroot and adjust
things like --jobs to suit the chroot host, but make sure all the USE flags
are the same as on the Atom. It'll take an hour or two to build the system,
but you only have to do it once, and of course it'll be done at the speed of
your host machine. You don't need to keep running etc-update or equivalent;
just build the binaries.

My chroot is /mnt/atom and this script starts it ready to chroot into:

$ cat /etc/init.d/atom
#!/sbin/openrc-run

depend() {
   need localmount
   need bootmisc
}

start() {
ebegin "Mounting 32-bit chroot dirs under /mnt/atom"
mount -t proc /proc /mnt/atom/proc
mount --rbind /dev /mnt/atom/dev
mount --rbind /sys /mnt/atom/sys
mount -t tmpfs tmpfs -o noatime,nosuid,nodev,noexec,mode=1777 /mnt/atom/tmp
mount -t tmpfs tmpfs -o noatime,uid=portage,gid=portage,mode=0775 
/mnt/atom/var/tmp/portage
mount -t nfs -o vers=3 192.168.1.2:/usr/portage /mnt/atom/usr/portage
rm -f /mnt/atom/etc/mtab
cp /etc/mtab.atom /mnt/atom/etc/mtab
eend $? "Error mounting 32-bit chroot directories"
}

stop() {
ebegin "Unmounting 32-bit /mnt/atom chroot dirs"
rm /mnt/atom/etc/mtab
ln -s /proc/self/mounts /mnt/atom/etc/mtab
umount -R /mnt/atom
mount /mnt/atom
}

You may prefer not to bother with tmpfs, but I have 32GB RAM on my host, so
it's efficient here. That IP address is the Atom machine.

No doubt someone more skilled than me at bash scripting could improve on my
script; suggestions welcome.

After updating the chroot you can emerge -k or -K on your Atom machine, after
syncing which will now be the most time-consuming part of the operation.

Let me know if anything isn't clear.

Thanks to Neil Bothwick, who showed me how to do this several years ago.

-- 
Regards
Peter

Re: [gentoo-user] The return of the dreaded "Cannot run C compiled programs"

[Todd Goodman]

What does 'gcc-config -l' show?

Todf

⁣Sent from BlueMail ​

On Mar 27, 2018, 5:02 AM, at 5:02 AM, Peter Humphrey  
wrote:
>On Tuesday, 27 March 2018 01:24:09 BST Daniel Frey wrote:
>
>> I ran into this some time ago and one of the updates removed the /lib
>->
>> /lib64 symlink.
>>
>> I simply ran `ln -s /lib64 /lib` and it was fine after that.
>
>Nice idea, Dan, but that isn't it in this case: 
>
># /bin/ls -ld /lib
>lrwxrwxrwx 1 root root 5 Mar 12 00:08 /lib -> lib64
>
>--
>Regards
>Peter

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[thelma]

On 03/28/2018 01:32 AM, Peter Humphrey wrote:
> On Tuesday, 27 March 2018 16:25:10 BST the...@sys-concept.com wrote:
>> SOLVED!
>> The gcc-6.4.0-r1 compiled with
>> MAKEOPTS="-j1"
>>
>> What is strange is that this is the second low profile system that
>> gcc-6.4.0-r1 failed to compile large package. My other boxed was 4-core
>> and 4GB of RAM and I had to switch to MAKEOPTS="-j1"
>>
>> The above system is: Intel(R) Atom(TM) CPU 330 @ 1.60GHz with 2GB of RAM
>> and "gcc-4.9.4" compiled "gcc-6.4.0-r1" with MAKEOPTS="-j5" OK
>> but when I switched/upgrade profile to "gcc-6.4.0-r1" it filed to
>> compile gcc-6.4.0 with MAKEOPTS="-j5"
>> I had lower MAKEOPTS to -j1
>>
>> So it seems to me the gcc-6.4.0-r1 much more resource hungry or there is
>> a bug in it.
> 
> I have a similar system, but Atom N270. I wouldn't want to compile much on 
> it, 
> and certainly not GCC. I NFS-export its $PORTDIR to this much more powerful 
> box, do the emerging here and then just install packages on the Atom. Still 
> not exactly fast, but incomparably better.

I should have done it as well, it is a bit too late I have only
45-packages left to compile out of 710.
Is it better use NFS or distcc?
Do you have a good link how to do it with: "NFS-export  $PORTDIR"

--
Thelma

Re: [gentoo-user] The return of the dreaded "Cannot run C compiled programs"

[Floyd Anderson]

On Wed, 28 Mar 2018 08:38:10 +0100
Peter Humphrey  wrote:

On Tuesday, 27 March 2018 16:47:32 BST Floyd Anderson wrote:


Just a guess, because you’re compiling multilib – look whether your
kernel is able to run 32bit binaries. Check, e.g. the setting for kernel
option CONFIG_IA32_EMULATION.


That's it! I just reused the .config from the previous no-multilib system
without thinking about it. Stupid boy (TM).


You’re not alone. I wanted to shrink my kernel size and switched that 
kernel option off (beside others) – the error occurred weeks later.



--
Regards,
floyd

Re: [gentoo-user] Error with infinality font while emerging sane-backends

[Floyd Anderson]

On Wed, 28 Mar 2018 13:58:21 +0800
Danny YUE  wrote:



Thanks for your quick reply :-)

I created the symbolic link as you told,


That solves the:

Fontconfig error: failed reading config file
Fontconfig error: Cannot load config file "infinality/conf.d"

errors – they’re gone.


but it still does not
work...same error message.


Now you have to solve the:

Error: /invalidfont in /findfont

Last OS error: No such file or directory
GPL Ghostscript 9.21: Error: /invalidfont in /findfont

errors. The culprit seems here the Type-1 font selection, see bug 
#620148 [1]. Commenting the mentioned section in:


   /etc/fonts/infinality/infinality.conf

works here, bumping Ghostscript to version 9.23 doesn’t.

Hope that helps. If not, you probably can temporarily rename:

   /usr/bin/fig2dev (package media-gfx/transfig)

to hide it from the media-gfx/sane-backends build process, so it wont 
build the PDF documentation. Previously sane-backends-1.0.27 compiles 
fine without media-gfx/xfig and therefore media-gfx/transfig.



Reference:
 [1] 



--
Regards,
floyd

Re: [gentoo-user] cant find stdlib.h

[Pengcheng Xu]

I had ran into this before (but on Gentoo FreeBSD); maybe the compile command 
line
had stray -isystem in it, thus disturbing the include search path.

Pengcheng Xu
i...@jsteward.moe



> H30/03/28 20:18、Bill Kenworthy のメール:
> 
> I have a compile problem qtgui I cant figure out:
> 
> compilation terminated.
> make: *** [Makefile:12443: .obj/qaccessible.o] Error 1
> make: *** [Makefile:12612: .obj/qaccessiblecache.o] Error 1
> In file included from
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_algo.h:59:0,
>  from
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/algorithm:62,
>  from
> ../../include/QtCore/../../src/corelib/global/qglobal.h:109,
>  from ../../include/QtCore/qglobal.h:1,
>  from
> ../../include/QtGui/../../src/gui/kernel/qtguiglobal.h:43,
>  from ../../include/QtGui/qtguiglobal.h:1,
>  from ../../include/QtGui/../../src/gui/image/qimage.h:43,
>  from ../../include/QtGui/qimage.h:1,
>  from image/qimage_sse4.cpp:40:
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/cstdlib:75:25:
> fatal error: stdlib.h: No such file or directory
>  #include_next 
> 
> 
> and of course /usr/include/stdlib.h exists
> 
> 
> The actual code in
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/cstdlib is:
> 
> // Need to ensure this finds the C library's  not a libstdc++
> // wrapper that might already be installed later in the include search path.
> #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
> #include_next 
> #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
> 
> Hints welcome!
> 
> 
> BillK
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

[gentoo-user] cant find stdlib.h

[Bill Kenworthy]

I have a compile problem qtgui I cant figure out:

compilation terminated.
make: *** [Makefile:12443: .obj/qaccessible.o] Error 1
make: *** [Makefile:12612: .obj/qaccessiblecache.o] Error 1
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_algo.h:59:0,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/algorithm:62,
 from
../../include/QtCore/../../src/corelib/global/qglobal.h:109,
 from ../../include/QtCore/qglobal.h:1,
 from
../../include/QtGui/../../src/gui/kernel/qtguiglobal.h:43,
 from ../../include/QtGui/qtguiglobal.h:1,
 from ../../include/QtGui/../../src/gui/image/qimage.h:43,
 from ../../include/QtGui/qimage.h:1,
 from image/qimage_sse4.cpp:40:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/cstdlib:75:25:
fatal error: stdlib.h: No such file or directory
 #include_next 


and of course /usr/include/stdlib.h exists


The actual code in
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/cstdlib is:

// Need to ensure this finds the C library's  not a libstdc++
// wrapper that might already be installed later in the include search path.
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next 
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

Hints welcome!


BillK

Re: [gentoo-user] The return of the dreaded "Cannot run C compiled programs"

[Peter Humphrey]

On Tuesday, 27 March 2018 16:47:32 BST Floyd Anderson wrote:

> Just a guess, because you’re compiling multilib – look whether your
> kernel is able to run 32bit binaries. Check, e.g. the setting for kernel
> option CONFIG_IA32_EMULATION.

That's it! I just reused the .config from the previous no-multilib system 
without thinking about it. Stupid boy (TM).

Many thanks, Floyd.

-- 
Regards
Peter

Re: [gentoo-user] [SOLVED] gcc-6.4.0-r1::gentoo failed (compile phase)

[Peter Humphrey]

On Tuesday, 27 March 2018 16:25:10 BST the...@sys-concept.com wrote:
> SOLVED!
> The gcc-6.4.0-r1 compiled with
> MAKEOPTS="-j1"
> 
> What is strange is that this is the second low profile system that
> gcc-6.4.0-r1 failed to compile large package. My other boxed was 4-core
> and 4GB of RAM and I had to switch to MAKEOPTS="-j1"
> 
> The above system is: Intel(R) Atom(TM) CPU 330 @ 1.60GHz with 2GB of RAM
> and "gcc-4.9.4" compiled "gcc-6.4.0-r1" with MAKEOPTS="-j5" OK
> but when I switched/upgrade profile to "gcc-6.4.0-r1" it filed to
> compile gcc-6.4.0 with MAKEOPTS="-j5"
> I had lower MAKEOPTS to -j1
> 
> So it seems to me the gcc-6.4.0-r1 much more resource hungry or there is
> a bug in it.

I have a similar system, but Atom N270. I wouldn't want to compile much on it, 
and certainly not GCC. I NFS-export its $PORTDIR to this much more powerful 
box, do the emerging here and then just install packages on the Atom. Still 
not exactly fast, but incomparably better.

-- 
Regards
Peter