[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Arnout Vandecappelle]

The .la fixup handling looks for paths starting with /usr and assumes
that they are missing the installation prefix (i.e. $(STAGING_DIR)). It
already handles the cases that $(STAGING_DIR) itself and $(BASE_DIR)
are under /usr, but it does not yet handle the case that a
pre-installed external toolchain is under /usr (and tracks that fact
in some .la file). For instance, if you use buildroot to generate a
toolchain with HOST_DIR=/usr/local/some_path, this problem will occur.

Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR), but in
addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is non-empty. For
internal toolchains, it is empty and the sed expression would fail.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reported-by: Carlos Soto <csotoalonso@gmail.com>
Cc: Carlos Soto <csotoalonso@gmail.com>
---
I haven't been able to test this very extensively because it's not so
easy to find .la files where it goes wrong.

Carlos, can you check if this patch solves the problem for you?
---
 package/pkg-autotools.mk | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
index 49b42d4..9dea08a 100644
--- a/package/pkg-autotools.mk
+++ b/package/pkg-autotools.mk
@@ -304,10 +304,13 @@ endif
 # needs to be applied to any path that starts with /usr.
 #
 # To protect against the case that the output or staging directories
-# themselves are under /usr, we first substitute away any occurrences
-# of these directories as @BASE_DIR@ and @STAGING_DIR at . Note that
-# STAGING_DIR can be outside BASE_DIR when the user sets BR2_HOST_DIR
-# to a custom value.
+# or the pre-installed external toolchain themselves are under /usr,
+# we first substitute away any occurrences of these directories as
+# @BASE_DIR@, @STAGING_DIR@ and @TOOLCHAIN_EXTERNAL_INSTALL_DIR@ respectively.
+# Note that STAGING_DIR can be outside BASE_DIR when the user sets
+# BR2_HOST_DIR to a custom value. Note that TOOLCHAIN_EXTERNAL_INSTALL_DIR
+# can be under @BASE_DIR@ when it's a downloaded toolchain, and can be empty
+# when we use an internal toolchain.
 #
 ifndef $(2)_INSTALL_STAGING_CMDS
 define $(2)_INSTALL_STAGING_CMDS
@@ -315,7 +318,11 @@ define $(2)_INSTALL_STAGING_CMDS
 	find $$(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty \
 		$$(SED) "s:$$(BASE_DIR):@BASE_DIR@:g" \
 			-e "s:$$(STAGING_DIR):@STAGING_DIR@:g" \
+			$$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
+				-e "s:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
 			-e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
+			$$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
+				-e "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g") \
 			-e "s:@STAGING_DIR@:$$(STAGING_DIR):g" \
 			-e "s:@BASE_DIR@:$$(BASE_DIR):g"
 endef
-- 
2.1.4

[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Yann E. MORIN]

Arnout, All,

On 2015-05-02 23:50 +0200, Arnout Vandecappelle (Essensium/Mind) spake thusly:
> The .la fixup handling looks for paths starting with /usr and assumes
> that they are missing the installation prefix (i.e. $(STAGING_DIR)). It
> already handles the cases that $(STAGING_DIR) itself and $(BASE_DIR)
> are under /usr, but it does not yet handle the case that a
> pre-installed external toolchain is under /usr (and tracks that fact
> in some .la file). For instance, if you use buildroot to generate a
> toolchain with HOST_DIR=/usr/local/some_path, this problem will occur.
> 
> Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR), but in
> addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is non-empty. For
> internal toolchains, it is empty and the sed expression would fail.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Reported-by: Carlos Soto <csotoalonso@gmail.com>
> Cc: Carlos Soto <csotoalonso@gmail.com>

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

I however wonder: shouldn't we do that .la munging in a hook that we
forcibly add to the list of post-staging-install hooks, so that it is
run even for those packages that redefine their _INSTALL_STAGING_CMDS ?

Regards,
Yann E. MORIN.

> ---
> I haven't been able to test this very extensively because it's not so
> easy to find .la files where it goes wrong.
> 
> Carlos, can you check if this patch solves the problem for you?
> ---
>  package/pkg-autotools.mk | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
> index 49b42d4..9dea08a 100644
> --- a/package/pkg-autotools.mk
> +++ b/package/pkg-autotools.mk
> @@ -304,10 +304,13 @@ endif
>  # needs to be applied to any path that starts with /usr.
>  #
>  # To protect against the case that the output or staging directories
> -# themselves are under /usr, we first substitute away any occurrences
> -# of these directories as @BASE_DIR@ and @STAGING_DIR at . Note that
> -# STAGING_DIR can be outside BASE_DIR when the user sets BR2_HOST_DIR
> -# to a custom value.
> +# or the pre-installed external toolchain themselves are under /usr,
> +# we first substitute away any occurrences of these directories as
> +# @BASE_DIR@, @STAGING_DIR@ and @TOOLCHAIN_EXTERNAL_INSTALL_DIR@ respectively.
> +# Note that STAGING_DIR can be outside BASE_DIR when the user sets
> +# BR2_HOST_DIR to a custom value. Note that TOOLCHAIN_EXTERNAL_INSTALL_DIR
> +# can be under @BASE_DIR@ when it's a downloaded toolchain, and can be empty
> +# when we use an internal toolchain.
>  #
>  ifndef $(2)_INSTALL_STAGING_CMDS
>  define $(2)_INSTALL_STAGING_CMDS
> @@ -315,7 +318,11 @@ define $(2)_INSTALL_STAGING_CMDS
>  	find $$(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty \
>  		$$(SED) "s:$$(BASE_DIR):@BASE_DIR@:g" \
>  			-e "s:$$(STAGING_DIR):@STAGING_DIR@:g" \
> +			$$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
> +				-e "s:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
>  			-e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
> +			$$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
> +				-e "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g") \
>  			-e "s:@STAGING_DIR@:$$(STAGING_DIR):g" \
>  			-e "s:@BASE_DIR@:$$(BASE_DIR):g"
>  endef
> -- 
> 2.1.4
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Arnout Vandecappelle]

On 03/05/15 00:34, Yann E. MORIN wrote:
> Arnout, All,
> 
> On 2015-05-02 23:50 +0200, Arnout Vandecappelle (Essensium/Mind) spake thusly:
>> The .la fixup handling looks for paths starting with /usr and assumes
>> that they are missing the installation prefix (i.e. $(STAGING_DIR)). It
>> already handles the cases that $(STAGING_DIR) itself and $(BASE_DIR)
>> are under /usr, but it does not yet handle the case that a
>> pre-installed external toolchain is under /usr (and tracks that fact
>> in some .la file). For instance, if you use buildroot to generate a
>> toolchain with HOST_DIR=/usr/local/some_path, this problem will occur.
>>
>> Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR), but in
>> addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is non-empty. For
>> internal toolchains, it is empty and the sed expression would fail.
>>
>> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>> Reported-by: Carlos Soto <csotoalonso@gmail.com>
>> Cc: Carlos Soto <csotoalonso@gmail.com>
> 
> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> I however wonder: shouldn't we do that .la munging in a hook that we
> forcibly add to the list of post-staging-install hooks, so that it is
> run even for those packages that redefine their _INSTALL_STAGING_CMDS ?

 I had the same thought... Even more: it is not really tied to autotools-package
because generic packages may also use libtool, so it could go directly into the
.stamp_staging_installed code.


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Yann E. MORIN]

Arnout, All,

On 2015-05-03 11:43 +0200, Arnout Vandecappelle spake thusly:
> On 03/05/15 00:34, Yann E. MORIN wrote:
> > On 2015-05-02 23:50 +0200, Arnout Vandecappelle (Essensium/Mind) spake thusly:
> >> The .la fixup handling looks for paths starting with /usr and assumes
> >> that they are missing the installation prefix (i.e. $(STAGING_DIR)). It
> >> already handles the cases that $(STAGING_DIR) itself and $(BASE_DIR)
> >> are under /usr, but it does not yet handle the case that a
> >> pre-installed external toolchain is under /usr (and tracks that fact
> >> in some .la file). For instance, if you use buildroot to generate a
> >> toolchain with HOST_DIR=/usr/local/some_path, this problem will occur.
> >>
> >> Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR), but in
> >> addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is non-empty. For
> >> internal toolchains, it is empty and the sed expression would fail.
> >>
> >> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> >> Reported-by: Carlos Soto <csotoalonso@gmail.com>
> >> Cc: Carlos Soto <csotoalonso@gmail.com>
> > 
> > Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> > 
> > I however wonder: shouldn't we do that .la munging in a hook that we
> > forcibly add to the list of post-staging-install hooks, so that it is
> > run even for those packages that redefine their _INSTALL_STAGING_CMDS ?
> 
>  I had the same thought... Even more: it is not really tied to autotools-package
> because generic packages may also use libtool, so it could go directly into the
> .stamp_staging_installed code.

Agreed. Shall I do it, or do you already have something on your side?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Carlos Soto]

2015-05-02 23:50 GMT+02:00 Arnout Vandecappelle (Essensium/Mind) <
arnout@mind.be>:

> The .la fixup handling looks for paths starting with /usr and assumes
> that they are missing the installation prefix (i.e. $(STAGING_DIR)). It
> already handles the cases that $(STAGING_DIR) itself and $(BASE_DIR)
> are under /usr, but it does not yet handle the case that a
> pre-installed external toolchain is under /usr (and tracks that fact
> in some .la file). For instance, if you use buildroot to generate a
> toolchain with HOST_DIR=/usr/local/some_path, this problem will occur.
>
> Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR), but in
> addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is non-empty. For
> internal toolchains, it is empty and the sed expression would fail.
>
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Reported-by: Carlos Soto <csotoalonso@gmail.com>
> Cc: Carlos Soto <csotoalonso@gmail.com>
> ---
> I haven't been able to test this very extensively because it's not so
> easy to find .la files where it goes wrong.
>
> Carlos, can you check if this patch solves the problem for you?
>

Hi Arnout,
I'm afraid it does not work. I've tried patching buildroot but it gave me
errors. So I've applied manually the changes to pkg-autotools.mk and that's
what happened after a make clean && make
find
/home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib*
-name "*.la" | xargs --no-run-if-empty /bin/sed -i -e
"s:/home/starsl/iMX6/buildroot/output:@BASE_DIR@:g" -e
"s:/home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot:@STAGING_DIR@:g"
-e
"s:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g"
-e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g"  -e
"s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:g"
\
/bin/sed: can't read     : No such file or directory
make: ***
[/home/starsl/iMX6/buildroot/output/build/alsa-lib-1.0.28/.stamp_staging_installed]
Error 123





> ---
>  package/pkg-autotools.mk | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
> index 49b42d4..9dea08a 100644
> --- a/package/pkg-autotools.mk
> +++ b/package/pkg-autotools.mk
> @@ -304,10 +304,13 @@ endif
>  # needs to be applied to any path that starts with /usr.
>  #
>  # To protect against the case that the output or staging directories
> -# themselves are under /usr, we first substitute away any occurrences
> -# of these directories as @BASE_DIR@ and @STAGING_DIR at . Note that
> -# STAGING_DIR can be outside BASE_DIR when the user sets BR2_HOST_DIR
> -# to a custom value.
> +# or the pre-installed external toolchain themselves are under /usr,
> +# we first substitute away any occurrences of these directories as
> +# @BASE_DIR@, @STAGING_DIR@ and @TOOLCHAIN_EXTERNAL_INSTALL_DIR@
> respectively.
> +# Note that STAGING_DIR can be outside BASE_DIR when the user sets
> +# BR2_HOST_DIR to a custom value. Note that TOOLCHAIN_EXTERNAL_INSTALL_DIR
> +# can be under @BASE_DIR@ when it's a downloaded toolchain, and can be
> empty
> +# when we use an internal toolchain.
>  #
>  ifndef $(2)_INSTALL_STAGING_CMDS
>  define $(2)_INSTALL_STAGING_CMDS
> @@ -315,7 +318,11 @@ define $(2)_INSTALL_STAGING_CMDS
>         find $$(STAGING_DIR)/usr/lib* -name "*.la" | xargs
> --no-run-if-empty \
>                 $$(SED) "s:$$(BASE_DIR):@BASE_DIR@:g" \
>                         -e "s:$$(STAGING_DIR):@STAGING_DIR@:g" \
> +                       $$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
> +                               -e
> "s:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g")
> \
>                         -e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
> +                       $$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
> +                               -e "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g")
> \
>                         -e "s:@STAGING_DIR@:$$(STAGING_DIR):g" \
>                         -e "s:@BASE_DIR@:$$(BASE_DIR):g"
>  endef
> --
> 2.1.4
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150503/6ac25091/attachment.html>

[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Arnout Vandecappelle]

On 03/05/15 18:11, Carlos Soto wrote:
> 2015-05-02 23:50 GMT+02:00 Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be
> <mailto:arnout@mind.be>>:
> 
>     The .la fixup handling looks for paths starting with /usr and assumes
>     that they are missing the installation prefix (i.e. $(STAGING_DIR)). It
>     already handles the cases that $(STAGING_DIR) itself and $(BASE_DIR)
>     are under /usr, but it does not yet handle the case that a
>     pre-installed external toolchain is under /usr (and tracks that fact
>     in some .la file). For instance, if you use buildroot to generate a
>     toolchain with HOST_DIR=/usr/local/some_path, this problem will occur.
> 
>     Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR), but in
>     addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is non-empty. For
>     internal toolchains, it is empty and the sed expression would fail.
> 
>     Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be
>     <mailto:arnout@mind.be>>
>     Reported-by: Carlos Soto <csotoalonso at gmail.com <mailto:csotoalonso@gmail.com>>
>     Cc: Carlos Soto <csotoalonso at gmail.com <mailto:csotoalonso@gmail.com>>
>     ---
>     I haven't been able to test this very extensively because it's not so
>     easy to find .la files where it goes wrong.
> 
>     Carlos, can you check if this patch solves the problem for you?
> 
> 
> Hi Arnout,
> I'm afraid it does not work. I've tried patching buildroot but it gave me
> errors. So I've applied manually the changes to pkg-autotools.mk
> <http://pkg-autotools.mk> and that's what happened after a make clean && make
> find
> /home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib*
> -name "*.la" | xargs --no-run-if-empty /bin/sed -i -e
> "s:/home/starsl/iMX6/buildroot/output:@BASE_DIR@:g" -e
> "s:/home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot:@STAGING_DIR@:g" 
> -e
> "s:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g"
> -e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g"  -e
> "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:g"
> \       

 You did something wrong when manually applying the patch: there's a spurious \
at the end. At least, I think that that's the problem. Can you post the relevant
part of pkg-autotools.mk to be sure?

 Regards,
 Arnout

> /bin/sed: can't read     : No such file or directory
> make: ***
> [/home/starsl/iMX6/buildroot/output/build/alsa-lib-1.0.28/.stamp_staging_installed]
> Error 123
> 
> 
> 
[snip]

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Carlos Soto]

2015-05-03 18:26 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:

> On 03/05/15 18:11, Carlos Soto wrote:
> > 2015-05-02 23:50 GMT+02:00 Arnout Vandecappelle (Essensium/Mind) <
> arnout at mind.be
> > <mailto:arnout@mind.be>>:
> >
> >     The .la fixup handling looks for paths starting with /usr and assumes
> >     that they are missing the installation prefix (i.e. $(STAGING_DIR)).
> It
> >     already handles the cases that $(STAGING_DIR) itself and $(BASE_DIR)
> >     are under /usr, but it does not yet handle the case that a
> >     pre-installed external toolchain is under /usr (and tracks that fact
> >     in some .la file). For instance, if you use buildroot to generate a
> >     toolchain with HOST_DIR=/usr/local/some_path, this problem will
> occur.
> >
> >     Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR), but in
> >     addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is non-empty. For
> >     internal toolchains, it is empty and the sed expression would fail.
> >
> >     Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be
> >     <mailto:arnout@mind.be>>
> >     Reported-by: Carlos Soto <csotoalonso@gmail.com <mailto:
> csotoalonso at gmail.com>>
> >     Cc: Carlos Soto <csotoalonso at gmail.com <mailto:csotoalonso@gmail.com
> >>
> >     ---
> >     I haven't been able to test this very extensively because it's not so
> >     easy to find .la files where it goes wrong.
> >
> >     Carlos, can you check if this patch solves the problem for you?
> >
> >
> > Hi Arnout,
> > I'm afraid it does not work. I've tried patching buildroot but it gave me
> > errors. So I've applied manually the changes to pkg-autotools.mk
> > <http://pkg-autotools.mk> and that's what happened after a make clean
> && make
> > find
> >
> /home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib*
> > -name "*.la" | xargs --no-run-if-empty /bin/sed -i -e
> > "s:/home/starsl/iMX6/buildroot/output:@BASE_DIR@:g" -e
> >
> "s:/home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot:@STAGING_DIR
> @:g"
> > -e
> >
> "s:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:@TOOLCHAIN_EXTERNAL_INSTALL_DIR
> @:g"
> > -e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g"  -e
> > "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR
> @:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:g"
> > \
>
>  You did something wrong when manually applying the patch: there's a
> spurious \
> at the end. At least, I think that that's the problem. Can you post the
> relevant
> part of pkg-autotools.mk to be sure?
>
>  Regards,
>  Arnout
>
>
Sure, here it is:
# or the pre-installed external toolchain themselves are under /usr,
# we first substitute away any occurrences of these directories as
# @BASE_DIR@, @STAGING_DIR@ and @TOOLCHAIN_EXTERNAL_INSTALL_DIR@
respectively.
# Note that STAGING_DIR can be outside BASE_DIR when the user sets
# BR2_HOST_DIR to a custom value. Note that TOOLCHAIN_EXTERNAL_INSTALL_DIR
# can be under @BASE_DIR@ when it's a downloaded toolchain, and can be empty
# when we use an internal toolchain.
#
ifndef $(2)_INSTALL_STAGING_CMDS
define $(2)_INSTALL_STAGING_CMDS
    $$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)
$$($$(PKG)_INSTALL_STAGING_OPTS) -C $$($$(PKG)_SRCDIR)
    find $$(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty \
        $$(SED) "s:$$(BASE_DIR):@BASE_DIR@:g" \
            -e "s:$$(STAGING_DIR):@STAGING_DIR@:g" \
            $$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
                -e
"s:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
            -e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
            $$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
                -e
"s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g")
\
            -e "s:@STAGING_DIR@:$$(STAGING_DIR):g" \
            -e "s:@BASE_DIR@:$$(BASE_DIR):g"
endef
endif





> [snip]
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150503/ab2872d8/attachment.html>

[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Arnout Vandecappelle]

On 03/05/15 18:37, Carlos Soto wrote:
> 2015-05-03 18:26 GMT+02:00 Arnout Vandecappelle <arnout@mind.be
> <mailto:arnout@mind.be>>:
> 
>     On 03/05/15 18:11, Carlos Soto wrote:
>     > 2015-05-02 23:50 GMT+02:00 Arnout Vandecappelle (Essensium/Mind) <arnout at mind.be <mailto:arnout@mind.be>
>     > <mailto:arnout at mind.be <mailto:arnout@mind.be>>>:
>     >
>     >     The .la fixup handling looks for paths starting with /usr and assumes
>     >     that they are missing the installation prefix (i.e. $(STAGING_DIR)). It
>     >     already handles the cases that $(STAGING_DIR) itself and $(BASE_DIR)
>     >     are under /usr, but it does not yet handle the case that a
>     >     pre-installed external toolchain is under /usr (and tracks that fact
>     >     in some .la file). For instance, if you use buildroot to generate a
>     >     toolchain with HOST_DIR=/usr/local/some_path, this problem will occur.
>     >
>     >     Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR), but in
>     >     addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is non-empty. For
>     >     internal toolchains, it is empty and the sed expression would fail.
>     >
>     >     Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout at mind.be <mailto:arnout@mind.be>
>     >     <mailto:arnout at mind.be <mailto:arnout@mind.be>>>
>     >     Reported-by: Carlos Soto <csotoalonso@gmail.com
>     <mailto:csotoalonso@gmail.com> <mailto:csotoalonso@gmail.com
>     <mailto:csotoalonso@gmail.com>>>
>     >     Cc: Carlos Soto <csotoalonso at gmail.com <mailto:csotoalonso@gmail.com>
>     <mailto:csotoalonso at gmail.com <mailto:csotoalonso@gmail.com>>>
>     >     ---
>     >     I haven't been able to test this very extensively because it's not so
>     >     easy to find .la files where it goes wrong.
>     >
>     >     Carlos, can you check if this patch solves the problem for you?
>     >
>     >
>     > Hi Arnout,
>     > I'm afraid it does not work. I've tried patching buildroot but it gave me
>     > errors. So I've applied manually the changes to pkg-autotools.mk <http://pkg-autotools.mk>
>     > <http://pkg-autotools.mk> and that's what happened after a make clean && make
>     > find
>     > /home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib*
>     > -name "*.la" | xargs --no-run-if-empty /bin/sed -i -e
>     > "s:/home/starsl/iMX6/buildroot/output:@BASE_DIR@:g" -e
>     > "s:/home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot:@STAGING_DIR@:g"
>     > -e
>     > "s:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g"
>     > -e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g"  -e
>     > "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:g"
>     > \
> 
>      You did something wrong when manually applying the patch: there's a spurious \
>     at the end. At least, I think that that's the problem. Can you post the relevant
>     part of pkg-autotools.mk <http://pkg-autotools.mk> to be sure?
> 
>      Regards,
>      Arnout
> 
> 
> Sure, here it is:
> # or the pre-installed external toolchain themselves are under /usr,
> # we first substitute away any occurrences of these directories as
> # @BASE_DIR@, @STAGING_DIR@ and @TOOLCHAIN_EXTERNAL_INSTALL_DIR@ respectively.
> # Note that STAGING_DIR can be outside BASE_DIR when the user sets
> # BR2_HOST_DIR to a custom value. Note that TOOLCHAIN_EXTERNAL_INSTALL_DIR
> # can be under @BASE_DIR@ when it's a downloaded toolchain, and can be empty
> # when we use an internal toolchain.
> #
> ifndef $(2)_INSTALL_STAGING_CMDS
> define $(2)_INSTALL_STAGING_CMDS
>     $$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)
> $$($$(PKG)_INSTALL_STAGING_OPTS) -C $$($$(PKG)_SRCDIR)
>     find $$(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty \
>         $$(SED) "s:$$(BASE_DIR):@BASE_DIR@:g" \
>             -e "s:$$(STAGING_DIR):@STAGING_DIR@:g" \
>             $$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
>                 -e
> "s:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g") \
>             -e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
>             $$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
>                 -e
> "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g") \   
>        

 Can you double-check that there is no space behind the \ here?

 Regards,
 Arnout

>             -e "s:@STAGING_DIR@:$$(STAGING_DIR):g" \
>             -e "s:@BASE_DIR@:$$(BASE_DIR):g"
> endef
> endif
> 
> 
> 
>  
> 
>     [snip]
> 
>     --
>     Arnout Vandecappelle                          arnout at mind be
>     Senior Embedded Software Architect            +32-16-286500
>     Essensium/Mind                                http://www.mind.be
>     G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
>     LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>     GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
> 
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] autotools-package: also handle pre-installed external toolchain in .la fixup

[Carlos Soto]

2015-05-03 18:38 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:

> On 03/05/15 18:37, Carlos Soto wrote:
> > 2015-05-03 18:26 GMT+02:00 Arnout Vandecappelle <arnout@mind.be
> > <mailto:arnout@mind.be>>:
> >
> >     On 03/05/15 18:11, Carlos Soto wrote:
> >     > 2015-05-02 23:50 GMT+02:00 Arnout Vandecappelle (Essensium/Mind) <
> arnout at mind.be <mailto:arnout@mind.be>
> >     > <mailto:arnout at mind.be <mailto:arnout@mind.be>>>:
> >     >
> >     >     The .la fixup handling looks for paths starting with /usr and
> assumes
> >     >     that they are missing the installation prefix (i.e.
> $(STAGING_DIR)). It
> >     >     already handles the cases that $(STAGING_DIR) itself and
> $(BASE_DIR)
> >     >     are under /usr, but it does not yet handle the case that a
> >     >     pre-installed external toolchain is under /usr (and tracks
> that fact
> >     >     in some .la file). For instance, if you use buildroot to
> generate a
> >     >     toolchain with HOST_DIR=/usr/local/some_path, this problem
> will occur.
> >     >
> >     >     Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR),
> but in
> >     >     addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is
> non-empty. For
> >     >     internal toolchains, it is empty and the sed expression would
> fail.
> >     >
> >     >     Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <
> arnout at mind.be <mailto:arnout@mind.be>
> >     >     <mailto:arnout at mind.be <mailto:arnout@mind.be>>>
> >     >     Reported-by: Carlos Soto <csotoalonso@gmail.com
> >     <mailto:csotoalonso@gmail.com> <mailto:csotoalonso@gmail.com
> >     <mailto:csotoalonso@gmail.com>>>
> >     >     Cc: Carlos Soto <csotoalonso@gmail.com <mailto:
> csotoalonso at gmail.com>
> >     <mailto:csotoalonso at gmail.com <mailto:csotoalonso@gmail.com>>>
> >     >     ---
> >     >     I haven't been able to test this very extensively because it's
> not so
> >     >     easy to find .la files where it goes wrong.
> >     >
> >     >     Carlos, can you check if this patch solves the problem for you?
> >     >
> >     >
> >     > Hi Arnout,
> >     > I'm afraid it does not work. I've tried patching buildroot but it
> gave me
> >     > errors. So I've applied manually the changes to pkg-autotools.mk <
> http://pkg-autotools.mk>
> >     > <http://pkg-autotools.mk> and that's what happened after a make
> clean && make
> >     > find
> >     >
> /home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/lib*
> >     > -name "*.la" | xargs --no-run-if-empty /bin/sed -i -e
> >     > "s:/home/starsl/iMX6/buildroot/output:@BASE_DIR@:g" -e
> >     >
> "s:/home/starsl/iMX6/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot:@STAGING_DIR
> @:g"
> >     > -e
> >     >
> "s:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:@TOOLCHAIN_EXTERNAL_INSTALL_DIR
> @:g"
> >     > -e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g"  -e
> >     > "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR
> @:/usr/local/xtools/arm-cortexa9_neon-linux-gnueabihf:g"
> >     > \
> >
> >      You did something wrong when manually applying the patch: there's a
> spurious \
> >     at the end. At least, I think that that's the problem. Can you post
> the relevant
> >     part of pkg-autotools.mk <http://pkg-autotools.mk> to be sure?
> >
> >      Regards,
> >      Arnout
> >
> >
> > Sure, here it is:
> > # or the pre-installed external toolchain themselves are under /usr,
> > # we first substitute away any occurrences of these directories as
> > # @BASE_DIR@, @STAGING_DIR@ and @TOOLCHAIN_EXTERNAL_INSTALL_DIR@
> respectively.
> > # Note that STAGING_DIR can be outside BASE_DIR when the user sets
> > # BR2_HOST_DIR to a custom value. Note that
> TOOLCHAIN_EXTERNAL_INSTALL_DIR
> > # can be under @BASE_DIR@ when it's a downloaded toolchain, and can be
> empty
> > # when we use an internal toolchain.
> > #
> > ifndef $(2)_INSTALL_STAGING_CMDS
> > define $(2)_INSTALL_STAGING_CMDS
> >     $$(TARGET_MAKE_ENV) $$($$(PKG)_MAKE_ENV) $$($$(PKG)_MAKE)
> > $$($$(PKG)_INSTALL_STAGING_OPTS) -C $$($$(PKG)_SRCDIR)
> >     find $$(STAGING_DIR)/usr/lib* -name "*.la" | xargs --no-run-if-empty
> \
> >         $$(SED) "s:$$(BASE_DIR):@BASE_DIR@:g" \
> >             -e "s:$$(STAGING_DIR):@STAGING_DIR@:g" \
> >             $$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
> >                 -e
> > "s:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:g")
> \
> >             -e "s:\(['= ]\)/usr:\\1 at STAGING_DIR@/usr:g" \
> >             $$(if $$(TOOLCHAIN_EXTERNAL_INSTALL_DIR),\
> >                 -e
> > "s:@TOOLCHAIN_EXTERNAL_INSTALL_DIR@:$$(TOOLCHAIN_EXTERNAL_INSTALL_DIR):g")
> \
> >
>
>  Can you double-check that there is no space behind the \ here?
>
>  Regards,
>  Arnout
>


Yes, that was the problem. I removed the trailing spaces and now the .la
files in the staging directory all have the right path.
Sorry about that Arnaut, and thank you very much for your help.

Regards,
Carlos




>
> >             -e "s:@STAGING_DIR@:$$(STAGING_DIR):g" \
> >             -e "s:@BASE_DIR@:$$(BASE_DIR):g"
> > endef
> > endif
> >
> >
> >
> >
> >
> >     [snip]
> >
> >     --
> >     Arnout Vandecappelle                          arnout at mind be
> >     Senior Embedded Software Architect            +32-16-286500
> >     Essensium/Mind                                http://www.mind.be
> >     G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR
> Leuven
> >     LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> >     GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
> >
> >
>
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150503/bbef456c/attachment.html>