/srv/irclogs.ubuntu.com/2017/04/16/#ubuntu-devel.txt

=== mezgani is now known as p3rror
keesdoko: 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:43
kees(specifically I'd like to tell stock 4.6 from ubuntu 4.6 since ubuntu moved the plugin headers around slightly)04:44
=== coreycb_vaca is now known as coreycb
PrutheusHello! 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?12:53
infinitykees: By "plugin headers", you mean /usr/lib/gcc/x86_64-linux-gnu/6/ and the like?13:19
infinitykees: That sort of thing should be tested outside the compiler, not within (as in, cpp macros don't make sense for that)13:19
infinitykees: See, for example: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6706074627da7734d21f0024b6f7fb58b5629d6b;hp=800938a1268309932c20dc523bb226bcab4bfe1813:22
infinitykees: (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)13:22
keesinfinity: 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:27
keesinfinity: 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.17:28
infinitykees: Ahh.19:58
infinitykees: That similarly seems like a job for autoconf-style search tests, especially given upstream's joy of backporting to stable branches.19:59
keesinfinity: yeah, kernel Kconfig is ... not friendly ... about such tests.20:02
keesbut 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.620:02
infinityHeh.20:03
infinitykees: 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. :P20:07
infinity(Bonus points if you had any numbers, even fuzzy ones)20:08
Ztanacc: 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:28
Ztanacc: 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?20:31
keesinfinity: 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:33
keesinfinity: I think everyone should configure gcc with --enable-default-ssp and --enable-default-pie :)22:34
=== _salem is now known as salem_
=== JanC is now known as Guest10805
=== JanC_ is now known as JanC

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!