From: Alexis Ballier <aballier@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: tommy@gentoo.org
Subject: Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
Date: Sat, 9 Mar 2013 11:45:34 +0100 [thread overview]
Message-ID: <20130309114534.138bf931@portable> (raw)
In-Reply-To: <5139F940.5060205@gentoo.org>
On Fri, 08 Mar 2013 15:44:16 +0100
Thomas Sachau <tommy@gentoo.org> wrote:
> Alexis Ballier schrieb:
> > On Thu, 07 Mar 2013 19:59:35 +0100
> > Thomas Sachau <tommy@gentoo.org> wrote:
> >>
> >> I dont have a list of binaries, i either noticed myself some
> >> abi-specific behaviour or got user reports for abi-specific
> >> behaviour. As an example i remember, dev-libs/libIDL has a config
> >> binary not matching the usual *-config scheme (libIDL-config-2),
> >> so instead of adding a random list of patterns, i simply added
> >> that package to the list of packages with wrapped binaries. The
> >> same applies to mysql, which has a mysql_config binary.
> >
> > Ok, so those make perfect sense for being wrapped and should be done
> > per-binary not per-package: We do not really want to wrap all mysql
> > binaries just for mysql_config.
> > Ebuilds should declare the binaries they want to be wrapped, so we
> > can grep the tree for getting a list of what to fight against if we
> > want a cleaner multilib system :)
>
> This is possible, but will make the solution more complex or limited
> (either the solution does not allow users to opt-in for wrapping all
> binaries of a package or you need an additional option for users to
> opt-in beside the variable, which includes the needed binaries).
Why do you want _users_ to do that? Ebuilds should do it. We are
talking about multi_lib_ not multi_arch_ after all :)
If you want to wrap all binaries, it may be allowable to have a regexp
there so that '*/bin/*' would wrap them all, but I don't think it is a
good idea to do that.
> >> I am not sure about the target of your qmake question, so as a
> >> general answer:
> >>
> >> qmake is something like configure for qmake based build systems. If
> >> you want to see the difference between qmake (32bit) and qmake
> >> (64bit), run a 64bit qmake on a qmake based package and do the same
> >> with a 32bit qmake and check the difference between the 2 runs.
> >
> > Well, I'm asking this because I don't have access to a 32bit qmake
> > here so a diff of the files generated by the two will be useful :P
> > And I believe it makes sense to study in details this case to
> > understand whether we want to wrap it or not. As Davide said, it is
> > likely that overriding the correct variable may make qmake output
> > not abi-specific. The difference between g++-64 and g++-32 qmake
> > mkspec is only a -m32 vs -m64 cflag which I think is overridden
> > elsewhere in our ebuilds so this should not matter much.
>
> If you want an example diff, can you point me to a small qmake based
> package?
media-video/smplayer or media-sound/qjackctl but this one also uses
autoconf before
Alexis.
next prev parent reply other threads:[~2013-03-09 10:45 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-02 23:02 [gentoo-dev] [RFC] multilib-build.eclass and restricting unsupported ABIs Michał Górny
2013-03-03 11:41 ` Alexis Ballier
2013-03-03 12:37 ` Michał Górny
2013-03-03 13:02 ` [gentoo-dev] " Thomas Sachau
2013-03-03 15:24 ` Alexis Ballier
2013-03-03 15:47 ` Thomas Sachau
2013-03-03 16:10 ` Alexis Ballier
2013-03-03 16:27 ` Thomas Sachau
2013-03-03 16:35 ` Alexis Ballier
2013-03-03 21:39 ` Thomas Sachau
2013-03-04 9:42 ` Alexis Ballier
2013-03-03 16:58 ` Michał Górny
2013-03-03 17:18 ` Alexis Ballier
2013-03-03 22:25 ` Michał Górny
2013-03-04 10:02 ` Alexis Ballier
2013-03-04 20:17 ` Thomas Sachau
2013-03-07 16:29 ` Alexis Ballier
2013-03-07 18:59 ` Thomas Sachau
2013-03-08 3:17 ` Davide Pesavento
2013-03-08 14:33 ` Thomas Sachau
2013-03-08 4:47 ` Michał Górny
2013-03-08 11:13 ` Alexis Ballier
2013-03-08 11:10 ` Alexis Ballier
2013-03-08 14:44 ` Thomas Sachau
2013-03-09 10:45 ` Alexis Ballier [this message]
2013-03-04 20:49 ` Michał Górny
2013-03-04 22:21 ` Thomas Sachau
2013-03-04 22:49 ` Michał Górny
2013-03-08 18:25 ` [gentoo-dev] " Steven J. Long
2013-03-07 16:25 ` [gentoo-dev] " Alexis Ballier
2013-03-08 16:30 ` Michał Górny
2013-03-09 10:10 ` Alexis Ballier
2013-03-10 13:42 ` Michał Górny
2013-03-15 10:32 ` Alexis Ballier
2013-03-15 14:25 ` Michał Górny
2013-03-03 16:00 ` Chí-Thanh Christopher Nguyễn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130309114534.138bf931@portable \
--to=aballier@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=tommy@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox