package/libxslt: fix static build
PATCH 1/1 package/libxslt: fix static build
Set --with-libxml-libs-prefix so libtool finds the correct dependencies for libxml2.
Fixes:
http://autobuild.buildroot.net/results/3f8/3f8d876ed6cfe6e73a75fa8904ebdd3f6f0fe53c/
--- package/libxslt/libxslt.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
package/libxslt/libxslt.mk +2 -1
@@ -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
Signature · 1 line
2.7.4
PATCH 1/1 package/libxslt: fix static build
Hello,
Quoted 16 lines · J?rg Krause
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 <[email protected]>--- package/libxslt/libxslt.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)package/libxslt/libxslt.mk +0
-0
package/libxslt/libxslt.mk LIBXSLT_CONF_OPTS = \ · line 18
Quoted 6 lines
package/libxslt/libxslt.mk +2
-1@@ -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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/libxslt: fix static build
Hello,
Quoted 9 lines · Thomas Petazzoni
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"
)
Quoted 4 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/libxslt: fix static build
Quoted 16 lines · Thomas Petazzoni
Hello,
Quoted 12 lines · Thomas Petazzoni
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"
)
Quoted 7 lines
Quoted 5 lines
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.
Quoted 3 lines
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
Quoted 3 lines
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'
Quoted 9 lines
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 inXML_LIBS, so from that point of view, Baruch solution is in line with what libxml2 is already doing.
Quoted 3 lines
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
PATCH 1/1 package/libxslt: fix static build
Hello,
Quoted 9 lines · J?rg Krause
Quoted 3 lines
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.
Quoted 12 lines
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_libsin 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'
Quoted 4 lines
.. 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.
Quoted 5 lines
Quoted 2 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/libxslt: fix static build
In reply to Thomas PetazzoniHi Thomas,
Quoted 15 lines · Thomas Petazzoni
Quoted 9 lines · Thomas Petazzoni
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"
)Quoted 4 lines
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.
Quoted 6 lines
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
Signature · 3 lines
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 -PATCH 1/1 package/libxslt: fix static build
Hello,
Quoted 19 lines · Baruch Siach
Quoted 18 lines · Thomas Petazzoni
Quoted 9 lines · Thomas Petazzoni
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"
)Quoted 4 lines
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/.
Quoted 8 lines
Quoted 3 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/libxslt: fix static build
Quoted 43 lines · Thomas Petazzoni
Hello,
Quoted 32 lines · Baruch Siach
Quoted 25 lines · Thomas Petazzoni
Quoted 12 lines · Thomas Petazzoni
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"
)Quoted 7 lines
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/.Quoted 5 lines
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 ?Quoted 7 lines
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.
Quoted 3 lines
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