Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH] package/libxslt: fix static build
@ 2016-03-28 21:09 Jörg Krause
  2016-03-29  1:01 ` Thomas Petazzoni
  0 siblings, 1 reply; 8+ messages in thread
From: Jörg Krause @ 2016-03-28 21:09 UTC (permalink / raw)
  To: buildroot

Set --with-libxml-libs-prefix so libtool finds the correct dependencies for
libxml2.

Fixes:
http://autobuild.buildroot.net/results/3f8/3f8d876ed6cfe6e73a75fa8904ebdd3f6f0fe53c/

Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
---
 package/libxslt/libxslt.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/libxslt/libxslt.mk b/package/libxslt/libxslt.mk
index 2e5cc14..0cc4bb9 100644
--- a/package/libxslt/libxslt.mk
+++ b/package/libxslt/libxslt.mk
@@ -14,7 +14,8 @@ LIBXSLT_CONF_OPTS = \
 	--with-gnu-ld \
 	--without-debug \
 	--without-python \
-	--with-libxml-prefix=$(STAGING_DIR)/usr/
+	--with-libxml-prefix=$(STAGING_DIR)/usr/ \
+	--with-libxml-libs-prefix=$(STAGING_DIR)/usr/lib
 LIBXSLT_CONFIG_SCRIPTS = xslt-config
 LIBXSLT_DEPENDENCIES = libxml2
 
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [Buildroot] [PATCH] package/libxslt: fix static build
  2016-03-28 21:09 [Buildroot] [PATCH] package/libxslt: fix static build Jörg Krause
@ 2016-03-29  1:01 ` Thomas Petazzoni
  2016-03-29 12:52   ` Thomas Petazzoni
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Petazzoni @ 2016-03-29  1:01 UTC (permalink / raw)
  To: buildroot

Hello,

On Mon, 28 Mar 2016 23:09:23 +0200, J?rg Krause wrote:
> Set --with-libxml-libs-prefix so libtool finds the correct dependencies for
> libxml2.
> 
> Fixes:
> http://autobuild.buildroot.net/results/3f8/3f8d876ed6cfe6e73a75fa8904ebdd3f6f0fe53c/
> 
> Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> ---
>  package/libxslt/libxslt.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/package/libxslt/libxslt.mk b/package/libxslt/libxslt.mk
> index 2e5cc14..0cc4bb9 100644
> --- a/package/libxslt/libxslt.mk
> +++ b/package/libxslt/libxslt.mk
> @@ -14,7 +14,8 @@ LIBXSLT_CONF_OPTS = \
>  	--with-gnu-ld \
>  	--without-debug \
>  	--without-python \
> -	--with-libxml-prefix=$(STAGING_DIR)/usr/
> +	--with-libxml-prefix=$(STAGING_DIR)/usr/ \
> +	--with-libxml-libs-prefix=$(STAGING_DIR)/usr/lib

I've applied because it indeed works, but to be honest, I don't
understand why: I don't quite understand how this can fix the build.
All what this option does is:

AC_ARG_WITH(libxml-libs-prefix,
        [  --with-libxml-libs-prefix=[PFX]      Specify location of libxml libs],
        LIBXML_LIBS="-L$withval"
)

I.e, it will add -L$(STAGING_DIR)/usr/lib to the gcc options. But that
is completely useless because $(STAGING_DIR)/usr/lib is already the
default search path for libraries. So why does it fix the build? I
don't know.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Buildroot] [PATCH] package/libxslt: fix static build
  2016-03-29  1:01 ` Thomas Petazzoni
@ 2016-03-29 12:52   ` Thomas Petazzoni
  2016-03-29 13:52     ` Jörg Krause
  2016-03-29 17:44     ` Baruch Siach
  0 siblings, 2 replies; 8+ messages in thread
From: Thomas Petazzoni @ 2016-03-29 12:52 UTC (permalink / raw)
  To: buildroot

Hello,

On Tue, 29 Mar 2016 03:01:13 +0200, Thomas Petazzoni wrote:

> I've applied because it indeed works, but to be honest, I don't
> understand why: I don't quite understand how this can fix the build.
> All what this option does is:
> 
> AC_ARG_WITH(libxml-libs-prefix,
>         [  --with-libxml-libs-prefix=[PFX]      Specify location of libxml libs],
>         LIBXML_LIBS="-L$withval"
> )
> 
> I.e, it will add -L$(STAGING_DIR)/usr/lib to the gcc options. But that
> is completely useless because $(STAGING_DIR)/usr/lib is already the
> default search path for libraries. So why does it fix the build? I
> don't know.

Baruch has posted another patch that I believe is supposed to fix the
same problem: http://patchwork.ozlabs.org/patch/602529/.

Baruch, J?rg, could you have a closer look at this problem, and see
which solution, between the one from J?rg and the one from Baruch is
actually correct ?

I must say I remain surprised that the version proposed by J?rg
actually works, but it does. The version posted by Baruch seems more
correct to me.

However, one drawback of the solution proposed by Baruch is that even
when doing dynamic linking, the application linking against libxml2 will
be directly linking against liblzma, which is not necessary. But that's
already what happens for libz, libpthread, and the other libraries
listed in XML_LIBS, so from that point of view, Baruch solution is in
line with what libxml2 is already doing.

Ideally, xml2-config should have a --static option, or even better,
drop xml2-config entirely and use pkg-config :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Buildroot] [PATCH] package/libxslt: fix static build
  2016-03-29 12:52   ` Thomas Petazzoni
@ 2016-03-29 13:52     ` Jörg Krause
  2016-03-29 14:09       ` Thomas Petazzoni
  2016-03-29 17:44     ` Baruch Siach
  1 sibling, 1 reply; 8+ messages in thread
From: Jörg Krause @ 2016-03-29 13:52 UTC (permalink / raw)
  To: buildroot

On Di, 2016-03-29 at 14:52 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 29 Mar 2016 03:01:13 +0200, Thomas Petazzoni wrote:
> 
> > 
> > I've applied because it indeed works, but to be honest, I don't
> > understand why: I don't quite understand how this can fix the
> > build.
> > All what this option does is:
> > 
> > AC_ARG_WITH(libxml-libs-prefix,
> > ????????[??--with-libxml-libs-prefix=[PFX]??????Specify location of
> > libxml libs],
> > ????????LIBXML_LIBS="-L$withval"
> > )
> > 
> > I.e, it will add -L$(STAGING_DIR)/usr/lib to the gcc options. But
> > that
> > is completely useless because $(STAGING_DIR)/usr/lib is already the
> > default search path for libraries. So why does it fix the build? I
> > don't know.
> Baruch has posted another patch that I believe is supposed to fix the
> same problem: http://patchwork.ozlabs.org/patch/602529/.

Sorry, I was not aware of this patch.

> Baruch, J?rg, could you have a closer look at this problem, and see
> which solution, between the one from J?rg and the one from Baruch is
> actually correct ?

The problem is that xml2-config does not work for cross-compilation:

$ ./output/host/usr/bfin-buildroot-uclinux-clibc/sysroot/usr//bin/xml2-
config --libs
-lxml2 -lm

> I must say I remain surprised that the version proposed by J?rg
> actually works, but it does. The version posted by Baruch seems more
> correct to me.

I am not quite sure why it works either. I guess it has something todo
with how libtool works, as libtool sets the correct dependency_libs in
libxslt.la if '--with-libxml-libs-prefix' is used:

# Libraries that this one depends upon.
dependency_libs=' -L/home/joerg/git/buildroot/output/host/usr/bfin-
buildroot-uclinux-uclibc/sysroot/usr/lib
/home/joerg/git/buildroot/output/host/usr/bfin-buildroot-uclinux-
uclibc/sysroot/usr/lib/libxml2.la
/home/joerg/git/buildroot/output/host/usr/bfin-buildroot-uclinux-
uclibc/sysroot/usr/lib/liblzma.la -lm'

.. whereas, whithout '--with-libxml-libs-prefix:

# Libraries that this one depends upon.
dependency_libs=' -lxml2 -lm'

> However, one drawback of the solution proposed by Baruch is that even
> when doing dynamic linking, the application linking against libxml2
> will
> be directly linking against liblzma, which is not necessary. But
> that's
> already what happens for libz, libpthread, and the other libraries
> listed in XML_LIBS, so from that point of view, Baruch solution is in
> line with what libxml2 is already doing.
> 
> Ideally, xml2-config should have a --static option, or even better,
> drop xml2-config entirely and use pkg-config :-)
> 

Patching libxlst to use pkg-config is what OE and yocto are doing [1]
as libxml2 does have a correct .pc file.

[1]?http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-suppor
t/libxslt/libxslt

Best regards
J?rg Krause

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Buildroot] [PATCH] package/libxslt: fix static build
  2016-03-29 13:52     ` Jörg Krause
@ 2016-03-29 14:09       ` Thomas Petazzoni
  0 siblings, 0 replies; 8+ messages in thread
From: Thomas Petazzoni @ 2016-03-29 14:09 UTC (permalink / raw)
  To: buildroot

Hello,

On Tue, 29 Mar 2016 15:52:23 +0200, J?rg Krause wrote:
> > Baruch, J?rg, could you have a closer look at this problem, and see
> > which solution, between the one from J?rg and the one from Baruch is
> > actually correct ?
> 
> The problem is that xml2-config does not work for cross-compilation:
> 
> $ ./output/host/usr/bfin-buildroot-uclinux-clibc/sysroot/usr//bin/xml2-
> config --libs
> -lxml2 -lm

Why do you say it doesn't work for cross-compilation? This result is
perfectly good for cross-compilation.

> I am not quite sure why it works either. I guess it has something todo
> with how libtool works, as libtool sets the correct dependency_libs in
> libxslt.la if '--with-libxml-libs-prefix' is used:
> 
> # Libraries that this one depends upon.
> dependency_libs=' -L/home/joerg/git/buildroot/output/host/usr/bfin-
> buildroot-uclinux-uclibc/sysroot/usr/lib
> /home/joerg/git/buildroot/output/host/usr/bfin-buildroot-uclinux-
> uclibc/sysroot/usr/lib/libxml2.la
> /home/joerg/git/buildroot/output/host/usr/bfin-buildroot-uclinux-
> uclibc/sysroot/usr/lib/liblzma.la -lm'
> 
> .. whereas, whithout '--with-libxml-libs-prefix:
> 
> # Libraries that this one depends upon.
> dependency_libs=' -lxml2 -lm'

Weird. I guess libtool is parsing this -L<path> option and does some
magic with it. It is completely stupid, because since we have --sysroot
$(STAGING_DIR), then automatically $(STAGING_DIR)/usr/lib is in the
search path for libraries, without the need to add a -L<path> option.
Except for the silly libtool.

> > Ideally, xml2-config should have a --static option, or even better,
> > drop xml2-config entirely and use pkg-config :-)
> 
> Patching libxlst to use pkg-config is what OE and yocto are doing [1]
> as libxml2 does have a correct .pc file.

And why isn't that upstream? The development of libxslt seems to be
active upstream: https://git.gnome.org/browse/libxslt/log/. Well,
except for the fact that they haven't done a release in the last three
years.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Buildroot] [PATCH] package/libxslt: fix static build
  2016-03-29 12:52   ` Thomas Petazzoni
  2016-03-29 13:52     ` Jörg Krause
@ 2016-03-29 17:44     ` Baruch Siach
  2016-03-29 17:56       ` Thomas Petazzoni
  1 sibling, 1 reply; 8+ messages in thread
From: Baruch Siach @ 2016-03-29 17:44 UTC (permalink / raw)
  To: buildroot

Hi Thomas,

On Tue, Mar 29, 2016 at 02:52:14PM +0200, Thomas Petazzoni wrote:
> On Tue, 29 Mar 2016 03:01:13 +0200, Thomas Petazzoni wrote:
> > I've applied because it indeed works, but to be honest, I don't
> > understand why: I don't quite understand how this can fix the build.
> > All what this option does is:
> > 
> > AC_ARG_WITH(libxml-libs-prefix,
> >         [  --with-libxml-libs-prefix=[PFX]      Specify location of libxml libs],
> >         LIBXML_LIBS="-L$withval"
> > )
> > 
> > I.e, it will add -L$(STAGING_DIR)/usr/lib to the gcc options. But that
> > is completely useless because $(STAGING_DIR)/usr/lib is already the
> > default search path for libraries. So why does it fix the build? I
> > don't know.
> 
> Baruch has posted another patch that I believe is supposed to fix the
> same problem: http://patchwork.ozlabs.org/patch/602529/.
> 
> Baruch, J?rg, could you have a closer look at this problem, and see
> which solution, between the one from J?rg and the one from Baruch is
> actually correct ?

The libxml2 patch fixes a bug in xml2-config generation. It fixes static build 
also for raptor, and possibly other libxml2 users (for which libxml2 is only 
an optional dependency, so we don't see hard failures). So I think that the 
libxml2 patch should be applied regardless of this one.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Buildroot] [PATCH] package/libxslt: fix static build
  2016-03-29 17:44     ` Baruch Siach
@ 2016-03-29 17:56       ` Thomas Petazzoni
  2016-03-29 18:35         ` Jörg Krause
  0 siblings, 1 reply; 8+ messages in thread
From: Thomas Petazzoni @ 2016-03-29 17:56 UTC (permalink / raw)
  To: buildroot

Hello,

On Tue, 29 Mar 2016 20:44:53 +0300, Baruch Siach wrote:

> On Tue, Mar 29, 2016 at 02:52:14PM +0200, Thomas Petazzoni wrote:
> > On Tue, 29 Mar 2016 03:01:13 +0200, Thomas Petazzoni wrote:
> > > I've applied because it indeed works, but to be honest, I don't
> > > understand why: I don't quite understand how this can fix the build.
> > > All what this option does is:
> > > 
> > > AC_ARG_WITH(libxml-libs-prefix,
> > >         [  --with-libxml-libs-prefix=[PFX]      Specify location of libxml libs],
> > >         LIBXML_LIBS="-L$withval"
> > > )
> > > 
> > > I.e, it will add -L$(STAGING_DIR)/usr/lib to the gcc options. But that
> > > is completely useless because $(STAGING_DIR)/usr/lib is already the
> > > default search path for libraries. So why does it fix the build? I
> > > don't know.
> > 
> > Baruch has posted another patch that I believe is supposed to fix the
> > same problem: http://patchwork.ozlabs.org/patch/602529/.
> > 
> > Baruch, J?rg, could you have a closer look at this problem, and see
> > which solution, between the one from J?rg and the one from Baruch is
> > actually correct ?
> 
> The libxml2 patch fixes a bug in xml2-config generation. It fixes static build 
> also for raptor, and possibly other libxml2 users (for which libxml2 is only 
> an optional dependency, so we don't see hard failures). So I think that the 
> libxml2 patch should be applied regardless of this one.

Could one of you check if, after the xml2 patch has been applied, the
libxslt fix from J?rg is still needed?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Buildroot] [PATCH] package/libxslt: fix static build
  2016-03-29 17:56       ` Thomas Petazzoni
@ 2016-03-29 18:35         ` Jörg Krause
  0 siblings, 0 replies; 8+ messages in thread
From: Jörg Krause @ 2016-03-29 18:35 UTC (permalink / raw)
  To: buildroot

On Di, 2016-03-29 at 19:56 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 29 Mar 2016 20:44:53 +0300, Baruch Siach wrote:
> 
> > 
> > On Tue, Mar 29, 2016 at 02:52:14PM +0200, Thomas Petazzoni wrote:
> > > 
> > > On Tue, 29 Mar 2016 03:01:13 +0200, Thomas Petazzoni wrote:
> > > > 
> > > > I've applied because it indeed works, but to be honest, I don't
> > > > understand why: I don't quite understand how this can fix the
> > > > build.
> > > > All what this option does is:
> > > > 
> > > > AC_ARG_WITH(libxml-libs-prefix,
> > > > ????????[??--with-libxml-libs-prefix=[PFX]??????Specify
> > > > location of libxml libs],
> > > > ????????LIBXML_LIBS="-L$withval"
> > > > )
> > > > 
> > > > I.e, it will add -L$(STAGING_DIR)/usr/lib to the gcc options.
> > > > But that
> > > > is completely useless because $(STAGING_DIR)/usr/lib is already
> > > > the
> > > > default search path for libraries. So why does it fix the
> > > > build? I
> > > > don't know.
> > > Baruch has posted another patch that I believe is supposed to fix
> > > the
> > > same problem: http://patchwork.ozlabs.org/patch/602529/.
> > > 
> > > Baruch, J?rg, could you have a closer look at this problem, and
> > > see
> > > which solution, between the one from J?rg and the one from Baruch
> > > is
> > > actually correct ?
> > The libxml2 patch fixes a bug in xml2-config generation. It fixes
> > static build?
> > also for raptor, and possibly other libxml2 users (for which
> > libxml2 is only?
> > an optional dependency, so we don't see hard failures). So I think
> > that the?
> > libxml2 patch should be applied regardless of this one.
> Could one of you check if, after the xml2 patch has been applied, the
> libxslt fix from J?rg is still needed?
> 

It builds successfully with xml2 patch applied (without xlst fix).

The difference between the building?libxslt with fix (after applying
libxml2 patch) is the value for?LIBXML_LIBS:

.. without:
S["LIBXML_LIBS"]=" -lxml2
-L/home/joerg/Development/git/buildroot/output/host/usr/arm-buildroot-
linux-uclibcgnueabi/sysroot/usr/lib -llzma -pthread -lm"

.. with:
S["LIBXML_LIBS"]="-
L/home/joerg/Development/git/buildroot/output/host/usr/arm-buildroot-
linux-uclibcgnueabi/sysroot/usr/lib -lxml2
-L/home/joerg/Development/git/build"\
"root/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib 
-llzma -pthread -lm"

But I'm not sure if it makes any difference.

J?rg

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2016-03-29 18:35 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-28 21:09 [Buildroot] [PATCH] package/libxslt: fix static build Jörg Krause
2016-03-29  1:01 ` Thomas Petazzoni
2016-03-29 12:52   ` Thomas Petazzoni
2016-03-29 13:52     ` Jörg Krause
2016-03-29 14:09       ` Thomas Petazzoni
2016-03-29 17:44     ` Baruch Siach
2016-03-29 17:56       ` Thomas Petazzoni
2016-03-29 18:35         ` Jörg Krause

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox