libglade build failure redux
Mike Frysinger
http://build.chromium.org/p/chromiumos/builders/tegra2%20seaboard%20full/builds/1524/steps/cbuildbot/logs/stdio
(ignore the sudo failures as that was a diff issue)
i believe that libglade has always been broken, but we only noticed
just now due to Nathan upgrading a bunch of packages. the root issue
being that libglade's configure script was generated with an old
version of pkg-config.m4 which only searches for "pkg-config" in
$PATH. newer versions look for "<host>-pkg-config" first. so
libglade has been using -I/-L paths to /usr/. in the past, we had an
older version of glib in /usr/, so this "worked" fine.
after Nathan upgraded things, we had a newer version of glib in /usr/.
unfortunately, we're on an old version of pango which needs defines
from the older version of glib. so mix in the fact that libglade
builds with -DG_DISABLE_DEPRECATED (which the old glib did not know
about), then includes newer glib and older pango (which needs the
deprecated glib stuff), and we hit this build failure.
i've fixed the underlying bug by hacking up libglade's build env:
https://gerrit.chromium.org/gerrit/14203
hopefully once we move on to auro, we can drop all the GNOME stuff,
and then not worry about it. otherwise, we'd want to upgrade both
libglade and pango in order to drop these build env hacks.
Nathan: unfortunately, one of your CL's got reverted in the process:
https://gerrit.chromium.org/gerrit/14199
i believe you should be able to re-land that when you get a chance
since the underlying issue is fixed
-mike
Mandeep Singh Baines
> libglade started killing all the bots; example log here:
> http://build.chromium.org/p/chromiumos/builders/tegra2%20seaboard%20full/builds/1524/steps/cbuildbot/logs/stdio
> (ignore the sudo failures as that was a diff issue)
>
> i believe that libglade has always been broken, but we only noticed
> just now due to Nathan upgrading a bunch of packages. the root issue
> being that libglade's configure script was generated with an old
> version of pkg-config.m4 which only searches for "pkg-config" in
> $PATH. newer versions look for "<host>-pkg-config" first. so
> libglade has been using -I/-L paths to /usr/. in the past, we had an
> older version of glib in /usr/, so this "worked" fine.
>
Could we somehow use the sandbox to prevent access to /usr/include
when cross-compiling? We can't prevent access to /usr/lib because
host tools will load libraries from there.
> after Nathan upgraded things, we had a newer version of glib in /usr/.
> unfortunately, we're on an old version of pango which needs defines
> from the older version of glib. so mix in the fact that libglade
> builds with -DG_DISABLE_DEPRECATED (which the old glib did not know
> about), then includes newer glib and older pango (which needs the
> deprecated glib stuff), and we hit this build failure.
>
> i've fixed the underlying bug by hacking up libglade's build env:
> https://gerrit.chromium.org/gerrit/14203
>
> hopefully once we move on to auro, we can drop all the GNOME stuff,
> and then not worry about it. otherwise, we'd want to upgrade both
> libglade and pango in order to drop these build env hacks.
>
> Nathan: unfortunately, one of your CL's got reverted in the process:
> https://gerrit.chromium.org/gerrit/14199
> i believe you should be able to re-land that when you get a chance
> since the underlying issue is fixed
> -mike
>
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
Mike Frysinger
> i've fixed the underlying bug by hacking up libglade's build env:
> https://gerrit.chromium.org/gerrit/14203
that fixed non-amd64 boards. needed this follow up for the amd64 ones:
https://gerrit.chromium.org/gerrit/14214
-mike
Mike Frysinger
> Mike Frysinger wrote:
>> libglade started killing all the bots; example log here:
>> http://build.chromium.org/p/chromiumos/builders/tegra2%20seaboard%20full/builds/1524/steps/cbuildbot/logs/stdio
>> (ignore the sudo failures as that was a diff issue)
>>
>> i believe that libglade has always been broken, but we only noticed
>> just now due to Nathan upgrading a bunch of packages. the root issue
>> being that libglade's configure script was generated with an old
>> version of pkg-config.m4 which only searches for "pkg-config" in
>> $PATH. newer versions look for "<host>-pkg-config" first. so
>> libglade has been using -I/-L paths to /usr/. in the past, we had an
>> older version of glib in /usr/, so this "worked" fine.
>
> Could we somehow use the sandbox to prevent access to /usr/include
> when cross-compiling? We can't prevent access to /usr/lib because
> host tools will load libraries from there.
same reason we can't block /usr/include ... some packages build local
helper tools and then execute them. like ncurses and `tac`.
there are patches floating around where the cross-compiler itself
(x86_64-cros-linux-gnu-gcc) would abort when it was given
-I/usr/include ...
-mike
Sonny Rao
Ahh, oops I shouldn't have re-opened the tree -- thanks for fixing Mike
Mandeep Singh Baines
Should be easy enough to handle by whitelisting via a new QA_HOST_BUILD
flag?
Some interesting patches here maybe:
http://www.ptxdist.org/software/ptxdist/ptxdist_faq_en.html
<quote>
Q: When I build my own application the compiler fails with "Compiler badness...". What does it mean?
A: It does mean the cross compiler has found some code that tries to include files from your host. This should never happen for makefiles which cope correctly with cross situations. Vanilla (upstream) gcc versions don't show this messages; it has been added to OSELAS.Toolchain() compilers in order to quickly find situations where the wrong header files are being included.
</quote>
Regards,
Mandeep
> -mike
Mike Frysinger
> Mike Frysinger (vap...@chromium.org) wrote:
>> On Sat, Jan 14, 2012 at 01:15, Mandeep Singh Baines wrote:
>> > Mike Frysinger wrote:
>> >> libglade started killing all the bots; example log here:
>> >> http://build.chromium.org/p/chromiumos/builders/tegra2%20seaboard%20full/builds/1524/steps/cbuildbot/logs/stdio
>> >> (ignore the sudo failures as that was a diff issue)
>> >>
>> >> i believe that libglade has always been broken, but we only noticed
>> >> just now due to Nathan upgrading a bunch of packages. the root issue
>> >> being that libglade's configure script was generated with an old
>> >> version of pkg-config.m4 which only searches for "pkg-config" in
>> >> $PATH. newer versions look for "<host>-pkg-config" first. so
>> >> libglade has been using -I/-L paths to /usr/. in the past, we had an
>> >> older version of glib in /usr/, so this "worked" fine.
>> >
>> > Could we somehow use the sandbox to prevent access to /usr/include
>> > when cross-compiling? We can't prevent access to /usr/lib because
>> > host tools will load libraries from there.
>>
>> same reason we can't block /usr/include ... some packages build local
>> helper tools and then execute them. like ncurses and `tac`.
>
> flag?
i don't think so. since packages execute `gcc` to compile code for
build-time tools, we'd have to whitelist much of /usr/include. which
would sort of defeat things.
>> there are patches floating around where the cross-compiler itself
>> (x86_64-cros-linux-gnu-gcc) would abort when it was given
>> -I/usr/include ...
>
> Some interesting patches here maybe:
this is the one i was thinking of:
http://cgit.openembedded.org/openembedded/tree/recipes/gcc/gcc-4.5/zecke-no-host-includes.patch
-mike
Mandeep Singh Baines
My bad, I think I meant RESTRICT. So add a new restrict which you use
to identify specific packages that need to build host tools.
Mike Frysinger
maybe. i fear the list will be too large to make it truly useful ...
or maybe i'm just being pessimistic.
-mike
Mandeep Singh Baines
Hmm, out the 300+ packages used to build ChromeOS, I'm aware of maybe
10 packages that need to build a host tool. There were more earlier but
some were fixed to rely on the package already being built on the host
and use the tool already installing in /usr/bin.
So that's a very conservative SWAG of 3 %.
Regards,
Mandeep
> -mike
Mike Frysinger
doing this might accomplish the same result:
sudo su -
echo SANDBOX_DENY=/usr/include > /etc/sandbox.d/90cros
and then removing that in the per-package env for the packages that
build tools ...
-mike
Mandeep Singh Baines
> On Wed, Jan 18, 2012 at 13:39, Mandeep Singh Baines wrote:
> > Mike Frysinger (vap...@chromium.org) wrote:
> >> On Wed, Jan 18, 2012 at 13:20, Mandeep Singh Baines wrote:
> >> > Mike Frysinger (vap...@chromium.org) wrote:
> >> >> On Wed, Jan 18, 2012 at 12:31, Mandeep Singh Baines wrote:
> >> >> > Mike Frysinger (vap...@chromium.org) wrote:
> >> >> >> On Sat, Jan 14, 2012 at 01:15, Mandeep Singh Baines wrote:
> >> >> >> > Mike Frysinger wrote:
> >> >> >> >> i believe that libglade has always been broken, but we only noticed
> >> >> >> >> being that libglade's configure script was generated with an old
> >> >> >> >> version of pkg-config.m4 which only searches for "pkg-config" in
> >> >> >> >> libglade has been using -I/-L paths to /usr/. �ｿｽin the past, we had an
> >> >> >> >> older version of glib in /usr/, so this "worked" fine.
> >> >> >> >
> >> >> >> > Could we somehow use the sandbox to prevent access to /usr/include
> >> >> >> > when cross-compiling? We can't prevent access to /usr/lib because
> >> >> >> > host tools will load libraries from there.
> >> >> >>
> >> >> >> same reason we can't block /usr/include ... some packages build local
> >> >> >
> >> >> > Should be easy enough to handle by whitelisting via a new QA_HOST_BUILD
> >> >> > flag?
> >> >>
> >> >> build-time tools, we'd have to whitelist much of /usr/include. �ｿｽwhich
> >> >> would sort of defeat things.
> >> >
> >> > My bad, I think I meant RESTRICT. So add a new restrict which you use
> >> > to identify specific packages that need to build host tools.
> >>
> >> or maybe i'm just being pessimistic.
> >
> > Hmm, out the 300+ packages used to build ChromeOS, I'm aware of maybe
> > 10 packages that need to build a host tool. There were more earlier but
> > some were fixed to rely on the package already being built on the host
> > and use the tool already installing in /usr/bin.
> >
> > So that's a very conservative SWAG of 3 %.
>
> doing this might accomplish the same result:
> sudo su -
> echo SANDBOX_DENY=/usr/include > /etc/sandbox.d/90cros
>
Neat! You'd only want this to apply to cross-compile builds.
So maybe:
[ "${ROOT}" != "/" ] && SANDBOX_DENY=/usr/include
So add this as a patch to sys-apps/sandbox?
> and then removing that in the per-package env for the packages that
> build tools ...
Where are the per-package envs located?
Regards,
Mandeep
> -mike
Mike Frysinger
we probably would want to add it to the emerge-$BOARD wrappers:
export SANDBOX_DENY=/usr/include
that way the normal `emerge` is unaffected
>> and then removing that in the per-package env for the packages that
>> build tools ...
>
> Where are the per-package envs located?
chromiumos-overlay/chromeos/config/env/
-mike
Mandeep Singh Baines
> On Thu, Jan 19, 2012 at 09:23, Mandeep Singh Baines wrote:
> > Mike Frysinger (vap...@chromium.org) wrote:
> >> doing this might accomplish the same result:
> >> sudo su -
> >> echo SANDBOX_DENY=/usr/include > /etc/sandbox.d/90cros
> >
> > Neat! You'd only want this to apply to cross-compile builds.
> > So maybe:
> >
> > [ "${ROOT}" != "/" ] && SANDBOX_DENY=/usr/include
> >
> > So add this as a patch to sys-apps/sandbox?
>
> we probably would want to add it to the emerge-$BOARD wrappers:
> export SANDBOX_DENY=/usr/include
>
Ah. Good idea.
> that way the normal `emerge` is unaffected
>
> >> and then removing that in the per-package env for the packages that
> >> build tools ...
> >
> > Where are the per-package envs located?
>
> chromiumos-overlay/chromeos/config/env/
Cool Thanks!
> -mike