Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

[Joshua Kinard <kumba@gentoo.org>]

On 06/17/2014 10:38, hasufell wrote:
> Joshua Kinard:
>>
>> "upstream" didn't say anywhere in that bug that they weren't interested.
>> They countered your reasoning with a technical argument.  QA even states
>> that you need to file separate bugs for the various build failures.  You
>> could set up a master TRACKER bug for these crossdev-related issues, and
>> then link in any existing bugs or create new ones tied to it, and that way,
>> you have things documented.
>>
> 
> I appreciate that you want to help, but I'm not sure how many times I
> have to explain to you that the PATH idea was neglected by the embedded
> gentoo project lead. Check the history of this thread, it starts here:
> https://groups.google.com/d/msg/linux.gentoo.dev/KZykx1DAJyM/YCMVUt4CzjUJ

I already have that thread in my client, so let me quote a few choice bits:


On 03/26/2014 01:17, Mike Frysinger wrote:
>> when you run `crossdev i686-pc-linux-gnu`, it owns that tuple.  that includes 
>> i686-pc-linux-gnu-pkg-config.
>> 
>> if we're going to have the multilib system lie and use a tuple that doesn't 
>> actually exist, we either:
>> 
>> (1) override all the vars so they point back to the real toolchain.
>> this doesn't scale when you consider helper tools like the legacy sdl-config 
>> or the extended set of tools that binutils/gcc/etc... install.  it's mitigated 
>> by the fact the set of vars in play most of the time is low.
>> 
>> (2) use tuples with loaded vendor fields to reduce the chance of collisions.
>> e.g. having an ABI=amd64 system use i686-gentoo%multilib-linux-gnu instead of 
>> i686-pc-linux-gnu would defeat any automatic path searches.

On 03/26/2014 22:41, Mike Frysinger wrote:
>> 
>> as i pointed out elsewhere in this thread, the problem is that multilib relies 
>> on automatic detection of the toolchain *failing* so that it falls back to the 
>> native value.  in other words, when you run `./configure --host=i686-pc-linux-
>> gnu`, it tries to find e.g. i686-pc-linux-gnu-ar.  it doesn't exist so the 
>> fallback is used (plain `ar`).  multilib is using these tuples so that the 
>> standard checks (autoconf/eclasses/etc...) trigger in the right ways for the 
>> cpu/os/userland combinations.
>> 
>> since crossdev installs a full proper toolchain for the target, the one 
>> multilib was using to lie now exists and its toolchain is used instead.

On 03/27/2014 02:41, Mike Frysinger wrote:
>> 
>> pkg-config does need fixing in some way.  we already know this.  it's why the 
>> multilib eclasses currently set PKG_CONFIG_XXX vars -- preciously so the 
>> correct ABI dir is utilized.  and this breaks when using some build systems 
>> (like scons) where the env gets blown away (although we also know scons 
>> sucks).



> So again, I am not doing work that goes diametral to what the project
> lead wants and I am not going to fork crossdev.
> 
> I have proposed numerous ways to communicate this problem to the user
> without touching any of the precious toolchain/embedded packages. If no
> one responds there, I'll just pick one and apply it.

And what I am trying to tell you is that making hardmask threats don't solve
the core problem.  You're threatening to to start a mask/unmask war that
probably won't end well for you.  Mike has, in all of the messages I have in
the thread, provided clear technical explanations for why crossdev operates
the way it does, and that it isn't the source of these problems.

Provide a technical counter-argument to that or propose a solution that
people can agree on and you're going to find people are a LOT more willing
to stand with you on fixing the perceived problem.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic