Dnia 2014-06-18, o godz. 17:24:03 Peter Stuge <pe...@stuge.se> napisał(a):
> Alexandre Rostovtsev wrote:
> > current crossdev versions blindly install their
> > /usr/bin/i686-pc-linux-gnu-pkg-config wrapper script, overwriting
> > the binary belonging to pkgconfig[abi_x86_32].
>
> Thanks for getting to the point.
>
> It seems silly for two toolchains (abi_x86_32 and a crossdev i686 toolchain)
> to compete for one and the same name.
>
> Is that really desirable?
No. But the user specifies prefix for crossdev. As far as I'm
concerned, crossdev could refuse prefixes that are already used
in Gentoo profiles.
> Both toolchains integrate with emerge; either one can be used to emerge
> packages, right? (Where the packages are emerged to doesn't matter.)
No, 'integrating with emerge' is a bad word. Crossdev wraps emerge
and runs on top of it. Multilib runs 'below' emerge as run by eclass.
> If Gentoo would like to support different toolchains for one CHOST
> then there obviously needs to be some abstraction, and creating it
> should take into account that things like autoconf, cmake, waf and
> friends may not support any such abstraction for a long time to come.
>
> An obvious low-finesse solution is to only allow one toolchain per CHOST.
Obviously.
> That would formalize the current situation where only one toolchain or
> the other works correctly, and would be fine as a first step.
>
> If long-term Gentoo does indeed want to support both an abi_x86_32
> and a crossdev-built i686-pc-linux-gnu toolchain, then obviously
> someone interested in that will have to come up with how it will
> work.
I'd rather see multilib gcc installing 'i686-pc-linux-gnu' wrappers
that call the native gcc with proper '-m' option. As far as I know,
there's no real difference between the code emitted by native compiler
with -m32 and cross-compiler for i686. This would remove some need for
crossdev (and therefore some breakages) and allow our users to avoid
rebuilding the same thing twice.
> > The initial multilib code didn't use prefixed pkg-config binaries
> > but simple PKG_CONFIG_PATH override.
>
> Do you mean PKG_CONFIG_LIBDIR?
Both.
> > However, crossdev installing i686-pc-linux-gnu-pkg-config caused
> > configure scripts to find and use it instead of plain 'pkg-config',
>
> That sounds to me like autoconf's pkg-config support might also be
> involved in the problem?
The autoconf's AC_PROG_TOOL macros are proper and very useful. What's
the real problem is that crossdev installs some custom wrapper that
clobbers PKG_CONFIG_* where real pkg-config is expected.
> > and since the wrapper dumbly overrides PKG_CONFIG_PATH it broke our
> > original solution.
> >
> > We specifically made pkg-config packages install the prefixed binaries
> > to trigger collisions with crossdev
>
> That strikes me as really unhelpful. You spent time on creating something
> you were sure would cause a problem, instead of on something to *avoid*
> the problem. Oh well.
This was hitting our users and crossdev team didn't care. I did what I
could from our side to fix this, though this probably wasn't good
enough.
Do you prefer if I add some logic to detect i686 crossdev and bail out
completely, telling users to remove it? That wouldn't be very friendly
but at least they wouldn't hit random build failures anymore.
> > -- so that people who have systems broken with crossdev's
> > i686-pc-linux-gnu-pkg-config would be more likely informed there's
> > something wrong with their systems.
>
> You seem to have made an arbitrary decision that crossdev's
> pkg-config is at fault. I think we need to look at this in a larger
> perspective as outlined above; take a step back.
Because it is at fault. Build systems expect *-pkg-config to be
a binary compatible with pkg-config. When crossdev installs something
that does not respect PKG_CONFIG_{LIBDIR,PATH} and instead uses some
fancy directories, it is inevitable that it will break something.
And just to be clear, we didn't invent anything new. The breakage was
there for years, we were just first ones to mix all the ingredients.
The CHOSTs used by our stuff come from profiles, we didn't invent them.
The multilib_toolchain_setup that sets the build environment comes from
multilib.eclass and was already used for multilib in the past. The code
that causes tc-getBUILD_CC to return incorrect (crossdev) compiler
comes from toolchain-funcs.eclass.
If you look at it all, you'd notice that all code that results in those
failures is maintained by toolchain team, and so is crossdev. So what
can small gx86-multilib team to do to fix it?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
