Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] MULTI_ABI support addition to main tree portage
Date: Sat, 29 Jan 2011 19:13:44
Message-Id: 1296328380.14673.3.camel@localhost.localdomain
In Reply to: Re: [gentoo-dev] MULTI_ABI support addition to main tree portage by Thomas Sachau
1 El sáb, 29-01-2011 a las 19:56 +0100, Thomas Sachau escribió:
2 > Am 29.01.2011 19:30, schrieb Pacho Ramos:
3 > > El sáb, 29-01-2011 a las 13:10 -0500, Nathan Phillip Brink escribió:
4 > >> On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote:
5 > >>>
6 > >>> Hello
7 > >>>
8 > >>> I would like to know what is "blocking" this from landing main tree in
9 > >>> the "near" future, as I reviewed:
10 > >>>
11 > >>> http://www.mail-archive.com/gentoo-dev@l.g.o/msg41737.html
12 > >>>
13 > >>> and looks like there wasn't major problems (at least commented in this
14 > >>> thread)
15 > >>
16 > >> There are still a number of known build failures, tracked in
17 > >> https://bugs.gentoo.org/alias/portage-multilib . There are probably
18 > >> many more portage-multilib-related build failures which haven't been
19 > >> encountered yet nor reported. Also, even these reported bugs are not
20 > >> necessarily fixed first because they only affect us the minority ;-).
21 > >
22 > > OK, thanks. Maybe bug 306835 should block bug 145737 instead of
23 > > depending on it, not?
24 >
25 > I think, they are mostly dublicates, bug 145737 was the original multilib-portage idea of kanaka,
26 > but he discontinued it. The version of today (bug 306835) does partly base on his work and partly on
27 > the work with the native-multilib eclass from some Gentoo users with some additional changes from me.
28 >
29 > >
30 > >>
31 > >> Most everything is easy to debug and as simple as replacing calls to
32 > >> $(LD) in poorly-written Makefileswith with calls to $(CC), fixing
33 > >> packages which ignore CFLAGS (where we store our -m32) or LDFLAGS
34 > >> (where we now also store -m32 since one's not allowed to require
35 > >> buildsystems to call $(CC) with $(CFLAGS) when objects are being
36 > >> linked into an executable or library).
37 > >>
38 > >> However, packages which use qmake or cmake macros installed by KDE are
39 > >> more difficult to debug and there are other funny issues such as
40 > >> CFLAGS being stored by a library's buildsystem and stored into
41 > >> /usr/share instead of an ABI-dependent directory, breaking packages
42 > >> which use that library... ;-)
43 > >>
44 > >> Also, there are still some decisions/changes to portage-multilib which
45 > >> might be made The most recent idea discussed was: should ${ARCH}
46 > >> useflags (like SRC_URI="x86? ( http://host/my-binari-x86.tar.bz2 )")
47 > >> be replaced with ${ABI} useflags or should we rewrite a bunch of
48 > >> ebuilds in the tree to be multilib-aware? For example:
49 > >>
50 > >> Say we have
51 > >> ABI=x86
52 > >> ARCH=amd64
53 > >>
54 > >> Does ``use x86'' return true or do we need to use ``use multilib_abi_x86''?
55 > >> Do detect the true arch, do we need ``use arch_amd64'' or does ``use amd64'' still return true?
56 > >>
57 > >
58 > > Where do you discuss things like this? IRC channel? Mailing-list?
59 > > Thanks :-)
60 >
61 > Most communication is done in #gentoo-multilib-overlay on freenode IRC. I have also created a mail
62 > alias (multilib@g.o), but it is only used for some bugzilla assignments at the moment.
63 >
64 >
65
66 OK, thanks a lot

Attachments

File name MIME type
signature.asc application/pgp-signature