I have a 2008 dual core Core2 that I gave up on because it doesn't
support QEMU hardware acceleration. Now that I've figured out chroot
for stuff I need, I decided to do a new 32-bit install. I figured this
might be a chance to experiment with GCC 6.3.0. I went whole-hog and
enabled graphite,
Shared objects often need -fPIC for proper relocations when
> linking, just add it when you're told to. It allows COW strategy
> for DLOs but at the cost of extra CPU register and some slowdown.
>
>
Shouldn't this be in the ebuilds? eg.
if gcc:6[pie];
then CFLAGS=${CFLAGS} -fPIC
On Mon, May 8, 2017 at 19:11:28 CEST, R0b0t1:
> [...]
> It might not matter for anyone on this list, but it seems like GCC 6
> doesn't support hardening properly. I'm kind of disappointed that they
> seem to want to skip it but I can understand the amount of work they
> might be avoiding.
Could yo
On Mon, May 8, 2017 at 10:09 AM, Rasmus Thomsen
wrote:
> Hi,
>
> libxcb just requires you to build it with -O1 when you want to use its 32bit
> libraries with GCC 6 (dunno about older versions off GCC).
> Personally, I haven't encountered any problems with GCC 6.3 other than
> libxcb.
>
> Regards,
On 2017-05-08, Andrew Savchenko wrote:
> The problem is that this warning is too severe: it suggests that
> package may not work properly without feature:
> "may cause unexpected problems"
> instead of saying "some additional features will be disabled"
>
> Hey, this is _very_ different to have
On Monday 08 May 2017 17:32:07 Alan McKinnon wrote:
> On 08/05/2017 14:54, Peter Humphrey wrote:
> > Hello list,
> >
> > The logging section of the security handbook[1] recommends using app-
> > admin/logcheck to monitor logs, but I can't get past a permission
> > problem. Logcheck sends me an e-m
On 08/05/2017 14:54, Peter Humphrey wrote:
> Hello list,
>
> The logging section of the security handbook[1] recommends using app-
> admin/logcheck to monitor logs, but I can't get past a permission problem.
> Logcheck sends me an e-mail which complains:
>
>
> Could not run logt
Hi,
libxcb just requires you to build it with -O1 when you want to use its 32bit
libraries with GCC 6 (dunno about older versions off GCC).
Personally, I haven't encountered any problems with GCC 6.3 other than libxcb.
Regards,
Rasmus
Original Message
On 8 May 2017, 16:14, Holg
On Mon, 08 May 2017 11:57:50 +, J. Roeleveld wrote:
> Only recently got my desktop converted to 5.4.
> Next is my laptop.
>
> When that is done, I could risk 6 on my desktop. But if Dev is thinking of
> skipping it
Don't bother with 6, go straight to 7. I had at least one library (libx
Hello list,
The logging section of the security handbook[1] recommends using app-
admin/logcheck to monitor logs, but I can't get past a permission problem.
Logcheck sends me an e-mail which complains:
Could not run logtail or save output
Check temporary directory: /tmp/logchec
On May 8, 2017 1:47:22 PM GMT+02:00, Dale wrote:
>Raffaele Belardi wrote:
>> During the weekend I 'emerge -e' a couple of ~amd64 systems with
>> gcc-6.3.0:
>>
>> 1. gnome desktop, 1000 packages, all build fine except:
>> - net-libs/webkit-gtk, rebuilding it again after world fixed it
>> (possibly
Raffaele Belardi wrote:
> During the weekend I 'emerge -e' a couple of ~amd64 systems with
> gcc-6.3.0:
>
> 1. gnome desktop, 1000 packages, all build fine except:
> - net-libs/webkit-gtk, rebuilding it again after world fixed it
> (possibly an issue with -j MAKEOPTS, a similar build failure is
> m
On Mon, 8 May 2017 08:46:54 +1000 Adam Carter wrote:
> Since an update to the default USE flags on gcc 6 turned on PIE and SSP,
> i'm getting these errors;
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> atof-generic.o: relocation R_X86_64_32 against `.rodata'
On Sat, 6 May 2017 14:28:51 -0400 John Blinka wrote:
> Hi, all,
>
> For some time I've been getting messages like:
>
> cannot properly execute
> /var/lib/layman/science/virtual/lapack/lapack-3.6-r100.ebuild
>
> for *every* package in the science overlay. This happened on 2 of 3
> very similar g
[root@asgard ~]$ eselect opengl list 7:21
Available OpenGL implementations:
[1] xorg-x11 *
[root@asgard ~]$ eselect mesa list 7:21
i915 (Intel 915, 945)
i965 (Intel GMA 965, G/Q3x, G/Q4x, HD)
[1] classic *
r300 (Radeon R300-R500)
r600 (Radeon R600-R700, Evergreen, Northern Islands)
sw (Sof
On Wed, 3 May 2017 15:11:33 -0700 Daniel Campbell wrote:
> cgroups are not being pushed in this case. Portage threw up a warning,
> letting you know that some features of htop may not be available without
> the CONFIG_CGROUPS flag on in the kernel. htop should work to your
> liking as it is right n
On Mon, 1 May 2017 09:46:38 -0400 Rich Freeman wrote:
> On Sun, Apr 30, 2017 at 4:17 PM, Kai Krakow wrote:
> > Am Sun, 30 Apr 2017 10:33:05 -0700
> > schrieb Jorge Almeida :
> >
> >> It makes sense that the kernel has it. Should it be enabled? For a
> >> server, probably. For a single-user worksta
17 matches
Mail list logo
