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: Fri, 8 Mar 2013 12:10:54 +0100	[thread overview]
Message-ID: <20130308121054.60b922bf@portable> (raw)
In-Reply-To: <5138E397.4040700@gentoo.org>

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 :)

> 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.

Alexis.


  parent reply	other threads:[~2013-03-08 11:11 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 [this message]
2013-03-08 14:44                           ` Thomas Sachau
2013-03-09 10:45                             ` Alexis Ballier
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=20130308121054.60b922bf@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