[gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Samuli Suominen]

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/developer/make.defaults?r1=1.11&r2=1.12

For example (these are all where they belong):

$ file /usr/lib/udisks2/udisksd
/usr/lib/udisks2/udisksd: ELF 64-bit LSB executable, x86-64, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

$ file /usr/lib/udev/* |grep ELF
/usr/lib/udev/accelerometer:             ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/ata_id:                    ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/cdrom_id:                  ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/collect:                   ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/hid2hci:                   ELF 64-bit LSB shared object, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/ift-load:                  ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/ipod-set-info:             ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/keymap:                    ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/mtd_probe:                 ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/mtp-probe:                 ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/scsi_id:                   ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udev-configure-printer:    ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-dm-export:          ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-lvm-pv-export:      ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-part-id:            ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-probe-ata-smart:    ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/udisks-probe-sas-expander: ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped
/usr/lib/udev/v4l_id:                    ELF 64-bit LSB executable, 
x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for 
GNU/Linux 2.6.9, stripped

I propably won't be working on this much, so help would be appericiated 
for restoring working multilib-strict check.

Thanks, Samuli

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Diego Elio Pettenò]

On 13/08/2012 09:55, Samuli Suominen wrote:
> 
> I propably won't be working on this much, so help would be appericiated
> for restoring working multilib-strict check.

Beside the fact that these would probably have looked better in
/usr/libexec — there used to be a whitelist of stuff that can be
installed in /usr/lib, can't you just add udev and udisks to that list?

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Alexandre Rostovtsev]

On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote:
> Beside the fact that these would probably have looked better in
> /usr/libexec

See Kay Sievers's comment at
https://bugs.freedesktop.org/show_bug.cgi?id=51617 :

"/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
shares absolutely zero things with the arch-specific $libdir ,or lib64/.

/usr/lib/<pkgname>/ is the canonical "application private directory". It
has the multi-lib or arch-specific rules as /bin.

It just happens to be the same directory as $libdir for 32bit
installations in the classic non-multi-arch layout, which might go away
over time, but that is absolutely no reason to symlink it away.

Having /lib pointing to /lib64 is plain wrong, and should not explicitly
be supported by upstream build systems. If it happens to be that
libexecdir works for that, then it's fine, but it is surely not treated
as a bug if it isn't."

-Alexandre

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Diego Elio Pettenò]

On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
> "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
> shares absolutely zero things with the arch-specific $libdir ,or lib64/.

Yes I know that FHS allows it. I still think it would be cleaner to use
/usr/libexec.

It's the usual difference between trying to be right and being pragmatic
about it.

You (and Kay) want to be right ignoring the fact that $tons of software
expects /usr/lib to just be another $libdir.

I'd rather be pragmatic and choose /usr/libexec which _clearly_ isn't.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Samuli Suominen]

On 14.08.2012 00:24, Diego Elio Pettenò wrote:
> On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
>> "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
>> shares absolutely zero things with the arch-specific $libdir ,or lib64/.
>
> Yes I know that FHS allows it. I still think it would be cleaner to use
> /usr/libexec.

I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/ 
on "daily basis"

> You (and Kay) want to be right ignoring the fact that $tons of software
> expects /usr/lib to just be another $libdir.

Count me in then I guess :/

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Diego Elio Pettenò]

On 14/08/2012 02:57, Samuli Suominen wrote:
> I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/
> on "daily basis"

So instead of discussing this you just decide you don't like the path
and go with your preference?

Honestly I would have preferred for this to go through council as _it
already went through it once_....

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Samuli Suominen]

On 14.08.2012 16:35, Diego Elio Pettenò wrote:
> On 14/08/2012 02:57, Samuli Suominen wrote:
>> I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/
>> on "daily basis"
>
> So instead of discussing this you just decide you don't like the path
> and go with your preference?
>
> Honestly I would have preferred for this to go through council as _it
> already went through it once_....
>

Sorry I was vague in that statement, I meant moving to both /usr/lib/ 
when suitable (and usually the default from upstream lately) and 
/usr/lib64/xfce* (Location of .so Xfce plugins)
Xfce had compability code for finding plugins from /usr/libexec only for 
4.10 series, and is marked as -DXFCE_DEPRECATED code, 4.12 will solely 
use /usr/lib64/xfce4/
I've done nothing against the status quo, only following sane reasoning 
and defaults from upstreams who have made a strong case for it being so,
or when they have actually made it impossible without carrying custom 
patches forever

So all good, I hope this cleared misunderstandings

- Samuli

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Samuli Suominen]

On 14.08.2012 19:57, Samuli Suominen wrote:
> On 14.08.2012 16:35, Diego Elio Pettenò wrote:
>> On 14/08/2012 02:57, Samuli Suominen wrote:
>>> I highly dislike libexec and have been moving stuff over /usr/lib/$pkg/
>>> on "daily basis"
>>
>> So instead of discussing this you just decide you don't like the path
>> and go with your preference?
>>
>> Honestly I would have preferred for this to go through council as _it
>> already went through it once_....
>>
>
> Sorry I was vague in that statement, I meant moving to both /usr/lib/
> when suitable (and usually the default from upstream lately) and
> /usr/lib64/xfce* (Location of .so Xfce plugins)

and possible couple of others than /usr/lib64/xfce*... meh, should 
really proof read my own msgs

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Diego Elio Pettenò]

On 14/08/2012 09:57, Samuli Suominen wrote:
> 
> Sorry I was vague in that statement, I meant moving to both /usr/lib/
> when suitable (and usually the default from upstream lately) and
> /usr/lib64/xfce* (Location of .so Xfce plugins)
> Xfce had compability code for finding plugins from /usr/libexec only for
> 4.10 series, and is marked as -DXFCE_DEPRECATED code, 4.12 will solely
> use /usr/lib64/xfce4/
> I've done nothing against the status quo, only following sane reasoning
> and defaults from upstreams who have made a strong case for it being so,
> or when they have actually made it impossible without carrying custom
> patches forever

For plugins (if they are plugins) we really need to use the $libdir as
they are ABI-dependent, so I'm perfectly happy with moving them out of
libexec (shouldn't have been there in the first place).

I'd still would like a revisit by council for what concerns /usr/libexec
though. I'm afraid that last time I let it slide after Kugelfang
promised he would write a draft that never came, as we had issue with cups.

In general, I'm in favour of using lib (and not $libdir) if they are
_executables_, which means they are not loaded in the same address space
of any other program. I'm just concerned of having another hundred
directories in /usr/lib as that could slow down ld.so...

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Tue, 14 Aug 2012 12:57:13 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 14.08.2012 00:24, Diego Elio Pettenò wrote:
> > On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
> >> "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or
> >> even /bin. It shares absolutely zero things with the arch-specific
> >> $libdir ,or lib64/.
> >
> > Yes I know that FHS allows it. I still think it would be cleaner to
> > use /usr/libexec.
> 
> I highly dislike libexec and have been moving stuff
> over /usr/lib/$pkg/ on "daily basis"

I believe we should be keeping «aligned» paths somewhere rather than
randomly moving stuff by hand. If you're saying that /usr/lib/${PN} ==
libexec, maybe we should put that into PMS as --libexecdir=?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Samuli Suominen]

On 14.08.2012 17:05, Michał Górny wrote:
> On Tue, 14 Aug 2012 12:57:13 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> On 14.08.2012 00:24, Diego Elio Pettenò wrote:
>>> On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
>>>> "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or
>>>> even /bin. It shares absolutely zero things with the arch-specific
>>>> $libdir ,or lib64/.
>>>
>>> Yes I know that FHS allows it. I still think it would be cleaner to
>>> use /usr/libexec.
>>
>> I highly dislike libexec and have been moving stuff
>> over /usr/lib/$pkg/ on "daily basis"
>
> I believe we should be keeping «aligned» paths somewhere rather than
> randomly moving stuff by hand. If you're saying that /usr/lib/${PN} ==
> libexec, maybe we should put that into PMS as --libexecdir=?
>

I would agree to this.

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Samuli Suominen]

On 14.08.2012 17:05, Michał Górny wrote:
> On Tue, 14 Aug 2012 12:57:13 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>
>> On 14.08.2012 00:24, Diego Elio Pettenò wrote:
>>> On 13/08/2012 11:29, Alexandre Rostovtsev wrote:
>>>> "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or
>>>> even /bin. It shares absolutely zero things with the arch-specific
>>>> $libdir ,or lib64/.
>>>
>>> Yes I know that FHS allows it. I still think it would be cleaner to
>>> use /usr/libexec.
>>
>> I highly dislike libexec and have been moving stuff
>> over /usr/lib/$pkg/ on "daily basis"
>
> I believe we should be keeping «aligned» paths somewhere rather than
> randomly moving stuff by hand. If you're saying that /usr/lib/${PN} ==
> libexec, maybe we should put that into PMS as --libexecdir=?
>

With a EAPI bump, of course, to prevent breakage.

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Mike Gilbert]

On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
<tetromino@gentoo.org> wrote:
> On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote:
>> Beside the fact that these would probably have looked better in
>> /usr/libexec
>
> See Kay Sievers's comment at
> https://bugs.freedesktop.org/show_bug.cgi?id=51617 :
>
> "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
> shares absolutely zero things with the arch-specific $libdir ,or lib64/.
>
> /usr/lib/<pkgname>/ is the canonical "application private directory". It
> has the multi-lib or arch-specific rules as /bin.
>

So... where should GRUB2 be installing its modules? Currently they get
installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and
platform are determined by use flags.

Should we drop the get_libdir and put them in /usr/lib/grub instead?
Should I even worry about it?

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

On Mon, 2012-08-13 at 17:56 -0400, Mike Gilbert wrote:
> On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
> <tetromino@gentoo.org> wrote:
> > On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote:
> >> Beside the fact that these would probably have looked better in
> >> /usr/libexec
> >
> > See Kay Sievers's comment at
> > https://bugs.freedesktop.org/show_bug.cgi?id=51617 :
> >
> > "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
> > shares absolutely zero things with the arch-specific $libdir ,or lib64/.
> >
> > /usr/lib/<pkgname>/ is the canonical "application private directory". It
> > has the multi-lib or arch-specific rules as /bin.
> >
> 
> So... where should GRUB2 be installing its modules? Currently they get
> installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and
> platform are determined by use flags.
> 
> Should we drop the get_libdir and put them in /usr/lib/grub instead?
> Should I even worry about it?

There really have no reason to be in $(get_libdir) as they're not
compiled for the platform implied by $(get_libdir) !

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Samuli Suominen]

On 14.08.2012 03:24, Olivier Crête wrote:
> On Mon, 2012-08-13 at 17:56 -0400, Mike Gilbert wrote:
>> On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev
>> <tetromino@gentoo.org> wrote:
>>> On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote:
>>>> Beside the fact that these would probably have looked better in
>>>> /usr/libexec
>>>
>>> See Kay Sievers's comment at
>>> https://bugs.freedesktop.org/show_bug.cgi?id=51617 :
>>>
>>> "/usr/lib/<pkgname>/ is a directory like /usr/libexec/ or even /bin. It
>>> shares absolutely zero things with the arch-specific $libdir ,or lib64/.
>>>
>>> /usr/lib/<pkgname>/ is the canonical "application private directory". It
>>> has the multi-lib or arch-specific rules as /bin.
>>>
>>
>> So... where should GRUB2 be installing its modules? Currently they get
>> installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and
>> platform are determined by use flags.
>>
>> Should we drop the get_libdir and put them in /usr/lib/grub instead?
>> Should I even worry about it?
>
> There really have no reason to be in $(get_libdir) as they're not
> compiled for the platform implied by $(get_libdir) !
>

+1, that's correct.

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/13/2012 12:55 PM, Samuli Suominen wrote:
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/developer/make.defaults?r1=1.11&r2=1.12
> 
> 
> For example (these are all where they belong):

I know it seems silly but there are already so many multilib-strict
violations which creep into the tree, isn't there a viable QA_something
we can use for this one ebuild instead of disabling a critical sanity check?

- -Zero_Chaos
> 
> $ file /usr/lib/udisks2/udisksd
> /usr/lib/udisks2/udisksd: ELF 64-bit LSB executable, x86-64, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
> stripped
> 
> $ file /usr/lib/udev/* |grep ELF
> /usr/lib/udev/accelerometer:             ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/ata_id:                    ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/cdrom_id:                  ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/collect:                   ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/hid2hci:                   ELF 64-bit LSB shared object,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/ift-load:                  ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/ipod-set-info:             ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/keymap:                    ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/mtd_probe:                 ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/mtp-probe:                 ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/scsi_id:                   ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udev-configure-printer:    ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-dm-export:          ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-lvm-pv-export:      ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-part-id:            ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-probe-ata-smart:    ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/udisks-probe-sas-expander: ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> /usr/lib/udev/v4l_id:                    ELF 64-bit LSB executable,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.9, stripped
> 
> I propably won't be working on this much, so help would be appericiated
> for restoring working multilib-strict check.
> 
> Thanks, Samuli
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQKUamAAoJEKXdFCfdEflKrAkP/0FykSpEUSmKDDPOWzMDIEx0
mdBIHu1o709ZKxITacfee6KIM2nxQCPim6qykczePevKWQ3GS5MRe0PiLgfb9/Y1
3DcTtCBFn+YlvpI/Esg2Ei8zrXokO2/etwCXCyyd6PbHhTKAetbQ6uOvMQnl0GOd
U/UykQITHGLDm2fqZR1OTXKfR8QzjD5+AtPbkx8kDN3k/IxpMbCaShRnzz7ScDab
MFzrIfpz4Swxkmolo5awYvpb+6qWGDH8/9OND2kev57clkUOO5TkaZq3T26sPXFP
tMMLOYKjYc20BN4AE9hgjMX75egaqQuKJli2dh4L7VYLWg3VEqaJghfhL5p52vRM
n/zjkjX0QP/wtb0Qa3i3Y0tL2VIm0iburb0SIQhO992vaOhoTTaYSHcNr5bU/ZUW
nyrbr9BL1sHOz39cg+oeKB7e40VlaoeybjHCHCJ1v0tjKjrf2jTTFJQN7hkk5tx+
MVxYY8+1QOWCJJO4Ft2Oa8JBuaCBcBeFb4ZOZZdZO86vvRzOqxEmfPmxu0pZqsbT
9JIwQrg5hUXaknZKT/Ib1Ibm3lrCSj6zSW31VbAAVX/crLYgT+fSq7UxrVbj4lGM
k2wEzrbPoX7eC6xM4ZDdU1OHKvXV5HJExCgQ9lA1xsNlxo13E7cg6xkKXApxUeDM
+K1Fbp7ZqnRekj1FbUpO
=MP0C
-----END PGP SIGNATURE-----

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Samuli Suominen]

On 13.08.2012 19:55, Samuli Suominen wrote:
[ ... ]

I should mention that we have discussed this already,

https://bugs.gentoo.org/show_bug.cgi?id=364375

Which was a result of long gentoo-dev ML thread, unfortunately my search 
foo failed and I couldn't find straight link to it

Why should we threat /usr than / any different in this regard, there was 
large consensus /lib/udev should be used instead of /lib64/udev and 
udev.pc's udevdir= is the path for "udev helpers", ELFs(!), and rules 
among other things

It's completely fair to say that multilib-strict feature has been broken 
ever since, years.

- Samuli

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Alexis Ballier]

On Tue, 14 Aug 2012 20:03:50 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 13.08.2012 19:55, Samuli Suominen wrote:
> [ ... ]
> 
> I should mention that we have discussed this already,
> 
> https://bugs.gentoo.org/show_bug.cgi?id=364375
> 
> Which was a result of long gentoo-dev ML thread, unfortunately my
> search foo failed and I couldn't find straight link to it
> 
> Why should we threat /usr than / any different in this regard, there
> was large consensus /lib/udev should be used instead of /lib64/udev
> and udev.pc's udevdir= is the path for "udev helpers", ELFs(!), and
> rules among other things
> 
> It's completely fair to say that multilib-strict feature has been
> broken ever since, years.

well, i dont agree its fair :P
it breaks on _pie_ executables, which are not that common if you dont
run hardened.

what is broken, and has been broken since years is multilib-strict +
pie toolchain; a flaw in the multilib-strict detection system that gets
confused by 'file' output on pie executables :)

A.

Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 316 bytes --]

On Tuesday 14 August 2012 13:37:25 Alexis Ballier wrote:
> it breaks on _pie_ executables, which are not that common if you dont
> run hardened.

every Gentoo system has PIEs on it.  not many, but some.

file /*bin/* /usr/*bin/* | grep shared.object

(i wonder why cups is building itself as PIE actually ...)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]