libtool --with-libtool-sysroot

libtool --with-libtool-sysroot

[Jack Mitchell]

I've run into an issue where libtool isn't using the right prefix in an 
SDK built with -c populate_sdk. Looking at the configure log I can see:

configure: WARNING: unrecognized options: --with-libtool-sysroot

However, looking at the libtool recipe in OE it has a patch which 
changes the libtool flag from --with-sysroot to --with-libtool-sysroot. 
The question is, how is this version not making it into my SDK, I have 
sourced the environment script and a which libtoolize points to the 
right path.

/openembedded/sdk/latest/sysroots/x86_64-oecore-linux/usr/bin/libtoolize

Any ideas?

Re: libtool --with-libtool-sysroot

[Burton, Ross]

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

On 11 November 2016 at 14:34, Jack Mitchell <ml@embed.me.uk> wrote:

> However, looking at the libtool recipe in OE it has a patch which changes
> the libtool flag from --with-sysroot to --with-libtool-sysroot. The
> question is, how is this version not making it into my SDK, I have sourced
> the environment script and a which libtoolize points to the right path.
>

Is the package you are trying to build using its own libtool (or the host
libtool), and not our prefixed libtool?

Ross

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

Re: libtool --with-libtool-sysroot

[Jack Mitchell]

On 11/11/16 15:34, Burton, Ross wrote:
>
> On 11 November 2016 at 14:34, Jack Mitchell <ml@embed.me.uk
> <mailto:ml@embed.me.uk>> wrote:
>
>     However, looking at the libtool recipe in OE it has a patch which
>     changes the libtool flag from --with-sysroot to
>     --with-libtool-sysroot. The question is, how is this version not
>     making it into my SDK, I have sourced the environment script and a
>     which libtoolize points to the right path.
>
>
> Is the package you are trying to build using its own libtool (or the
> host libtool), and not our prefixed libtool?
>
> Ross

This may be happening but it's just a generic autotools project. No 
references to libtool in the project apart from the ones automatically 
generated.

autoreconf -i
./configure ${CONFIGURE_FLAGS}
make

How would one check which libtool was being used, or influence which one 
autotools chooses?

Cheers,

Re: libtool --with-libtool-sysroot

[Burton, Ross]

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

On 11 November 2016 at 17:31, Jack Mitchell <ml@embed.me.uk> wrote:

> How would one check which libtool was being used, or influence which one
> autotools chooses?
>

One common problem is a makefile or configure using "libtool" directly
instead of $(LIBTOOL).

Grep the generated Makefiles for "libtool", the only instance where it is
executed should be in an assignment to LIBTOOL.  For example, glib:

LIBTOOL = $(top_builddir)/x86_64-poky-linux-libtool

Ross


Ross

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

Re: libtool --with-libtool-sysroot

[Jack Mitchell]

On 11/11/16 17:33, Burton, Ross wrote:
>
> On 11 November 2016 at 17:31, Jack Mitchell <ml@embed.me.uk
> <mailto:ml@embed.me.uk>> wrote:
>
>     How would one check which libtool was being used, or influence which
>     one autotools chooses?
>
>
> One common problem is a makefile or configure using "libtool" directly
> instead of $(LIBTOOL).
>
> Grep the generated Makefiles for "libtool", the only instance where it
> is executed should be in an assignment to LIBTOOL.  For example, glib:
>
> LIBTOOL = $(top_builddir)/x86_64-poky-linux-libtool
>

I got to the bottom of this, I was switching between native and cross 
compiling but only running 'autoreconf -i' so it was detecting libtool 
was already present from previous native runs and not replacing it with 
our 'cross' version of libtool. I feel like there should be a binary 
compatibility check in there to auto overwrite if they don't match, but 
hey ho.

Always use autoreconf -if to force update of all the required autotools 
scripts in future.

Cheers,
Jack.

Re: libtool --with-libtool-sysroot

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 1193 bytes --]



On 11/16/16 2:20 AM, Jack Mitchell wrote:
> On 11/11/16 17:33, Burton, Ross wrote:
>>
>> On 11 November 2016 at 17:31, Jack Mitchell <ml@embed.me.uk
>> <mailto:ml@embed.me.uk>> wrote:
>>
>>     How would one check which libtool was being used, or influence which
>>     one autotools chooses?
>>
>>
>> One common problem is a makefile or configure using "libtool" directly
>> instead of $(LIBTOOL).
>>
>> Grep the generated Makefiles for "libtool", the only instance where it
>> is executed should be in an assignment to LIBTOOL.  For example, glib:
>>
>> LIBTOOL = $(top_builddir)/x86_64-poky-linux-libtool
>>
> 
> I got to the bottom of this, I was switching between native and cross
> compiling but only running 'autoreconf -i' so it was detecting libtool was
> already present from previous native runs and not replacing it with our
> 'cross' version of libtool. I feel like there should be a binary compatibility
> check in there to auto overwrite if they don't match, but hey ho.
> 
> Always use autoreconf -if to force update of all the required autotools
> scripts in future.

what us autotools bbclass doing in this case ?

> 
> Cheers,
> Jack.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: libtool --with-libtool-sysroot

[Burton, Ross]

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

On 16 November 2016 at 17:22, Khem Raj <raj.khem@gmail.com> wrote:

> what us autotools bbclass doing in this case ?
>

The class is passing --force, so this only happens if you're running
autoreconf manually.

Ross

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

Re: libtool --with-libtool-sysroot

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 405 bytes --]



On 11/16/16 9:26 AM, Burton, Ross wrote:
> 
> On 16 November 2016 at 17:22, Khem Raj <raj.khem@gmail.com
> <mailto:raj.khem@gmail.com>> wrote:
> 
>     what us autotools bbclass doing in this case ?
> 
> 
> The class is passing --force, so this only happens if you're running
> autoreconf manually.
> 

OK thanks so there is nothing to fix. But may be FAQ entry would be good

> Ross


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]