On 12/2/14, 11:10 AM, Burton, Ross wrote:
On 2 December 2014 at 17:02, Mark Hatle <[email protected]
<mailto:[email protected]>> wrote:
Personally I think using "${exec_prefix}/libexec" is incorrect. This does
not support a multilib configuration where you may have both a 64-bit and
32-bit version of the libexec program on the system. (perhaps this isn't a
real problem, but we ran into some conflicts in the past.)
Are any of these conflicts actually a problem? Can you give an example? I know
there's been several attempts to "fix" GConf multilib installation which were
generally breaking GConf instead of fixing a test case...
I simply don't remember anymore. It was an issue were a 32-bit and 64-bit
version of whatever it was, wasn't working properly. It was returning values
that were specific to the libdir.
The problem was discovered in comprehensive system testing... but for the life
of me I can't remember what the problem was. (and for all I know it's not a
problem anymore?)
So moving to the libdir, ensures that we are unique per multilib.. and the
BPN ensures that we're unique per recipe.
A libexecdir that isn't global is a problem because some packages want to run
*other recipes* binaries, and they can't just do $libexecdir/some-binary.
The other binary problem was addressed by either changing the libexec path for
the provider, or setting to libdir/${BPN} for the user.
Ross
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
