crossdev and multilib interference

classic Classic list List threaded Threaded
85 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Samuli Suominen-4

On 27/03/14 08:41, Mike Frysinger wrote:

> On Thu 27 Mar 2014 02:31:01 Alexandre Rostovtsev wrote:
>> On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote:
>>>> An amd64 multilib system *is* expected to build x86
>>>> binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is
>>>> expected to be not a part of any cross-compile toolchain, but a part of
>>>> the native toolchain for the machine's secondary native ABI. Especially
>>>> when i686-pc-linux-gnu-ar is in /usr/bin.
>>> sure, and it works just fine when you use the correct toolchain.  if the
>>> user wants to build an ABI using their default toolchain, they can pass
>>> the right ABI flag for it.
>> They can't pass the right ABI flag because only the core parts of the
>> toolchain have the concept of an ABI flag.
>>
>> Sure, binutils and gcc respect "-m32". But what about pkgconfig (and its
>> clones pkgconf and pkgconfig-openbsd)? What about the *-config tools for
>> various libraries? Are you going to patch all of them to respect "-m32"?
> 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).


I pushed 0.28-r1 of dev-util/pkgconfig with ABI_X86 support so that you
can directly
call eg. i686-pc-linux-gnu-pkg-config to search from /usr/lib32/pkgconfig/

I'll try to figure something out for pkgconfig-openbsd too. Don't care
about pkgconf.

> i don't care about the *-config scripts.  that's a dead concept long ago
> proven to suck and anything still using it needs fixing.
>

nod

Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Mike Frysinger
In reply to this post by Michał Górny-5
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:

> Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
> > On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> > > (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.
> >
> > this patch keeps the status quo.  although the status quo is broken, but
> > we
> > can sort that out independently.
>
> Except that it breaks stuff that is installed at the point and comes
> with no plan of cleaning up the resulting mess.
such as ... ?  vague statements can't be addressed.

> > --- profiles/arch/amd64/make.defaults 18 Jan 2014 01:03:24 -0000 1.21
> > +++ profiles/arch/amd64/make.defaults 27 Mar 2014 06:13:22 -0000
> > @@ -21,17 +21,17 @@ ABI="amd64"
> >
> >  # 64bit specific settings.
> >  CFLAGS_amd64="-m64"
> >  LDFLAGS_amd64="-m elf_x86_64"
> >
> > -CHOST_amd64="x86_64-pc-linux-gnu"
> > +CHOST_amd64="${CHOST}"
> >
> >  # 32bit specific settings.
> >  CFLAGS_x86="-m32"
> >  LDFLAGS_x86="-m elf_i386"
> >
> > -CHOST_x86="i686-pc-linux-gnu"
> > +CHOST_x86="i686-gentoo%multilib-linux-gnu"
>
> Using percent sign here looks like asking for trouble at some point.
> I don't see why you can't use plain 'gentoomultilib' that is more
> fool-proof.
i merely picked a value that was highly unlikely for people to use.  the %
should be safe as it is not interpreted by the shell and strongly indicates
"hey man, don't mess with me".  it could just as easily be a _ or nothing at
all.  i don't feel strongly about it.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Mike Frysinger
In reply to this post by Michał Górny-5
really have no idea what you're ranting about.  doesn't look discussion worthy
though.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: crossdev and multilib interference

Steven J. Long
In reply to this post by Mike Frysinger
Mike Frysinger wrote:

> Steven J. Long wrote:
> > Mike Frysinger wrote:
> > > if they're in $PATH, then the exact location is irrelevant.
> > > they need not be in /usr/bin to cause a problem.
> > > if they're not in $PATH, then you're breaking the cross-compilers
> > > and that is unacceptable.
> >
> > Cross-compilation should be supported via cross-emerge, and perhaps a small
> > script the cross-compiler sources to setup the env (ie prefix to PATH in
> > this case) for using CHOST-* tools, like x86-pc-linux-gnu-gcc targetting
> > a straight x86 platform, instead of the normal multilib setup. The
> > latter being used by the former (I'd have thought it was already done.)
> >
> > The cross tools should NOT pollute the default PATH, simply because the
> > user happened to run crossdev at some point.

> that's bs.  people install crossdev to get a cross-compile environment, not to
> get something that only works through `emerge`.  attempting to restrict it so
> it only works through `emerge` is unacceptable and it has never been that way.

That's why I suggested a small sh script to source, to setup that environment.
Personally, I do an awful lot more than that just to build a native chroot,
let alone cross-compile. And I really don't see the hardship for these brave
"cross-compilers" of yours in sourcing a small setup script, which can be
added to ~/.bashrc or even the system-wide one, for anyone who really wants
it to apply whenever they login. Is this somehow beyond our most advanced
userbase?

People may install crossdev to get a cross-compile environment, but it's a
broken design if it's not contained. And BS about how you think it should
ALWAYS go for everybody, only leads to borked "solutions" elsewhere like
telling the people on an amd64 install that they have to run some god-awful
"new" %multilib thing to compile for their secondary ABI. That's just as
counter-intuitive, when you could just fix your borkage and have a clean
setup for everyone.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Michał Górny-5
In reply to this post by Mike Frysinger
Dnia 2014-03-27, o godz. 03:18:31
Mike Frysinger <[hidden email]> napisał(a):

> On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
> > Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
> > > On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> > > > (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.
> > >
> > > this patch keeps the status quo.  although the status quo is broken, but
> > > we
> > > can sort that out independently.
> >
> > Except that it breaks stuff that is installed at the point and comes
> > with no plan of cleaning up the resulting mess.
>
> such as ... ?  vague statements can't be addressed.
Such as all the builds that use ${CHOST}-foo currently. If you change
CHOST, our users will have to find and rebuild all packages that
install ${CHOST}-foos or otherwise random breakage will happen.

--
Best regards,
Michał Górny

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Mike Frysinger
On Thu 27 Mar 2014 10:10:07 Michał Górny wrote:

> Dnia 2014-03-27, o godz. 03:18:31 Mike Frysinger napisał(a):
> > On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
> > > Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
> > > > On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> > > > > (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.
> > > >
> > > > this patch keeps the status quo.  although the status quo is broken,
> > > > but
> > > > we
> > > > can sort that out independently.
> > >
> > > Except that it breaks stuff that is installed at the point and comes
> > > with no plan of cleaning up the resulting mess.
> >
> > such as ... ?  vague statements can't be addressed.
>
> Such as all the builds that use ${CHOST}-foo currently. If you change
> CHOST, our users will have to find and rebuild all packages that
> install ${CHOST}-foos or otherwise random breakage will happen.
again, please give a concrete example
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Michał Górny-5
Dnia 2014-03-27, o godz. 10:23:30
Mike Frysinger <[hidden email]> napisał(a):

> On Thu 27 Mar 2014 10:10:07 Michał Górny wrote:
> > Dnia 2014-03-27, o godz. 03:18:31 Mike Frysinger napisał(a):
> > > On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
> > > > Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
> > > > > On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> > > > > > (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.
> > > > >
> > > > > this patch keeps the status quo.  although the status quo is broken,
> > > > > but
> > > > > we
> > > > > can sort that out independently.
> > > >
> > > > Except that it breaks stuff that is installed at the point and comes
> > > > with no plan of cleaning up the resulting mess.
> > >
> > > such as ... ?  vague statements can't be addressed.
> >
> > Such as all the builds that use ${CHOST}-foo currently. If you change
> > CHOST, our users will have to find and rebuild all packages that
> > install ${CHOST}-foos or otherwise random breakage will happen.
>
> again, please give a concrete example
glib -- ${CHOST}-gdk-pixbuf-query-loaders (used in gnome2-utils.eclass)
gpg-error -- ${CHOST}-gpg-error-config
libgcrypt -- ${CHOST}-libgcrypt-config
llvm -- ${CHOST}-llvm-config
pango -- ${CHOST}-pango-querymodules

If you change CHOST, all invocations of those tools will fail randomly
until the respective packages are rebuilt. In some cases it will call
the wrong variant (resulting in borked output), in other it will call
non-existing tool.

And let's just hope it's the only issue we're going to hit.

--
Best regards,
Michał Górny

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Mike Frysinger
On Thu 27 Mar 2014 15:31:31 Michał Górny wrote:

> Dnia 2014-03-27, o godz. 10:23:30 Mike Frysinger napisał(a):
> > On Thu 27 Mar 2014 10:10:07 Michał Górny wrote:
> > > Dnia 2014-03-27, o godz. 03:18:31 Mike Frysinger napisał(a):
> > > > On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
> > > > > Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
> > > > > > On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
> > > > > > > (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.
> > > > > >
> > > > > > this patch keeps the status quo.  although the status quo is
> > > > > > broken,
> > > > > > but
> > > > > > we
> > > > > > can sort that out independently.
> > > > >
> > > > > Except that it breaks stuff that is installed at the point and comes
> > > > > with no plan of cleaning up the resulting mess.
> > > >
> > > > such as ... ?  vague statements can't be addressed.
> > >
> > > Such as all the builds that use ${CHOST}-foo currently. If you change
> > > CHOST, our users will have to find and rebuild all packages that
> > > install ${CHOST}-foos or otherwise random breakage will happen.
> >
> > again, please give a concrete example
>
> glib -- ${CHOST}-gdk-pixbuf-query-loaders (used in gnome2-utils.eclass)
> gpg-error -- ${CHOST}-gpg-error-config
> libgcrypt -- ${CHOST}-libgcrypt-config
> llvm -- ${CHOST}-llvm-config
> pango -- ${CHOST}-pango-querymodules
>
> If you change CHOST, all invocations of those tools will fail randomly
> until the respective packages are rebuilt. In some cases it will call
> the wrong variant (resulting in borked output), in other it will call
> non-existing tool.
so the *-config scripts.  we already know these are broken, not only from a
conceptual pov, but from real world too -- it relies on CHOST being unique.  
but this needs to be sorted out anyways since the current system isn't working
(independent of crossdev usage), and perhaps that means breaking now so things
are cleaner in the future.

for the gnupg projects, we've already disabled -L paths from being emitted, so
the variants will still work (gpg-error-config will give the same answer as
$CHOST-gpg-error-config wrt --libs and such).

the llvm/gdk/pango logic would probably break.  we had been looking at
rewriting the gdk/pango stuff to not require direct execution (since this
logic completely fails when cross-compiling) in Chromium OS, but that's been
on the back burner for a while.  instead, we hand generate/mung the pango
modules cache file, and we've punted gtk/gdk from the image, so we don't care
it is broken.

the pango stuff is also broken because it uses /etc/pango/$CHOST in an attempt
to get an ABI unique path.  we probably should change that to /etc/pango/$ABI
or /etc/pango/$(get_libdir) or move it the multilib dir like the gdk cache
does.  the gnome guys would know best.

the llvm impact doesn't look terribly big as very few things use it.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: crossdev and multilib interference

Mike Frysinger
In reply to this post by Steven J. Long
On Thu 27 Mar 2014 08:41:08 Steven J. Long wrote:

> Mike Frysinger wrote:
> > Steven J. Long wrote:
> > > Mike Frysinger wrote:
> > > > if they're in $PATH, then the exact location is irrelevant.
> > > > they need not be in /usr/bin to cause a problem.
> > > > if they're not in $PATH, then you're breaking the cross-compilers
> > > > and that is unacceptable.
> > >
> > > Cross-compilation should be supported via cross-emerge, and perhaps a
> > > small
> > > script the cross-compiler sources to setup the env (ie prefix to PATH in
> > > this case) for using CHOST-* tools, like x86-pc-linux-gnu-gcc targetting
> > > a straight x86 platform, instead of the normal multilib setup. The
> > > latter being used by the former (I'd have thought it was already done.)
> > >
> > > The cross tools should NOT pollute the default PATH, simply because the
> > > user happened to run crossdev at some point.
> >
> > that's bs.  people install crossdev to get a cross-compile environment,
> > not to get something that only works through `emerge`.  attempting to
> > restrict it so it only works through `emerge` is unacceptable and it has
> > never been that way.
>
> That's why I suggested a small sh script to source, to setup that
> environment. Personally, I do an awful lot more than that just to build a
> native chroot, let alone cross-compile. And I really don't see the hardship
> for these brave "cross-compilers" of yours in sourcing a small setup
> script, which can be added to ~/.bashrc or even the system-wide one, for
> anyone who really wants it to apply whenever they login. Is this somehow
> beyond our most advanced userbase?
>
> People may install crossdev to get a cross-compile environment, but it's a
> broken design if it's not contained. And BS about how you think it should
> ALWAYS go for everybody, only leads to borked "solutions" elsewhere like
> telling the people on an amd64 install that they have to run some god-awful
> "new" %multilib thing to compile for their secondary ABI. That's just as
> counter-intuitive, when you could just fix your borkage and have a clean
> setup for everyone.
your conclusions are invalid as you're basing them on the assumption that the
current multilib system is working correctly and cleanly.  it is provably not.

sticking your head in the sand and blaming crossdev for errors in the multilib
logic is asinine.
-mike

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Maciej Mrozowski-2
In reply to this post by Mike Frysinger
On Wednesday 26 of March 2014 02:07:56 Mike Frysinger wrote:

| cmake is completely broken when it comes to library searching and multilib and
| cross-compiling.  it will happily look in hardcoded / paths to test for the
| existence of files as well as directly execute `pkg-config`.  it's a great
| example of people saying "autotools is crap, so let's invent our own kind of
| crap and ignore lessons learned".  this isn't the fault of cmake eclasses, but
| it'd be nice if we could someone standardize the hacks in there so we don't
| have to duplicate across ebuilds.

If we provided toolchain.cmake (passed to CMake via -DCMAKE_TOOLCHAIN_FILE=<path>) file for each crossdev, that could not only set compiler paths/etc but also override CMAKE_SYSTEM_PREFIX_PATH, we would get pretty close to autotools.

Yes, CMake has pretty rudimentary (to put it mildly..) cross-compilation support but it still can be done there somewhat "right".

regards
MM

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Michał Górny-5
In reply to this post by Mike Frysinger
Dnia 2014-03-28, o godz. 02:33:09
Mike Frysinger <[hidden email]> napisał(a):

> the pango stuff is also broken because it uses /etc/pango/$CHOST in an attempt
> to get an ABI unique path.  we probably should change that to /etc/pango/$ABI
> or /etc/pango/$(get_libdir) or move it the multilib dir like the gdk cache
> does.  the gnome guys would know best.

Because inventing distro-specific directories is always the best
solution.

> the llvm impact doesn't look terribly big as very few things use it.

Indeed, most of Gentoo amd64 users don't care about being unable to
build Mesa at all.

--
Best regards,
Michał Górny

signature.asc (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Steven J. Long
In reply to this post by Mike Frysinger
Mike Frysinger wrote:

> Steven J. Long wrote:
> > Mike Frysinger wrote:
> > > Steven J. Long wrote:
> > > > The cross tools should NOT pollute the default PATH, simply because the
> > > > user happened to run crossdev at some point.
> > >
> > > that's bs.  people install crossdev to get a cross-compile environment,
> > > not to get something that only works through `emerge`.  attempting to
> > > restrict it so it only works through `emerge` is unacceptable and it has
> > > never been that way.
> >
> > That's why I suggested a small sh script to source, to setup that
> > environment. Personally, I do an awful lot more than that just to build a
> > native chroot, let alone cross-compile. And I really don't see the hardship
> > for these brave "cross-compilers" of yours in sourcing a small setup
> > script, which can be added to ~/.bashrc or even the system-wide one, for
> > anyone who really wants it to apply whenever they login. Is this somehow
> > beyond our most advanced userbase?
> >
> > People may install crossdev to get a cross-compile environment, but it's a
> > broken design if it's not contained.
>
> your conclusions are invalid as you're basing them on the assumption that
> the current multilib system is working correctly and cleanly.

No, I am not. I am basing them on the premise that a "target" SYSROOT is
potentially only one of N such sysroots for the same config.guess stanza.
I expected you to see that usage immediately, and the flexibility that
separation brings. After all, crossdev separates sysroots out already. It's
a trivial change to keep them separate, and it's easy for cross-compilers,
who already deal with this kind of thing, and more, on a daily basis. Only
it gives them more options should they want them, as I for one do.

No, use-cases are not relevant at this point. If you can't see it, that
doesn't meant it's not out there; it just means you're looking in the
wrong direction.

> it is provably not.
>
> sticking your head in the sand and blaming crossdev for errors in the
> multilib logic is asinine.

And sticking your head in the sand and ignoring flexibility, is simply your
usual ego-waving (as well as providing amusement at your rationalisation-
masquerading-as-logic.) I'd hoped you'd grown past this in the last few years,
since the embarrassing (to you) eclass-manpages awk bug, but evidently not.
It's why you're an awful recruiter, and imo a useless coder, despite being
a very talented QA person and bug-patcher.

The more you code, the more you have to realise how susceptible you are to
mistake. It's *after* you fully realise and _accept_ that, that you become
a truly useful coder. You are clearly still at the wrestling-with-the-ego
stage, after all these years. So you have my sympathy, because I know how
difficult a fight that is, and you're clearly in distress (or you wouldn't
resort to negative personal attacks so frequently, instead of considering
the application. So much bile..) The way to win is to stop fighting,
because you are only fighting yourself.

Accept that you are only a human, and you make mistakes and have blind-spots
just like everyone else. One's just been pointed out to you; do you do the
grown-up thing and accept that, and fix it, or do you keep on with the
tantrums, the dodgy patches and the baroque chain of "fixes" that flow from
your borked "logic"? Grow up, already. Or fire off more bile > /dev/null.

"I'll see you when you get there, if you ever get there.."

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
Steven J. Long:
>
> "I'll see you when you get there, if you ever get there.."
>

No improvements so far. I am going to hardmask sys-devel/crossdev,
unless someone can explain why we are still in broken stage.

More packages are popping up that randomly break. Recent failures were
related to tc-getBUILD_CC.

This isn't stable in any way. I'm not blaming anyone, but that's what
hardmasking is for. A working solution was declined, so...

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Chí-Thanh Christopher Nguyễn
hasufell schrieb:
> No improvements so far. I am going to hardmask sys-devel/crossdev,
> unless someone can explain why we are still in broken stage.
>
> More packages are popping up that randomly break. Recent failures were
> related to tc-getBUILD_CC.
>
> This isn't stable in any way. I'm not blaming anyone, but that's what
> hardmasking is for. A working solution was declined, so...

If I understand correctly, it is not the crossdev package being present on
the system, but the generated toolchains that cause the trouble.

I think there are less intrusive options than hardmask, such as pkg_pretend()
check or blocking offending packages from cross-${CTARGET} category.


Best regards,
Chí-Thanh Christopher Nguyễn


Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

Ryan Hill
In reply to this post by hasufell
On Sun, 15 Jun 2014 20:35:53 +0000
hasufell <[hidden email]> wrote:

> Steven J. Long:
> >
> > "I'll see you when you get there, if you ever get there.."
> >
>
> No improvements so far. I am going to hardmask sys-devel/crossdev,
> unless someone can explain why we are still in broken stage.

Do that and we'll have to take you out behind the woodshed.


--
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

signature.asc (486 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: crossdev and multilib interference

hasufell
Ryan Hill:

> On Sun, 15 Jun 2014 20:35:53 +0000
> hasufell <[hidden email]> wrote:
>
>> Steven J. Long:
>>>
>>> "I'll see you when you get there, if you ever get there.."
>>>
>>
>> No improvements so far. I am going to hardmask sys-devel/crossdev,
>> unless someone can explain why we are still in broken stage.
>
> Do that and we'll have to take you out behind the woodshed.
>
>

If you think having broken packages for months in stable arch is ok,
then you are wrong.

And btw., your funny threats don't impress me anymore.

I'll bring this up to the council agenda if you like. This is a
non-trivial tree-wide problem and if toolchain keeps ignoring it, then I
will hardmask the thing.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
In reply to this post by Chí-Thanh Christopher Nguyễn
Chí-Thanh Christopher Nguyễn:

> hasufell schrieb:
>> No improvements so far. I am going to hardmask sys-devel/crossdev,
>> unless someone can explain why we are still in broken stage.
>>
>> More packages are popping up that randomly break. Recent failures were
>> related to tc-getBUILD_CC.
>>
>> This isn't stable in any way. I'm not blaming anyone, but that's what
>> hardmasking is for. A working solution was declined, so...
>
> If I understand correctly, it is not the crossdev package being present on
> the system, but the generated toolchains that cause the trouble.
>
> I think there are less intrusive options than hardmask, such as pkg_pretend()
> check or blocking offending packages from cross-${CTARGET} category.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>

There was a proposed solution which works perfectly fine: don't clutter
PATH with crossdev links.

If any embedded developer needs these tools in PATH he can add them
temporarily (I'm pretty sure he knows how; an elog can be added as
well), via wrapper scripts or whatnot. That's a reasonable trade-off.

However, toolchain does not agree and I don't randomly touch other
peoples packages (unless there is no response).

So there are only two things left:
* block crossdev within multilib eclasses (that sounds really wrong to me)
* hardmask it, so we are able to communicate this problem to the user

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Steev Klimaszewski-2
On Mon, 2014-06-16 at 13:37 +0000, hasufell wrote:

> Chí-Thanh Christopher Nguyễn:
> > hasufell schrieb:
> >> No improvements so far. I am going to hardmask sys-devel/crossdev,
> >> unless someone can explain why we are still in broken stage.
> >>
> >> More packages are popping up that randomly break. Recent failures were
> >> related to tc-getBUILD_CC.
> >>
> >> This isn't stable in any way. I'm not blaming anyone, but that's what
> >> hardmasking is for. A working solution was declined, so...
> >
> > If I understand correctly, it is not the crossdev package being present on
> > the system, but the generated toolchains that cause the trouble.
> >
> > I think there are less intrusive options than hardmask, such as pkg_pretend()
> > check or blocking offending packages from cross-${CTARGET} category.
> >
> >
> > Best regards,
> > Chí-Thanh Christopher Nguyễn
> >
> >
>
> There was a proposed solution which works perfectly fine: don't clutter
> PATH with crossdev links.
>
> If any embedded developer needs these tools in PATH he can add them
> temporarily (I'm pretty sure he knows how; an elog can be added as
> well), via wrapper scripts or whatnot. That's a reasonable trade-off.
>
> However, toolchain does not agree and I don't randomly touch other
> peoples packages (unless there is no response).
>
> So there are only two things left:
> * block crossdev within multilib eclasses (that sounds really wrong to me)
> * hardmask it, so we are able to communicate this problem to the user
>

I'm someone who uses crossdev (and the cross compilers) quite heavily -
can you point me to a bug that you're talking about? I'm not in the
toolchain, and while I agree that temporarily adding the cross
compiler(s) to the PATH is easy, for some of us, it's easier to allow
Gentoo to do so.

I'm not a huge fan of multilib, but at the same time, I'd like to not
see crossdev being hardmasked, just to prove your point.  I don't have
near as much free time as I'd like, but I may try to squeeze some time
in to help out.


Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

hasufell
Steev Klimaszewski:

>
> I'm someone who uses crossdev (and the cross compilers) quite heavily -
> can you point me to a bug that you're talking about? I'm not in the
> toolchain, and while I agree that temporarily adding the cross
> compiler(s) to the PATH is easy, for some of us, it's easier to allow
> Gentoo to do so.
>
> I'm not a huge fan of multilib, but at the same time, I'd like to not
> see crossdev being hardmasked, just to prove your point.  I don't have
> near as much free time as I'd like, but I may try to squeeze some time
> in to help out.
>
>

see https://bugs.gentoo.org/show_bug.cgi?id=500338

emerge a native x86 toolchain and enable ABI_X86="32" globally. A lot of
packages randomly fail, either because of wrong PKG_CONFIG being picked
up or even wrong CC/CXX, causing failure at linking stage and whatnot.

Also check the history of this thread for a few proposed solutions.

Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: crossdev and multilib interference

Jeroen Roovers-3
On Mon, 16 Jun 2014 19:31:58 +0000
hasufell <[hidden email]> wrote:

> Also check the history of this thread for a few proposed solutions.

The history of this thread and the history of gx86-multilib and
crossdev development suggest that crossdev was doing nothing wrong until
gx86-multilib came around and a problem was found between them. Masking
either for the benefit of the other would be, and let me quote the
history of this thread out of context just to fit in with the tone and
mode this sub-thread has taken, "asinine".


     jer

12345