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 ku...@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
