Re: [gentoo-user] How to use logcheck
On Mon, 08 May 2017 16:50:42 +0100, Peter Humphrey wrote:
> As /var/log/messages is so determinedly accessible only to root, can
> any log analyser ever work?
I've used logcheck and have /var/log/messages readable by it.
-rw-r- 1 root logcheck 811K May 9 08:46 /var/log/messages
I have this in syslog-ng.conf
options {
[snip default stuff]
#(Make log files group-readable by logcheck)
group(logcheck);
perm(0640);
};
--
Neil Bothwick
The trouble with doing something right the first time is that nobody
appreciates how difficult it was.
pgpSuRkTiDIgj.pgp
Description: OpenPGP digital signature
Re: [gentoo-user] world rebuild with gcc-6.3.0 - not completely there yet
On Tue, May 09, 2017 at 12:59:12AM -0400, Walter Dnes wrote > I blew away the partially completed install and started again. > This time, it'll be 6.3.0 without graphite. > > I'm busy Tuesday morning. So I'll fire up an "emerge -e @world" > before going to bed, and see where things are when I get back in > the afternoon. The "emerge -e" finished successfully overnight. Since this is at the initial install stage, there were only 156 packages to build, but at least that's progress. I'll finish the install this afternoon. -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-user] Re: world rebuild with gcc-6.3.0 - not completely there yet
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 mentioned in bug 515968 although it's for an older package version) - sci-electronics/gnucap (bug 594184) - games-action/armagetronad (bugs 610844, 617768) 2. lxde media center, 850 packages, all fine except: - games-sports/trigger - games-sports/torcs Haven't had time to process these yet. Looks like it's still better to keep a gcc-5.x version around. Further info, on a ~x86 system: # qlop -gH libreoffice ... libreoffice: Fri May 5 18:02:29 2017: 9 hours, 27 minutes, 30 seconds libreoffice: Tue May 9 01:35:10 2017: 10 hours, 48 minutes, 40 seconds The first build was with gcc-5.4.0-r3, the second with gcc-6.3.0. raffaele
Re: [gentoo-user] gcc 6 PIE use flag
On Tue, 9 May 2017 14:36:09 +1000 Adam Carter wrote:
> 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
I'm not so sure. Whether -fPIC is required or not depends on too
many factors and adding it when not needed will bring harm.
Are you using hardened?
Best regards,
Andrew Savchenko
pgp8oPjdoXM85.pgp
Description: PGP signature
Re: [gentoo-user] layman: cannot properly execute...
>> Any ideas on how to debug this? > > First of all, update all affected parties to the latest versions > (eix, portage, layman). Did that. I'm always up to date. > > Second, use divide and conqueror strategy. If this is the eix > problem, isolate it to eix only without invoking layman (or emaint > sync -a or what on the earth you were doing?!). I use eix-sync, so I believe this is a problem with eix rather than any ancillary software. > > Try with eix-update. If problem persists, look for what eix cache > method you are using: see man eix for the list, there are many of > them. Since you have exec error, it likely is ebuild, try to change > it to parse or metadata. > eix-update gives the same error messages as eix-sync. I've tried reading the eix man page, and have to admit that I don't understand what the various cache methods mean. I did try both "eix-update -m science parse" and "eix-update -m science metadata" without solving the problem (and without me understanding precisely how these commands change the situation). FWIW, eix --dump gives # STRING # Portage cache-backend that should be used for the overlays. # (metadata[:*]/sqlite/flat[:*]/portage-2.1/parse[*][|]ebuild[*]/eix[*][:*]) OVERLAY_CACHE_METHOD="parse|ebuild*" In my installations, I note that there's a /usr/portage/metadata/md5-cache directory, but no /var/lib/layman/science/metadata cache directories. Is something missing? Is there some place other than the eix man page that describes these various kinds of caches? Thanks for your suggestions, John
Re: [gentoo-user] world rebuild with gcc-6.3.0 - not completely there yet
I've been running some number theory on my CPU 24/7 for the last month... It's a good burn-in because it uses all my cpu and all my ram. =P The run will complete a month from now, I hope... Kinda stoked about gcc 6.x coming, really looking forward to rebuilding my system, hope things go well by the time I'm ready. =) Walter Dnes wrote: > 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, and used various -floop and -ftree CXXFLAGS. When I > tried updating @world on a new install, it was a Churchillian > "unmitigated disaster", with multiple program builds aborting with > "internal compiler error" messages complaining about something to do > with "loop". I blew away the partially completed install and started > again. This time, it'll be 6.3.0 without graphite. > > I'm busy Tuesday morning. So I'll fire up an "emerge -e @world" before > going to bed, and see where things are when I get back in the afternoon. -- Strange Game. The only winning move is not to play. Powers are not rights.
Re: [gentoo-user] gcc 6 PIE use flag
On Mon, May 08, 2017 at 08:46:54AM +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' can not be used > when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > dw2gencfi.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be > used when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > frags.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used > when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > messages.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used > when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > subsegs.o: relocation R_X86_64_32 against `.rodata' can not be used when > making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > symbols.o: relocation R_X86_64_32S against symbol `_sch_toupper' can not be > used when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > atof-ieee.o: relocation R_X86_64_32S against `.rodata' can not be used when > making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > symbols.o: warning: relocation against `strlen@@GLIBC_2.2.5' in readonly > section `.text' > /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: > final link failed: Nonrepresentable section on output > collect2: error: ld returned 1 exit status > > If I add -fPIC to CFLAGS it will compile. Interestingly some packages (eg > PHP) will compile without the -fPIC. Also the man page says; "This option > makes a difference on AArch64, m68k, PowerPC and SPARC:, whereas i'm > running amd64. > > What's going on here? It's a feature, not a bug. There's a news item being worked on in the Gentoo dev list. I'd normally just link to a mail archive, but it's too new to have been archived yet. Here's a copy of the proposed news item. Note the example error message about relocation against .rodata ### Title: GCC 6 defaults to USE="pie ssp" Author: Matthias Maier Content-Type: text/plain Posted: 2017-05-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: >=sys-devel/gcc-6.3.0 Display-If-Keyword: amd64 In Gentoo, several GCC features can be default disabled or enabled via use-flags of sys-devel/gcc. Starting with gcc-4.8.3 we have already enabled default SSP [1]. Since the PIE patchset for default position independent executable support was integrated upstream [2,3], starting with gcc-6.3 we are also enabling PIE by default (via a default-enabled use-flag pie) in regular (non-hardened) profiles. [Additionally, following Gentoo policies, the default-off use-flags nopie (only present in Hardened) and nossp are replaced starting with gcc-6 by default-on use-flags pie and ssp.] Be advised that switching from an older version to GCC 6 will enable the PIE feature by default. This should not cause many problems, but it may be necessary to recompile parts of your userland. An indicator are linker errors of the form [4] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC [1] https://www.gentoo.org/support/news-items/2014-06-15-gcc48_ssp.html [2] https://gcc.gnu.org/gcc-6/changes.html [3] A big thanks to all developers and members of the Gentoo community that made upstreaming the pie patchset and other hardening options possible! [4] https://bugs.gentoo.org/617698 ### -- Walter Dnes I don't run "desktop environments"; I run useful applications
