Multilib Development Update

Multilib Development Update

[Richard Purdie]

We've been experimenting with multilib and I now feel it right to
discuss the changes a bit further now there is something to discuss :).
The work so far on this is available on the branch:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml

There have been a few issues and some lessons to learn. I've also have
to make some implementation decisions based on the issues we were
running into. To summarise them:

a) bitbake has issues if you try and delete variables from the data
store. Patches two and three on the branch fix the issues I was seeing.
More details are in the commits.

b) I found the recent additional event in bitbake wasn't in the right
place to optimally support multilib so I had to move the expandKeys()
call. Since the only known user is the native/nativesdk classes in
OE-Core, this should be ok to do at this point. Again, the commit has
the specific details.

c) When adding parameter support to BBCLASSEXTEND I added some variables
so the class can figure out which class is being processed and what the
parameter is. Related to this is the issue that bbclass event handlers
once added always get called, even if the class isn't inherited in a
subsequent recipe file!

d) I switched to using <multilib>- as the prefix for multilib recipes.
This was because using the ":" character didn't work out as it gets
placed into paths in too many places if you add it to PN.

e) I've made the assumption that if a name in PACKAGES uses PN, its at
the start.

f) The use of := in cross.bbclass makes life hard for multilib. There is
a special section of multilib.bbclass devoted to handling those
variables. Initially I approached this as two separate multilib classes
but these are merged together now.

g) I set the TARGET_VENDOR to the horrendously ugly string
"-pokymllib32". The reason is that any "-" characters in there breaks
config.sub at present and other separators cause other issues. I suspect
we can fix that going forward but for now it works albeit looking
horrible.

h) I had to introduce MLPREFIX for use in certain places, thankfully all
in places "normal" recipes shouldn't need to use it.


Summary is that you can now add:

require conf/multilib.conf
MULTILIBS = "multilib:lib32 multilib:lib64"

to your local.conf and then "bitbake zlib lib64-zlib lib32-zlib" and it
will build all three configurations. Packaging of the components I've
looked at is ok so far with the files in the correct directories and
whilst I've not tried building an image from these, I'm optimistic :).

Since various Yocto people are scheduled to work on pieces of this, I've
split the subsequent work into the following tasks for development
purposes:

1) Change libdir to "lib64" for qemux86-64 and see what breaks.

2) Extend MULTILIB class extension to recipes required to build:
     a) minimal image
     b) LSB image?
     c) Sato image?
     d) world [stretch goal for 1.1]

   This task also could include a better way of specifying which 
   recipes to extend.

3) Add support to RPM packaging backend to turn modified package names 
   into true rpm multilib packages.

4) Add support to standard opkg backend to allow parallel install of 
   multilib variant packages (likely to be hacky at first but also 
   include a proposal for better native opkg support of this)

5) Add support to bitbake to pass BBEXTEND parameters from options like 
   bitbake -b where filenames are specified on the commandline

6) Create some "standard" multilib configurations (x86 32+64 bit)

7) Overhaul architecture, ABI, optimisation configuration files with a 
   view to better structure (and ease specifying multilib 
   configurations).

8) Reconsolidate multilib + multilibcross class differences [already 
   done by RP now]

9) Directly support multlibs within the toolchain itself [post 1.1]

10) Investigate better TARGET_VENDOR handling for config.sub. Currently 
   we can only have ARCH-VENDOR-linux where VENDOR cannot contain "-" 
   but it might be possible to relax that constraint.

I'm quite pleased with the way this code "feels" now and it isn't
working out too invasive into the rest of the system. I therefore think
we have a solid base to start building the above tasks upon.

There are other cleanup issues it does highlight such as the convoluted
mess of MULIMACH_ARCH variables, BASE_PACKAGE_ARCH, PACKAGE_ARCH and so
forth but I'll save that for a separate discussion.

Cheers,

Richard

Re: Multilib Development Update

[Koen Kooi]

Op 21 jun 2011, om 14:14 heeft Richard Purdie het volgende geschreven:

> We've been experimenting with multilib and I now feel it right to
> discuss the changes a bit further now there is something to discuss :).
> The work so far on this is available on the branch:
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
> 
> There have been a few issues and some lessons to learn. I've also have
> to make some implementation decisions based on the issues we were
> running into. To summarise them:

[..]

> g) I set the TARGET_VENDOR to the horrendously ugly string
> "-pokymllib32". The reason is that any "-" characters in there breaks
> config.sub at present and other separators cause other issues. I suspect
> we can fix that going forward but for now it works albeit looking
> horrible.

Angstrom has had some problems with that as well and I think DISTROs shouldn't poke TARGET_VENDOR directly, but do something like:

bitbake.conf:

# No hyphens!
DISTROVENDOR ??= "oecore"
TARGET_VENDOR = "-${DISTROVENDOR}"

DISTRO.conf:

# No hyphens!
DISTROVENDOR = "foo"

regards,

Koen

Re: Multilib Development Update

[Frans Meulenbroeks]

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

As I already asked before: what is the benefit having this in embedded
systems?

If I am doing an embedded system I know the target hardware, and there is no
need to have e.g. both 32 and 64 bit libs.

Frans.

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

Re: Multilib Development Update

[Richard Purdie]

On Tue, 2011-06-21 at 15:02 +0200, Frans Meulenbroeks wrote:
> As I already asked before: what is the benefit having this in embedded
> systems?
> 
> If I am doing an embedded system I know the target hardware, and there
> is no need to have e.g. both 32 and 64 bit libs.

This has been mentioned before but there are embedded use cases where
the requirement is to have a low overhead OS using 32 bit libs and
binaries to save memory but the main application (like a database
server) runs in 64 bit mode with 64 bit libraries so it can take
advantage of system memory, extra instructions or so forth. This applies
to mips and powerpc as well as x86.

The implementation is fairly self contained so if you don't want
multilib, you shouldn't even be aware its there...

Cheers,

Richard

Re: Multilib Development Update

[Richard Purdie]

On Tue, 2011-06-21 at 14:28 +0200, Koen Kooi wrote:
> Op 21 jun 2011, om 14:14 heeft Richard Purdie het volgende geschreven:
> 
> > We've been experimenting with multilib and I now feel it right to
> > discuss the changes a bit further now there is something to discuss :).
> > The work so far on this is available on the branch:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
> > 
> > There have been a few issues and some lessons to learn. I've also have
> > to make some implementation decisions based on the issues we were
> > running into. To summarise them:
> 
> [..]
> 
> > g) I set the TARGET_VENDOR to the horrendously ugly string
> > "-pokymllib32". The reason is that any "-" characters in there breaks
> > config.sub at present and other separators cause other issues. I suspect
> > we can fix that going forward but for now it works albeit looking
> > horrible.
> 
> Angstrom has had some problems with that as well and I think DISTROs
> shouldn't poke TARGET_VENDOR directly, but do something like:
> 
> bitbake.conf:
> 
> # No hyphens!
> DISTROVENDOR ??= "oecore"
> TARGET_VENDOR = "-${DISTROVENDOR}"
> 
> DISTRO.conf:
> 
> # No hyphens!
> DISTROVENDOR = "foo"

Agreed, I think we're going to need to do something like this.

Cheers,

Richard

Re: Multilib Development Update

[Eric Bénard]

Hi,

On 21/06/2011 15:30, Richard Purdie wrote:
> On Tue, 2011-06-21 at 15:02 +0200, Frans Meulenbroeks wrote:
>> As I already asked before: what is the benefit having this in embedded
>> systems?
>>
>> If I am doing an embedded system I know the target hardware, and there
>> is no need to have e.g. both 32 and 64 bit libs.
>
> This has been mentioned before but there are embedded use cases where
> the requirement is to have a low overhead OS using 32 bit libs and
> binaries to save memory but the main application (like a database
> server) runs in 64 bit mode with 64 bit libraries so it can take
> advantage of system memory, extra instructions or so forth. This applies
> to mips and powerpc as well as x86.
>
> The implementation is fairly self contained so if you don't want
> multilib, you shouldn't even be aware its there...
>
will that feature allow to build a sdk running on both x86 and amd64 hosts 
whatever is the build host ?

Eric

Re: Multilib Development Update

[Khem Raj]

On 06/21/2011 05:14 AM, Richard Purdie wrote:
> We've been experimenting with multilib and I now feel it right to
> discuss the changes a bit further now there is something to discuss :).
> The work so far on this is available on the branch:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
>
> There have been a few issues and some lessons to learn. I've also have
> to make some implementation decisions based on the issues we were
> running into. To summarise them:
>
> a) bitbake has issues if you try and delete variables from the data
> store. Patches two and three on the branch fix the issues I was seeing.
> More details are in the commits.
>
> b) I found the recent additional event in bitbake wasn't in the right
> place to optimally support multilib so I had to move the expandKeys()
> call. Since the only known user is the native/nativesdk classes in
> OE-Core, this should be ok to do at this point. Again, the commit has
> the specific details.
>
> c) When adding parameter support to BBCLASSEXTEND I added some variables
> so the class can figure out which class is being processed and what the
> parameter is. Related to this is the issue that bbclass event handlers
> once added always get called, even if the class isn't inherited in a
> subsequent recipe file!
>
> d) I switched to using<multilib>- as the prefix for multilib recipes.
> This was because using the ":" character didn't work out as it gets
> placed into paths in too many places if you add it to PN.
>
> e) I've made the assumption that if a name in PACKAGES uses PN, its at
> the start.
>
> f) The use of := in cross.bbclass makes life hard for multilib. There is
> a special section of multilib.bbclass devoted to handling those
> variables. Initially I approached this as two separate multilib classes
> but these are merged together now.
>
> g) I set the TARGET_VENDOR to the horrendously ugly string
> "-pokymllib32". The reason is that any "-" characters in there breaks
> config.sub at present and other separators cause other issues. I suspect
> we can fix that going forward but for now it works albeit looking
> horrible.


generally _ works well with triplets but I guess we have overrides so 
thats ruled out.

>
> h) I had to introduce MLPREFIX for use in certain places, thankfully all
> in places "normal" recipes shouldn't need to use it.
>
>
> Summary is that you can now add:
>
> require conf/multilib.conf
> MULTILIBS = "multilib:lib32 multilib:lib64"

I think MULTILIB = "lib32 lib64" would be nicer

>
> to your local.conf and then "bitbake zlib lib64-zlib lib32-zlib" and it
> will build all three configurations.

will it also build binaries for both libs as well ? or just libraries


Packaging of the components I've
> looked at is ok so far with the files in the correct directories and
> whilst I've not tried building an image from these, I'm optimistic :).
>
> Since various Yocto people are scheduled to work on pieces of this, I've
> split the subsequent work into the following tasks for development
> purposes:
>
> 1) Change libdir to "lib64" for qemux86-64 and see what breaks.
>
> 2) Extend MULTILIB class extension to recipes required to build:
>       a) minimal image
>       b) LSB image?
>       c) Sato image?
>       d) world [stretch goal for 1.1]
>
>     This task also could include a better way of specifying which
>     recipes to extend.
>
> 3) Add support to RPM packaging backend to turn modified package names
>     into true rpm multilib packages.
>
> 4) Add support to standard opkg backend to allow parallel install of
>     multilib variant packages (likely to be hacky at first but also
>     include a proposal for better native opkg support of this)
>
> 5) Add support to bitbake to pass BBEXTEND parameters from options like
>     bitbake -b where filenames are specified on the commandline
>
> 6) Create some "standard" multilib configurations (x86 32+64 bit)
>
> 7) Overhaul architecture, ABI, optimisation configuration files with a
>     view to better structure (and ease specifying multilib
>     configurations).
>
> 8) Reconsolidate multilib + multilibcross class differences [already
>     done by RP now]
>
> 9) Directly support multlibs within the toolchain itself [post 1.1]
>
> 10) Investigate better TARGET_VENDOR handling for config.sub. Currently
>     we can only have ARCH-VENDOR-linux where VENDOR cannot contain "-"
>     but it might be possible to relax that constraint.
>
> I'm quite pleased with the way this code "feels" now and it isn't
> working out too invasive into the rest of the system. I therefore think
> we have a solid base to start building the above tasks upon.
>
> There are other cleanup issues it does highlight such as the convoluted
> mess of MULIMACH_ARCH variables, BASE_PACKAGE_ARCH, PACKAGE_ARCH and so
> forth but I'll save that for a separate discussion.
>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Multilib Development Update

[Mark Hatle]

On 6/21/11 8:02 AM, Frans Meulenbroeks wrote:
> As I already asked before: what is the benefit having this in embedded systems?
> 
> If I am doing an embedded system I know the target hardware, and there is no
> need to have e.g. both 32 and 64 bit libs.

64-bit database on a 32-bit system.

64-bit "userspace" device drivers on a 32-bit system.

Being able to run a binary application for compatibility.  This is fairly common
in some embedded areas where they need something like mips o32, but the rest of
the system is running n32 for performance.

etc...

This is something that most embedded systems won't use, but there are a large
class of devices, primarily Carrier Grade devices, that do require mixed-mode
systems.

--Mark

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

Re: Multilib Development Update

[Mark Hatle]

On 6/21/11 9:32 AM, Khem Raj wrote:
> On 06/21/2011 05:14 AM, Richard Purdie wrote:
>> We've been experimenting with multilib and I now feel it right to
>> discuss the changes a bit further now there is something to discuss :).
>> The work so far on this is available on the branch:
>>
>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/ml
>>
>> There have been a few issues and some lessons to learn. I've also have
>> to make some implementation decisions based on the issues we were
>> running into. To summarise them:
>>
>> a) bitbake has issues if you try and delete variables from the data
>> store. Patches two and three on the branch fix the issues I was seeing.
>> More details are in the commits.
>>
>> b) I found the recent additional event in bitbake wasn't in the right
>> place to optimally support multilib so I had to move the expandKeys()
>> call. Since the only known user is the native/nativesdk classes in
>> OE-Core, this should be ok to do at this point. Again, the commit has
>> the specific details.
>>
>> c) When adding parameter support to BBCLASSEXTEND I added some variables
>> so the class can figure out which class is being processed and what the
>> parameter is. Related to this is the issue that bbclass event handlers
>> once added always get called, even if the class isn't inherited in a
>> subsequent recipe file!
>>
>> d) I switched to using<multilib>- as the prefix for multilib recipes.
>> This was because using the ":" character didn't work out as it gets
>> placed into paths in too many places if you add it to PN.
>>
>> e) I've made the assumption that if a name in PACKAGES uses PN, its at
>> the start.
>>
>> f) The use of := in cross.bbclass makes life hard for multilib. There is
>> a special section of multilib.bbclass devoted to handling those
>> variables. Initially I approached this as two separate multilib classes
>> but these are merged together now.
>>
>> g) I set the TARGET_VENDOR to the horrendously ugly string
>> "-pokymllib32". The reason is that any "-" characters in there breaks
>> config.sub at present and other separators cause other issues. I suspect
>> we can fix that going forward but for now it works albeit looking
>> horrible.
> 
> 
> generally _ works well with triplets but I guess we have overrides so 
> thats ruled out.
> 
>>
>> h) I had to introduce MLPREFIX for use in certain places, thankfully all
>> in places "normal" recipes shouldn't need to use it.
>>
>>
>> Summary is that you can now add:
>>
>> require conf/multilib.conf
>> MULTILIBS = "multilib:lib32 multilib:lib64"
> 
> I think MULTILIB = "lib32 lib64" would be nicer
> 
>>
>> to your local.conf and then "bitbake zlib lib64-zlib lib32-zlib" and it
>> will build all three configurations.
> 
> will it also build binaries for both libs as well ? or just libraries

Goal is to build the whole recipe for whatever multilibs are defined.

The packaging system(s) can then choose to install whatever is required for the
runtime dependencies.  (RPM can do some additional conflict avoidance, but this
has to work for opkg and deb packages as well.)

--Mark

> 
> Packaging of the components I've
>> looked at is ok so far with the files in the correct directories and
>> whilst I've not tried building an image from these, I'm optimistic :).
>>
>> Since various Yocto people are scheduled to work on pieces of this, I've
>> split the subsequent work into the following tasks for development
>> purposes:
>>
>> 1) Change libdir to "lib64" for qemux86-64 and see what breaks.
>>
>> 2) Extend MULTILIB class extension to recipes required to build:
>>       a) minimal image
>>       b) LSB image?
>>       c) Sato image?
>>       d) world [stretch goal for 1.1]
>>
>>     This task also could include a better way of specifying which
>>     recipes to extend.
>>
>> 3) Add support to RPM packaging backend to turn modified package names
>>     into true rpm multilib packages.
>>
>> 4) Add support to standard opkg backend to allow parallel install of
>>     multilib variant packages (likely to be hacky at first but also
>>     include a proposal for better native opkg support of this)
>>
>> 5) Add support to bitbake to pass BBEXTEND parameters from options like
>>     bitbake -b where filenames are specified on the commandline
>>
>> 6) Create some "standard" multilib configurations (x86 32+64 bit)
>>
>> 7) Overhaul architecture, ABI, optimisation configuration files with a
>>     view to better structure (and ease specifying multilib
>>     configurations).
>>
>> 8) Reconsolidate multilib + multilibcross class differences [already
>>     done by RP now]
>>
>> 9) Directly support multlibs within the toolchain itself [post 1.1]
>>
>> 10) Investigate better TARGET_VENDOR handling for config.sub. Currently
>>     we can only have ARCH-VENDOR-linux where VENDOR cannot contain "-"
>>     but it might be possible to relax that constraint.
>>
>> I'm quite pleased with the way this code "feels" now and it isn't
>> working out too invasive into the rest of the system. I therefore think
>> we have a solid base to start building the above tasks upon.
>>
>> There are other cleanup issues it does highlight such as the convoluted
>> mess of MULIMACH_ARCH variables, BASE_PACKAGE_ARCH, PACKAGE_ARCH and so
>> forth but I'll save that for a separate discussion.
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Multilib Development Update

[Khem Raj]

On 06/21/2011 06:33 AM, Eric Bénard wrote:
> Hi,
>
> On 21/06/2011 15:30, Richard Purdie wrote:
>> On Tue, 2011-06-21 at 15:02 +0200, Frans Meulenbroeks wrote:
>>> As I already asked before: what is the benefit having this in embedded
>>> systems?
>>>
>>> If I am doing an embedded system I know the target hardware, and there
>>> is no need to have e.g. both 32 and 64 bit libs.
>>
>> This has been mentioned before but there are embedded use cases where
>> the requirement is to have a low overhead OS using 32 bit libs and
>> binaries to save memory but the main application (like a database
>> server) runs in 64 bit mode with 64 bit libraries so it can take
>> advantage of system memory, extra instructions or so forth. This applies
>> to mips and powerpc as well as x86.
>>
>> The implementation is fairly self contained so if you don't want
>> multilib, you shouldn't even be aware its there...
>>
> will that feature allow to build a sdk running on both x86 and amd64
> hosts whatever is the build host ?
>

thats a different aspect.
Although we could make a SDK which could cook up packages which run
on multilibs


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

Re: Multilib Development Update

[Richard Purdie]

On Tue, 2011-06-21 at 15:33 +0200, Eric Bénard wrote:
> Hi,
> 
> On 21/06/2011 15:30, Richard Purdie wrote:
> > On Tue, 2011-06-21 at 15:02 +0200, Frans Meulenbroeks wrote:
> >> As I already asked before: what is the benefit having this in embedded
> >> systems?
> >>
> >> If I am doing an embedded system I know the target hardware, and there
> >> is no need to have e.g. both 32 and 64 bit libs.
> >
> > This has been mentioned before but there are embedded use cases where
> > the requirement is to have a low overhead OS using 32 bit libs and
> > binaries to save memory but the main application (like a database
> > server) runs in 64 bit mode with 64 bit libraries so it can take
> > advantage of system memory, extra instructions or so forth. This applies
> > to mips and powerpc as well as x86.
> >
> > The implementation is fairly self contained so if you don't want
> > multilib, you shouldn't even be aware its there...
> >
> will that feature allow to build a sdk running on both x86 and amd64 hosts 
> whatever is the build host ?

With OE-Core, you could already do this by setting SDKMACHINE and
building one, then setting SDKMACHINE to the other and building it
again.

Looking at the code, I am strongly tempted to replace nativesdk and
crosssdk with the multilib code though as I think it can reuse the same
functionality. That is a step beyond where we're currently at though :)

Cheers,

Richard

[Multilib] a problem of SHLIBSDIR

[Lu, Lianhao]

Hi,

SHLIBSDIR is a central place where to store the pkg information about the shared libraries which the package would provide. In the do_package task,  the function package_do_shlibs() will use this kind of information to automatically add RDEPENDS for the package being built. In the multilib situation, the SHLIBSDIR should be set to a different place form the normal version, otherwise a 32bit application might RDEPENDS on lib64-eglibc instead of the 32bit eglibc. 

The following patch tries to solve this problem. Any comment?
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=llu/ml&id=1970842424c414db50058ff99c6627e3ca034a04 

----------------------------------------------------------------------------------
classes/multilib.bbclass: Change the SHLIBSDIR.
Changes the SHLIBSDIR for the multilib version, so it won't mix up with the normal version.

Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>

Diffstat (more/less context) (ignore whitespace changes)
-rw-r--r--	meta/classes/multilib.bbclass	1+	
1 files changed, 1 insertions, 0 deletions

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 36c52ef..17edc37 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -30,6 +30,7 @@ python multilib_virtclass_handler () {
             e.data.setVar("BASE_PACKAGE_ARCH", "${TARGET_ARCH}")
 
     bb.data.setVar("PN", variant + "-" + bb.data.getVar("PN", e.data, False), e.data)
+    bb.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant ,bb.data.getVar("SHLIBSDIR",e.data,False) + "/" + variant, e.data)
     bb.data.setVar("OVERRIDES", bb.data.getVar("OVERRIDES", e.data, False) + override, e.data)
 }

Best Regards,
-Lianhao Lu

Re: [Multilib] a problem of SHLIBSDIR

[Richard Purdie]

On Wed, 2011-06-29 at 17:10 +0800, Lu, Lianhao wrote:
> Hi,
> 
> SHLIBSDIR is a central place where to store the pkg information about
> the shared libraries which the package would provide. In the
> do_package task,  the function package_do_shlibs() will use this kind
> of information to automatically add RDEPENDS for the package being
> built. In the multilib situation, the SHLIBSDIR should be set to a
> different place form the normal version, otherwise a 32bit application
> might RDEPENDS on lib64-eglibc instead of the 32bit eglibc. 
> 
> The following patch tries to solve this problem. Any comment?
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=llu/ml&id=1970842424c414db50058ff99c6627e3ca034a04 

I think I'd been assuming that SHLIBSDIR included the TARGET_VENDOR
string as part of the triplet but it obviously doesn't and we need this.

Good catch. I think the patch is a good one to add!

Cheers,

Richard