[PATCH 0/2 v2] Udev multilib fixes

[PATCH 0/2 v2] Udev multilib fixes

[Radu Moisan]

Changed /lib with ${base_libdir}
Fixes [YOCTO #4096]

Radu Moisan (2):
  initramfs-live-boot: enable multilib support
  udev: enable multilib support

 .../initrdscripts/initramfs-live-boot_1.0.bb       |    1 +
 meta/recipes-core/udev/udev.inc                    |    1 +
 2 files changed, 2 insertions(+)

-- 
1.7.9.5

[PATCH 1/2] initramfs-live-boot: enable multilib support

[Radu Moisan]

Use base_libdir instead harcoded /lib
Fixes [YOCTO #4096]

Signed-off-by: Radu Moisan <radu.moisan@intel.com>
---
 .../initrdscripts/initramfs-live-boot_1.0.bb       |    1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
index 1e674a4..0c354ae 100644
--- a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
@@ -15,6 +15,7 @@ do_compile() {
 }
  
 do_install() {
+        sed -i 's@/lib/udev@${base_libdir}/udev@g' ${WORKDIR}/init-live.sh
         install -m 0755 ${WORKDIR}/init-live.sh ${D}/init
 }
 
-- 
1.7.9.5

[PATCH 2/2] udev: enable multilib support

[Radu Moisan]

Use base_libdir in place of hardcoded /lib
Fixes [YOCTO #4096]

Signed-off-by: Radu Moisan <radu.moisan@intel.com>
---
 meta/recipes-core/udev/udev.inc |    1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index e358d2d..6fd0240 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -76,6 +76,7 @@ FILES_udev-utils = "${bindir}/udevadm"
 
 do_install_append () {
 	install -d ${D}${sysconfdir}/init.d
+	sed -i 's@/lib/udev@${base_libdir}/udev@g' ${WORKDIR}/init
 	install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
 	install -m 0755 ${WORKDIR}/udev-cache ${D}${sysconfdir}/init.d/udev-cache
 
-- 
1.7.9.5

Re: [PATCH 2/2] udev: enable multilib support

[Koen Kooi]

Op 3 apr. 2013, om 18:25 heeft Radu Moisan <radu.moisan@intel.com> het volgende geschreven:

> Use base_libdir in place of hardcoded /lib
> Fixes [YOCTO #4096]
> 
> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
> ---
> meta/recipes-core/udev/udev.inc |    1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
> index e358d2d..6fd0240 100644
> --- a/meta/recipes-core/udev/udev.inc
> +++ b/meta/recipes-core/udev/udev.inc
> @@ -76,6 +76,7 @@ FILES_udev-utils = "${bindir}/udevadm"
> 
> do_install_append () {
> 	install -d ${D}${sysconfdir}/init.d
> +	sed -i 's@/lib/udev@${base_libdir}/udev@g' ${WORKDIR}/init
> 	install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
> 	install -m 0755 ${WORKDIR}/udev-cache ${D}${sysconfdir}/init.d/udev-cache

NACK! The udev maintainers have been clear that it is always /lib/udev, even on 64 bit systems, so you're not fixing a problem, you're creating an extra one.

Re: [PATCH 2/2] udev: enable multilib support

[Burton, Ross]

On 3 April 2013 18:58, Koen Kooi <koen@dominion.thruhere.net> wrote:
> NACK! The udev maintainers have been clear that it is always /lib/udev, even on 64 bit systems, so you're not fixing a problem, you're creating an extra one.

Radu, can you do a multilib udev build and see what continues to fall
into /lib64, so we can fix it?  (and the same with systemd)

Ross

Re: [PATCH 2/2] udev: enable multilib support

[Khem Raj]

On Apr 3, 2013, at 11:02 AM, "Burton, Ross" <ross.burton@intel.com> wrote:

> On 3 April 2013 18:58, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> NACK! The udev maintainers have been clear that it is always /lib/udev, even on 64 bit systems, so you're not fixing a problem, you're creating an extra one.
> 
> Radu, can you do a multilib udev build and see what continues to fall
> into /lib64, so we can fix it?  (and the same with systemd)
> 


all my testing is always in multilib x86 and ppc env and as Koen mentioned there are paths for configs which always
remain /lib or /usr/lib even if base lib is /lib64 and we have to be careful about it.

> Ross
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/2] udev: enable multilib support

[Radu Moisan]

On 04/03/2013 09:02 PM, Burton, Ross wrote:
> On 3 April 2013 18:58, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> NACK! The udev maintainers have been clear that it is always /lib/udev, even on 64 bit systems, so you're not fixing a problem, you're creating an extra one.
> Radu, can you do a multilib udev build and see what continues to fall
> into /lib64, so we can fix it?  (and the same with systemd)

I'll take a look into this, of course.

Radu

Re: [PATCH 2/2] udev: enable multilib support

[Radu Moisan]

On 04/03/2013 08:58 PM, Koen Kooi wrote:
> Op 3 apr. 2013, om 18:25 heeft Radu Moisan <radu.moisan@intel.com> het volgende geschreven:
>
>> Use base_libdir in place of hardcoded /lib
>> Fixes [YOCTO #4096]
>>
>> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
>> ---
>> meta/recipes-core/udev/udev.inc |    1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
>> index e358d2d..6fd0240 100644
>> --- a/meta/recipes-core/udev/udev.inc
>> +++ b/meta/recipes-core/udev/udev.inc
>> @@ -76,6 +76,7 @@ FILES_udev-utils = "${bindir}/udevadm"
>>
>> do_install_append () {
>> 	install -d ${D}${sysconfdir}/init.d
>> +	sed -i 's@/lib/udev@${base_libdir}/udev@g' ${WORKDIR}/init
>> 	install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
>> 	install -m 0755 ${WORKDIR}/udev-cache ${D}${sysconfdir}/init.d/udev-cache
> NACK! The udev maintainers have been clear that it is always /lib/udev, even on 64 bit systems, so you're not fixing a problem, you're creating an extra one.

Koen, do you agree with this one?
http://patches.openembedded.org/patch/41167/

Radu

Re: [PATCH 2/2] udev: enable multilib support

[Koen Kooi]

Op 4 apr. 2013, om 14:45 heeft Radu Moisan <radu.moisan@intel.com> het volgende geschreven:

> 
> On 04/03/2013 08:58 PM, Koen Kooi wrote:
>> Op 3 apr. 2013, om 18:25 heeft Radu Moisan <radu.moisan@intel.com> het volgende geschreven:
>> 
>>> Use base_libdir in place of hardcoded /lib
>>> Fixes [YOCTO #4096]
>>> 
>>> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
>>> ---
>>> meta/recipes-core/udev/udev.inc |    1 +
>>> 1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
>>> index e358d2d..6fd0240 100644
>>> --- a/meta/recipes-core/udev/udev.inc
>>> +++ b/meta/recipes-core/udev/udev.inc
>>> @@ -76,6 +76,7 @@ FILES_udev-utils = "${bindir}/udevadm"
>>> 
>>> do_install_append () {
>>> 	install -d ${D}${sysconfdir}/init.d
>>> +	sed -i 's@/lib/udev@${base_libdir}/udev@g' ${WORKDIR}/init
>>> 	install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
>>> 	install -m 0755 ${WORKDIR}/udev-cache ${D}${sysconfdir}/init.d/udev-cache
>> NACK! The udev maintainers have been clear that it is always /lib/udev, even on 64 bit systems, so you're not fixing a problem, you're creating an extra one.
> 
> Koen, do you agree with this one?
> http://patches.openembedded.org/patch/41167/

That patch seems to match what Fedora does:

koen@rrMBP setup-scripts]$ file /lib/udev/*
/lib/udev/accelerometer:             ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x600a72599b0896506d2cff430b7126d912370056, not stripped
/lib/udev/ata_id:                    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x84bbaed9b1588de0a405bde9c7f7350f4be6839e, not stripped
/lib/udev/bluetooth_serial:          POSIX shell script, ASCII text executable
/lib/udev/cdrom_id:                  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x8bdb6f801be7f68939ece42f4661685654699a01, not stripped
/lib/udev/check-ptp-camera:          Bourne-Again shell script, ASCII text executable
/lib/udev/collect:                   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xab7db8974d08b609e4750750043d8093d4aa3b80, not stripped
/lib/udev/findkeyboards:             POSIX shell script, ASCII text executable
/lib/udev/hwdb.d:                    directory
/lib/udev/ift-load:                  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x49f9ba51194518eb078834e8ff5630253e84bfa0, stripped
/lib/udev/iphone-set-info:           ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x70bd3a730278aace048187c123d500b63d2e3adb, stripped
/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.32, BuildID[sha1]=0x52ed540687d1e2806c5c2a836b60141e2f3d8c36, stripped
/lib/udev/keyboard-force-release.sh: POSIX shell script, ASCII text executable
/lib/udev/keymap:                    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x8b2541255989492410485c979eee55d8237fa85f, not stripped
/lib/udev/keymaps:                   directory
/lib/udev/mtd_probe:                 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x4bb384bb9a2c32cd7a8c8cd3db15f0a44572d5a1, not stripped
/lib/udev/mtp-probe:                 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x5f6e4b4944c003b08788f0bfe97840da3cfcd29b, stripped
/lib/udev/pcmcia-check-broken-cis:   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x1632f66c648501cf19bb478f50ee689e5caa1590, stripped
/lib/udev/pcmcia-socket-startup:     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x48bf0e8e9461ed430c7173974795f3bd1b0d42a6, stripped
/lib/udev/rename_device:             ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x9740fdf52fb7304ddb56ecef2d3b4e157fd208dc, stripped
/lib/udev/rules.d:                   directory
/lib/udev/scsi_id:                   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x9ca187eac5c28bdcf96b56002329317099870c3b, not stripped
/lib/udev/tascam_fpga:               POSIX shell script, ASCII text executable
/lib/udev/tascam_fw:                 POSIX shell script, ASCII text executable
/lib/udev/udev-add-printer:          Python script, ASCII text executable
/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.32, BuildID[sha1]=0xb0ddd749dbefd5abced9b5b64fc5f1280199f2aa, stripped
/lib/udev/usb_modeswitch:            POSIX shell script, ASCII text executable
/lib/udev/v4l_id:                    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xa8f5533157c207a48ba3876ae61b1c73cb9733fc, not stripped

Re: [PATCH 2/2] udev: enable multilib support

[Radu Moisan]

On 04/04/2013 04:03 PM, Koen Kooi wrote:
> Op 4 apr. 2013, om 14:45 heeft Radu Moisan <radu.moisan@intel.com> het volgende geschreven:
>
>> On 04/03/2013 08:58 PM, Koen Kooi wrote:
>>> Op 3 apr. 2013, om 18:25 heeft Radu Moisan <radu.moisan@intel.com> het volgende geschreven:
>>>
>>>> Use base_libdir in place of hardcoded /lib
>>>> Fixes [YOCTO #4096]
>>>>
>>>> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
>>>> ---
>>>> meta/recipes-core/udev/udev.inc |    1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
>>>> index e358d2d..6fd0240 100644
>>>> --- a/meta/recipes-core/udev/udev.inc
>>>> +++ b/meta/recipes-core/udev/udev.inc
>>>> @@ -76,6 +76,7 @@ FILES_udev-utils = "${bindir}/udevadm"
>>>>
>>>> do_install_append () {
>>>> 	install -d ${D}${sysconfdir}/init.d
>>>> +	sed -i 's@/lib/udev@${base_libdir}/udev@g' ${WORKDIR}/init
>>>> 	install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
>>>> 	install -m 0755 ${WORKDIR}/udev-cache ${D}${sysconfdir}/init.d/udev-cache
>>> NACK! The udev maintainers have been clear that it is always /lib/udev, even on 64 bit systems, so you're not fixing a problem, you're creating an extra one.
>> Koen, do you agree with this one?
>> http://patches.openembedded.org/patch/41167/
> That patch seems to match what Fedora does:
>
> koen@rrMBP setup-scripts]$ file /lib/udev/*
> /lib/udev/accelerometer:             ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x600a72599b0896506d2cff430b7126d912370056, not stripped
> /lib/udev/ata_id:                    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x84bbaed9b1588de0a405bde9c7f7350f4be6839e, not stripped
> /lib/udev/bluetooth_serial:          POSIX shell script, ASCII text executable
> /lib/udev/cdrom_id:                  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x8bdb6f801be7f68939ece42f4661685654699a01, not stripped
> /lib/udev/check-ptp-camera:          Bourne-Again shell script, ASCII text executable
> /lib/udev/collect:                   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xab7db8974d08b609e4750750043d8093d4aa3b80, not stripped
> /lib/udev/findkeyboards:             POSIX shell script, ASCII text executable
> /lib/udev/hwdb.d:                    directory
> /lib/udev/ift-load:                  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x49f9ba51194518eb078834e8ff5630253e84bfa0, stripped
> /lib/udev/iphone-set-info:           ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x70bd3a730278aace048187c123d500b63d2e3adb, stripped
> /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.32, BuildID[sha1]=0x52ed540687d1e2806c5c2a836b60141e2f3d8c36, stripped
> /lib/udev/keyboard-force-release.sh: POSIX shell script, ASCII text executable
> /lib/udev/keymap:                    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x8b2541255989492410485c979eee55d8237fa85f, not stripped
> /lib/udev/keymaps:                   directory
> /lib/udev/mtd_probe:                 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x4bb384bb9a2c32cd7a8c8cd3db15f0a44572d5a1, not stripped
> /lib/udev/mtp-probe:                 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x5f6e4b4944c003b08788f0bfe97840da3cfcd29b, stripped
> /lib/udev/pcmcia-check-broken-cis:   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x1632f66c648501cf19bb478f50ee689e5caa1590, stripped
> /lib/udev/pcmcia-socket-startup:     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x48bf0e8e9461ed430c7173974795f3bd1b0d42a6, stripped
> /lib/udev/rename_device:             ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x9740fdf52fb7304ddb56ecef2d3b4e157fd208dc, stripped
> /lib/udev/rules.d:                   directory
> /lib/udev/scsi_id:                   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x9ca187eac5c28bdcf96b56002329317099870c3b, not stripped
> /lib/udev/tascam_fpga:               POSIX shell script, ASCII text executable
> /lib/udev/tascam_fw:                 POSIX shell script, ASCII text executable
> /lib/udev/udev-add-printer:          Python script, ASCII text executable
> /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.32, BuildID[sha1]=0xb0ddd749dbefd5abced9b5b64fc5f1280199f2aa, stripped
> /lib/udev/usb_modeswitch:            POSIX shell script, ASCII text executable
> /lib/udev/v4l_id:                    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xa8f5533157c207a48ba3876ae61b1c73cb9733fc, not stripped
>
Same thing on my ubuntu.
What I understand from this is that Koen is referring to 64bit binary 
files located in noarch_base_libdir, that is /lib. Please correct me if 
I'm wrong.
Another thing I bumped into... is there any reason why udevd ends up in 
/lib (/lib64) and not in /sbin? On my machine is located in /sbin and 
I'm assuming it is the same for most distributions.

Radu

Re: [PATCH 2/2] udev: enable multilib support

[Alex Damian]

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

On udev-184 they changed the default location from /sbin/ to /lib/udev/ and
I kept same as the upstream is.


On Fri, Apr 5, 2013 at 2:59 PM, Radu Moisan <radu.moisan@intel.com> wrote:

>
> On 04/04/2013 04:03 PM, Koen Kooi wrote:
>
>> Op 4 apr. 2013, om 14:45 heeft Radu Moisan <radu.moisan@intel.com> het
>> volgende geschreven:
>>
>>  On 04/03/2013 08:58 PM, Koen Kooi wrote:
>>>
>>>> Op 3 apr. 2013, om 18:25 heeft Radu Moisan <radu.moisan@intel.com> het
>>>> volgende geschreven:
>>>>
>>>>  Use base_libdir in place of hardcoded /lib
>>>>> Fixes [YOCTO #4096]
>>>>>
>>>>> Signed-off-by: Radu Moisan <radu.moisan@intel.com>
>>>>> ---
>>>>> meta/recipes-core/udev/udev.**inc |    1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/meta/recipes-core/udev/udev.**inc
>>>>> b/meta/recipes-core/udev/udev.**inc
>>>>> index e358d2d..6fd0240 100644
>>>>> --- a/meta/recipes-core/udev/udev.**inc
>>>>> +++ b/meta/recipes-core/udev/udev.**inc
>>>>> @@ -76,6 +76,7 @@ FILES_udev-utils = "${bindir}/udevadm"
>>>>>
>>>>> do_install_append () {
>>>>>         install -d ${D}${sysconfdir}/init.d
>>>>> +       sed -i 's@/lib/udev@${base_libdir}/**udev@g' ${WORKDIR}/init
>>>>>         install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
>>>>>         install -m 0755 ${WORKDIR}/udev-cache
>>>>> ${D}${sysconfdir}/init.d/udev-**cache
>>>>>
>>>> NACK! The udev maintainers have been clear that it is always /lib/udev,
>>>> even on 64 bit systems, so you're not fixing a problem, you're creating an
>>>> extra one.
>>>>
>>> Koen, do you agree with this one?
>>> http://patches.openembedded.**org/patch/41167/<http://patches.openembedded.org/patch/41167/>
>>>
>> That patch seems to match what Fedora does:
>>
>> koen@rrMBP setup-scripts]$ file /lib/udev/*
>> /lib/udev/accelerometer:             ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x600a72599b0896506d2cff430b71**26d912370056,
>> not stripped
>> /lib/udev/ata_id:                    ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x84bbaed9b1588de0a405bde9c7f7**350f4be6839e,
>> not stripped
>> /lib/udev/bluetooth_serial:          POSIX shell script, ASCII text
>> executable
>> /lib/udev/cdrom_id:                  ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x8bdb6f801be7f68939ece42f4661**685654699a01,
>> not stripped
>> /lib/udev/check-ptp-camera:          Bourne-Again shell script, ASCII
>> text executable
>> /lib/udev/collect:                   ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0xab7db8974d08b609e4750750043d**8093d4aa3b80,
>> not stripped
>> /lib/udev/findkeyboards:             POSIX shell script, ASCII text
>> executable
>> /lib/udev/hwdb.d:                    directory
>> /lib/udev/ift-load:                  ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x49f9ba51194518eb078834e8ff56**30253e84bfa0,
>> stripped
>> /lib/udev/iphone-set-info:           ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x70bd3a730278aace048187c123d5**00b63d2e3adb,
>> stripped
>> /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.32, BuildID[sha1]=**0x52ed540687d1e2806c5c2a836b60**141e2f3d8c36,
>> stripped
>> /lib/udev/keyboard-force-**release.sh: POSIX shell script, ASCII text
>> executable
>> /lib/udev/keymap:                    ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x8b2541255989492410485c979eee**55d8237fa85f,
>> not stripped
>> /lib/udev/keymaps:                   directory
>> /lib/udev/mtd_probe:                 ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x4bb384bb9a2c32cd7a8c8cd3db15**f0a44572d5a1,
>> not stripped
>> /lib/udev/mtp-probe:                 ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x5f6e4b4944c003b08788f0bfe978**40da3cfcd29b,
>> stripped
>> /lib/udev/pcmcia-check-broken-**cis:   ELF 64-bit LSB executable,
>> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
>> GNU/Linux 2.6.32, BuildID[sha1]=**0x1632f66c648501cf19bb478f50ee**689e5caa1590,
>> stripped
>> /lib/udev/pcmcia-socket-**startup:     ELF 64-bit LSB executable,
>> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
>> GNU/Linux 2.6.32, BuildID[sha1]=**0x48bf0e8e9461ed430c7173974795**f3bd1b0d42a6,
>> stripped
>> /lib/udev/rename_device:             ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x9740fdf52fb7304ddb56ecef2d3b**4e157fd208dc,
>> stripped
>> /lib/udev/rules.d:                   directory
>> /lib/udev/scsi_id:                   ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0x9ca187eac5c28bdcf96b56002329**317099870c3b,
>> not stripped
>> /lib/udev/tascam_fpga:               POSIX shell script, ASCII text
>> executable
>> /lib/udev/tascam_fw:                 POSIX shell script, ASCII text
>> executable
>> /lib/udev/udev-add-printer:          Python script, ASCII text executable
>> /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.32, BuildID[sha1]=**0xb0ddd749dbefd5abced9b5b64fc5**f1280199f2aa,
>> stripped
>> /lib/udev/usb_modeswitch:            POSIX shell script, ASCII text
>> executable
>> /lib/udev/v4l_id:                    ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
>> 2.6.32, BuildID[sha1]=**0xa8f5533157c207a48ba3876ae61b**1c73cb9733fc,
>> not stripped
>>
>>  Same thing on my ubuntu.
> What I understand from this is that Koen is referring to 64bit binary
> files located in noarch_base_libdir, that is /lib. Please correct me if I'm
> wrong.
> Another thing I bumped into... is there any reason why udevd ends up in
> /lib (/lib64) and not in /sbin? On my machine is located in /sbin and I'm
> assuming it is the same for most distributions.
>
> Radu
>
>
> ______________________________**_________________
> Openembedded-core mailing list
> Openembedded-core@lists.**openembedded.org<Openembedded-core@lists.openembedded.org>
> http://lists.linuxtogo.org/**cgi-bin/mailman/listinfo/**openembedded-core<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core>
>

[-- Attachment #2: Type: text/html, Size: 8499 bytes --]

Re: [PATCH 2/2] udev: enable multilib support

[Richard Purdie]

On Fri, 2013-04-05 at 16:29 +0300, Alex Damian wrote:
> On udev-184 they changed the default location from /sbin/
> to /lib/udev/ and I kept same as the upstream is.

Firstly, I know some people did ask me questions offlist about this and
I probably gave misleading answers. I thought this was a problem with
the location of the rules directory initially. We need to have one rules
directory regardless of multilibs.

Binaries however are a very different question. The multilib code we
have in OE is complex and does make some assumptions about layout, not
least as we have to interface into several package managers and also
work with all their assumptions. The situation is that:

* library files are expected to go into /libX
* binaries are expected to go into the usual bin/sbin dirs
* files in /etc, /usr/share and other similar directories are expected 
  to be identical
* We have sanity tests which check for these things

The package managers are taught to let certain packages "win" in
bin/sbin and to error if overlapping files outside this are not
identical.

It therefore follows that we would have to start adding exceptions to
this code if we have potential for both 32 bit and 64 bit /lib/udev/
binaries. We'd also have to add rules about which one would be expected
to "win" under which circumstances and so on.

To me, the simplest solution here is to point libexec dir at /sbin so
that we have /sbin/udev/ since this then works with the various multilib
rules. It means a user can install the 64 bit and 32 bit multilibs for
udev in parallel (for libudev for example) and that things should all
work correctly.

I appreciate upstream don't agree with that approach but equally they
don't have the generic multilib support we have to worry about. Hacking
the multilib code to pieces just to match upstream in this case is going
to be a lot more painful, I appreciate its the not optimal solution
though.

There is some pressure here since I would like the release to have
working multilib support as well as sysvinit and systemd :/.

Cheers,

Richard

Re: [PATCH 2/2] udev: enable multilib support

[Koen Kooi]

Op 5 apr. 2013, om 16:34 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:

> On Fri, 2013-04-05 at 16:29 +0300, Alex Damian wrote:
>> On udev-184 they changed the default location from /sbin/
>> to /lib/udev/ and I kept same as the upstream is.
> 
> Firstly, I know some people did ask me questions offlist about this and
> I probably gave misleading answers. I thought this was a problem with
> the location of the rules directory initially. We need to have one rules
> directory regardless of multilibs.
> 
> Binaries however are a very different question. The multilib code we
> have in OE is complex and does make some assumptions about layout, not
> least as we have to interface into several package managers and also
> work with all their assumptions. The situation is that:
> 
> * library files are expected to go into /libX
> * binaries are expected to go into the usual bin/sbin dirs
> * files in /etc, /usr/share and other similar directories are expected 
>  to be identical
> * We have sanity tests which check for these things
> 
> The package managers are taught to let certain packages "win" in
> bin/sbin and to error if overlapping files outside this are not
> identical.
> 
> It therefore follows that we would have to start adding exceptions to
> this code if we have potential for both 32 bit and 64 bit /lib/udev/
> binaries. We'd also have to add rules about which one would be expected
> to "win" under which circumstances and so on.
> 
> To me, the simplest solution here is to point libexec dir at /sbin so
> that we have /sbin/udev/ since this then works with the various multilib
> rules. It means a user can install the 64 bit and 32 bit multilibs for
> udev in parallel (for libudev for example) and that things should all
> work correctly.
> 
> I appreciate upstream don't agree with that approach but equally they
> don't have the generic multilib support we have to worry about. Hacking
> the multilib code to pieces just to match upstream in this case is going
> to be a lot more painful, I appreciate its the not optimal solution
> though.


FWIW, the udev *libraries* (libudev, libgudev, etc) go in $prefix/lib64 on 64 bit machines, the udev *binaries* into /lib. So multi*lib* should work.

Re: [PATCH 2/2] udev: enable multilib support

[Richard Purdie]

On Sat, 2013-04-06 at 12:32 +0200, Koen Kooi wrote:
> Op 5 apr. 2013, om 16:34 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> 
> > On Fri, 2013-04-05 at 16:29 +0300, Alex Damian wrote:
> >> On udev-184 they changed the default location from /sbin/
> >> to /lib/udev/ and I kept same as the upstream is.
> > 
> > Firstly, I know some people did ask me questions offlist about this and
> > I probably gave misleading answers. I thought this was a problem with
> > the location of the rules directory initially. We need to have one rules
> > directory regardless of multilibs.
> > 
> > Binaries however are a very different question. The multilib code we
> > have in OE is complex and does make some assumptions about layout, not
> > least as we have to interface into several package managers and also
> > work with all their assumptions. The situation is that:
> > 
> > * library files are expected to go into /libX
> > * binaries are expected to go into the usual bin/sbin dirs
> > * files in /etc, /usr/share and other similar directories are expected 
> >  to be identical
> > * We have sanity tests which check for these things
> > 
> > The package managers are taught to let certain packages "win" in
> > bin/sbin and to error if overlapping files outside this are not
> > identical.
> > 
> > It therefore follows that we would have to start adding exceptions to
> > this code if we have potential for both 32 bit and 64 bit /lib/udev/
> > binaries. We'd also have to add rules about which one would be expected
> > to "win" under which circumstances and so on.
> > 
> > To me, the simplest solution here is to point libexec dir at /sbin so
> > that we have /sbin/udev/ since this then works with the various multilib
> > rules. It means a user can install the 64 bit and 32 bit multilibs for
> > udev in parallel (for libudev for example) and that things should all
> > work correctly.
> > 
> > I appreciate upstream don't agree with that approach but equally they
> > don't have the generic multilib support we have to worry about. Hacking
> > the multilib code to pieces just to match upstream in this case is going
> > to be a lot more painful, I appreciate its the not optimal solution
> > though.
> 
> 
> FWIW, the udev *libraries* (libudev, libgudev, etc) go in
> $prefix/lib64 on 64 bit machines, the udev *binaries* into /lib. So
> multi*lib* should work.

Which is effectively what I said.

multilib package A has binary X in /lib. multilib package also B has
binary X in /lib. Package A and B cannot be installed at the same time
(package managers can't cope) and the sanity tests will fail.

Sure, we can force the libraries to be in separate packages. There is no
mechanism to force conflicts between two different multilibs easily
though and the system can still end up trying to install both packages
with conflicting binaries which it needs a resolution to.

So either we set udev to use paths which don't overlap with the lib
handling or we hack the multilib code, each of the package managers and
sanity tests.

Cheers,

Richard

Re: [PATCH 2/2] udev: enable multilib support

[Koen Kooi]

Op 7 apr. 2013, om 00:00 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:

> On Sat, 2013-04-06 at 12:32 +0200, Koen Kooi wrote:
>> Op 5 apr. 2013, om 16:34 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
>> 
>>> On Fri, 2013-04-05 at 16:29 +0300, Alex Damian wrote:
>>>> On udev-184 they changed the default location from /sbin/
>>>> to /lib/udev/ and I kept same as the upstream is.
>>> 
>>> Firstly, I know some people did ask me questions offlist about this and
>>> I probably gave misleading answers. I thought this was a problem with
>>> the location of the rules directory initially. We need to have one rules
>>> directory regardless of multilibs.
>>> 
>>> Binaries however are a very different question. The multilib code we
>>> have in OE is complex and does make some assumptions about layout, not
>>> least as we have to interface into several package managers and also
>>> work with all their assumptions. The situation is that:
>>> 
>>> * library files are expected to go into /libX
>>> * binaries are expected to go into the usual bin/sbin dirs
>>> * files in /etc, /usr/share and other similar directories are expected 
>>> to be identical
>>> * We have sanity tests which check for these things
>>> 
>>> The package managers are taught to let certain packages "win" in
>>> bin/sbin and to error if overlapping files outside this are not
>>> identical.
>>> 
>>> It therefore follows that we would have to start adding exceptions to
>>> this code if we have potential for both 32 bit and 64 bit /lib/udev/
>>> binaries. We'd also have to add rules about which one would be expected
>>> to "win" under which circumstances and so on.
>>> 
>>> To me, the simplest solution here is to point libexec dir at /sbin so
>>> that we have /sbin/udev/ since this then works with the various multilib
>>> rules. It means a user can install the 64 bit and 32 bit multilibs for
>>> udev in parallel (for libudev for example) and that things should all
>>> work correctly.
>>> 
>>> I appreciate upstream don't agree with that approach but equally they
>>> don't have the generic multilib support we have to worry about. Hacking
>>> the multilib code to pieces just to match upstream in this case is going
>>> to be a lot more painful, I appreciate its the not optimal solution
>>> though.
>> 
>> 
>> FWIW, the udev *libraries* (libudev, libgudev, etc) go in
>> $prefix/lib64 on 64 bit machines, the udev *binaries* into /lib. So
>> multi*lib* should work.
> 
> Which is effectively what I said.
> 
> multilib package A has binary X in /lib. multilib package also B has
> binary X in /lib. Package A and B cannot be installed at the same time
> (package managers can't cope) and the sanity tests will fail.
> 
> Sure, we can force the libraries to be in separate packages. 

For udev and systemd each and every library has its own subpackage already, so that isn't a problem here.

[PATCH 2/2] udev: enable multilib support

[Radu Moisan]

Use base_libdir in place of hardcoded /lib

Signed-off-by: Radu Moisan <radu.moisan@intel.com>
---
 meta/recipes-core/udev/udev.inc |    1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index e358d2d..6fd0240 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -76,6 +76,7 @@ FILES_udev-utils = "${bindir}/udevadm"
 
 do_install_append () {
 	install -d ${D}${sysconfdir}/init.d
+	sed -i 's@/lib/udev@${base_libdir}/udev@g' ${WORKDIR}/init
 	install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/udev
 	install -m 0755 ${WORKDIR}/udev-cache ${D}${sysconfdir}/init.d/udev-cache
 
-- 
1.7.9.5