=== mezgani is now known as p3rror
[04:43] <kees> doko: is there any way to tell a debian/ubuntu gcc build from a stock gcc build using only preprocessor magic? it looks like there's nothing different but a date in the __VERSION__ define.
[04:44] <kees> (specifically I'd like to tell stock 4.6 from ubuntu 4.6 since ubuntu moved the plugin headers around slightly)
=== coreycb_vaca is now known as coreycb
[12:53] <Prutheus> Hello! I am working with GTK and libappindicator ... however, I want to change the icon of the indicator in my program dynamically ... like this: https://ghostbin.com/paste/jt9wd  but this is not working, how to solve my problem?
[13:19] <infinity> kees: By "plugin headers", you mean /usr/lib/gcc/x86_64-linux-gnu/6/ and the like?
[13:19] <infinity> kees: That sort of thing should be tested outside the compiler, not within (as in, cpp macros don't make sense for that)
[13:22] <infinity> kees: See, for example: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6706074627da7734d21f0024b6f7fb58b5629d6b;hp=800938a1268309932c20dc523bb226bcab4bfe18
[13:22] <infinity> kees: (assuming you're doing the same silly thing we are, which is dropping stdinc, and then turning around and trying to recontruct it because we think we know better :P)
[17:27] <kees> infinity: I mean the headers in gcc-N-plugin-dev. the "c-common.h" file moved to c-family/ in gcc 4.7, but ubuntu's 4.6 moved it there early with https://sources.debian.net/src/gcc-4.6/4.6.3-14/debian/patches/pr45078.diff/
[17:28] <kees> infinity: which means that if I do a gcc version test in headers to find the right place to include c-common.h from, I can't use only a version test, since 4.6 stock and ubuntu builds have it in different places.
[19:58] <infinity> kees: Ahh.
[19:59] <infinity> kees: That similarly seems like a job for autoconf-style search tests, especially given upstream's joy of backporting to stable branches.
[20:02] <kees> infinity: yeah, kernel Kconfig is ... not friendly ... about such tests.
[20:02] <kees> but that's okay. near as I can tell, the only gcc 4.6 left on the planet not built from source are the Debian and Ubuntu packages. :) so I'll just continue to pretend that's the "real" 4.6
[20:03] <infinity> Heh.
[20:07] <infinity> kees: While I have you here, care to have a public opinion about armhf and PIE?  I recall the last time you and I spoke about it, you said ChromeOS does PIE on armhf and we should JFDI ourselves.  doko, on the other hand, says you expressed the opposite opinion to him. :P
[20:08] <infinity> (Bonus points if you had any numbers, even fuzzy ones)
[20:28] <Zta> nacc: Hi again =) I decided to go a somewhat different route: I created a docker image with all tools and dependencies and clone the sources. Then I added scripts to do all what we discussed earlier, with the exception of schroot; I build the package directly on the host (=dockered!) system. And I actually got something working (with the same procedure that did not work in schroot, strangely).
[20:31] <Zta> nacc: So all is good. Except when I decide update my sources and rebuild the package.  Then I get: dpkg-source: error: unwanted binary file: debian/aseprite/usr/bin/aseprite[...]  Should I just delete this directory manually?
[22:33] <kees> infinity: I think what doko remembers was me agreeing that I wasn't opposed to armhf staying non-PIE. That said, I think there's no good reason to stay non-PIE since there are more general registers on arm than i386, and the compiler can already float the PIE register around, so there's even less loss of performane.
[22:34] <kees> infinity: I think everyone should configure gcc with --enable-default-ssp and --enable-default-pie :)
=== _salem is now known as salem_
=== JanC is now known as Guest10805
=== JanC_ is now known as JanC