[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] MULTI_ABI support addition to main tree portage
From:       Pacho Ramos <pacho () gentoo ! org>
Date:       2011-01-29 19:13:00
Message-ID: 1296328380.14673.3.camel () localhost ! localdomain
[Download RAW message or body]


El sáb, 29-01-2011 a las 19:56 +0100, Thomas Sachau escribió:
> Am 29.01.2011 19:30, schrieb Pacho Ramos:
> > El sáb, 29-01-2011 a las 13:10 -0500, Nathan Phillip Brink escribió:
> >> On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote:
> >>>
> >>> Hello
> >>>
> >>> I would like to know what is "blocking" this from landing main tree in
> >>> the "near" future, as I reviewed:
> >>>
> >>> http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html
> >>>
> >>> and looks like there wasn't major problems (at least commented in this
> >>> thread)
> >>
> >> There are still a number of known build failures, tracked in
> >> https://bugs.gentoo.org/alias/portage-multilib . There are probably
> >> many more portage-multilib-related build failures which haven't been
> >> encountered yet nor reported. Also, even these reported bugs are not
> >> necessarily fixed first because they only affect us the minority ;-).
> > 
> > OK, thanks. Maybe bug 306835 should block bug 145737 instead of
> > depending on it, not?
> 
> I think, they are mostly dublicates, bug 145737 was the original multilib-portage idea of kanaka,
> but he discontinued it. The version of today (bug 306835) does partly base on his work and partly on
> the work with the native-multilib eclass from some Gentoo users with some additional changes from me.
> 
> > 
> >>
> >> Most everything is easy to debug and as simple as replacing calls to
> >> $(LD) in poorly-written Makefileswith with calls to $(CC), fixing
> >> packages which ignore CFLAGS (where we store our -m32) or LDFLAGS
> >> (where we now also store -m32 since one's not allowed to require
> >> buildsystems to call $(CC) with $(CFLAGS) when objects are being
> >> linked into an executable or library).
> >>
> >> However, packages which use qmake or cmake macros installed by KDE are
> >> more difficult to debug and there are other funny issues such as
> >> CFLAGS being stored by a library's buildsystem and stored into
> >> /usr/share instead of an ABI-dependent directory, breaking packages
> >> which use that library... ;-)
> >>
> >> Also, there are still some decisions/changes to portage-multilib which
> >> might be made The most recent idea discussed was: should ${ARCH}
> >> useflags (like SRC_URI="x86? ( http://host/my-binari-x86.tar.bz2 )")
> >> be replaced with ${ABI} useflags or should we rewrite a bunch of
> >> ebuilds in the tree to be multilib-aware? For example:
> >>
> >> Say we have
> >> ABI=x86
> >> ARCH=amd64
> >>
> >> Does ``use x86'' return true or do we need to use ``use multilib_abi_x86''?
> >> Do detect the true arch, do we need ``use arch_amd64'' or does ``use amd64'' still return true?
> >>
> > 
> > Where do you discuss things like this? IRC channel? Mailing-list?
> > Thanks :-)
> 
> Most communication is done in #gentoo-multilib-overlay on freenode IRC. I have also created a mail
> alias (multilib@g.o), but it is only used for some bugzilla assignments at the moment.
> 
> 

OK, thanks a lot

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]