[Buildroot] [PATCH] package/libxml-parser-perl: make host build use correct compiler

[Buildroot] [PATCH] package/libxml-parser-perl: make host build use correct compiler

[Norbert Lange]

This package uses gcc filename without path, which breaks the host build
if host and target compiler have the same filename.
We pack the HOST variables as override so absolute paths are used for
the host tools.
---
 package/libxml-parser-perl/libxml-parser-perl.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/libxml-parser-perl/libxml-parser-perl.mk b/package/libxml-parser-perl/libxml-parser-perl.mk
index fcde5fc939..100c49633c 100644
--- a/package/libxml-parser-perl/libxml-parser-perl.mk
+++ b/package/libxml-parser-perl/libxml-parser-perl.mk
@@ -25,7 +25,7 @@ define HOST_LIBXML_PARSER_PERL_CONFIGURE_CMDS
 endef
 
 define HOST_LIBXML_PARSER_PERL_BUILD_CMDS
-	$(HOST_MAKE_ENV) $(MAKE) -C $(@D)
+	$(HOST_MAKE_ENV) $(MAKE) $(HOST_CONFIGURE_OPTS) -C $(@D)
 endef
 
 define HOST_LIBXML_PARSER_PERL_INSTALL_CMDS
-- 
2.26.2

[Buildroot] [PATCH] package/libxml-parser-perl: make host build use correct compiler

[Thomas Petazzoni]

On Sat,  6 Jun 2020 00:58:12 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> This package uses gcc filename without path, which breaks the host build
> if host and target compiler have the same filename.

How is it possible for the host and target compilers to have the same
file name ?

> We pack the HOST variables as override so absolute paths are used for
> the host tools.

I'm not sure what you mean by "we pack the HOST variables".

Note: I do understand that the patch will ensure that the compiler
point by $(HOSTCC) will be used, instead of whatever default the
libxml-parser-perl build system thinks it should use. But your commit
log is very confusing.

Also, your Signed-off-by is missing.

Could you resend, with a clarified explanation, and your SoB added ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] package/libxml-parser-perl: make host build use correct compiler

[Norbert Lange]

Am Sa., 6. Juni 2020 um 22:04 Uhr schrieb Thomas Petazzoni
<thomas.petazzoni@bootlin.com>:
>
> On Sat,  6 Jun 2020 00:58:12 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
>
> > This package uses gcc filename without path, which breaks the host build
> > if host and target compiler have the same filename.
>
> How is it possible for the host and target compilers to have the same
> file name ?

I use crosstool for a x86_64 target compiler, same architecture as my
desktop pc.

>
> > We pack the HOST variables as override so absolute paths are used for
> > the host tools.
>
> I'm not sure what you mean by "we pack the HOST variables".
>
> Note: I do understand that the patch will ensure that the compiler
> point by $(HOSTCC) will be used, instead of whatever default the
> libxml-parser-perl build system thinks it should use. But your commit
> log is very confusing.
>
> Also, your Signed-off-by is missing.

Was using  git send-email blindly without checking, sorry.

>
> Could you resend, with a clarified explanation, and your SoB added ?

Done.

On an not entirely unrelated note, I got troubles getting into patchwork,
did reset my PW 2-3 time, still can't log in. Is there some hidden 8
letter limit or similar?

Norbert

[Buildroot] [PATCH] package/libxml-parser-perl: make host build use correct compiler

[Thomas Petazzoni]

On Sun, 7 Jun 2020 00:29:59 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> > How is it possible for the host and target compilers to have the same
> > file name ?  
> 
> I use crosstool for a x86_64 target compiler, same architecture as my
> desktop pc.

That is still weird: the native compiler on your system is normally
called "gcc", while the compiler in your toolchain is generally named
x86_64-linux-gcc or some variation on that.

Even though your patch is definitely correct, I'd like to understand
how you fall into this situation. Indeed, I'm pretty sure several other
host packages might be affected, and if this is a valid situation, we
should see if there's a way to test it in our autobuilders.

> On an not entirely unrelated note, I got troubles getting into patchwork,
> did reset my PW 2-3 time, still can't log in. Is there some hidden 8
> letter limit or similar?

I don't think there is such a limitation. This patchwork instance is
not always super stable, yesterday we had 500 errors for a few moments
for example. If you have issues, we can contact the admins of the
instance and see if they can have a look.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com