public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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.


  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