Re: [Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.
Hi Norbert, On Sunday, 2011-09-04 16:47:04 -0500, Norbert Thiebaud wrote: I've been working on gbuildification of 'external libraires' taking the approach of untar - patch - configure - post_patch (sometimes it may be easier/useful to patch the result of configure, rather that the input) - make - make install (--prefix=solver) and make uninstall to clean the 'delivered stuff Please ensure that creating a patch on top of the others still works, in dmake that's the create_patch target in solenv/inc/tg_ext.mk Thanks Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.
On Mon, 2011-09-05 at 11:28 +0200, Stephan Bergmann wrote: On Sep 4, 2011, at 11:47 PM, Norbert Thiebaud wrote: why is there zlib/zlib.h and external/zlib/zlib.h ? At least on Linux, that would result in only one of the two versions of the external library being loaded, and the other dependee failing more or less badly. A practical example was libjpeg, iirc the stock libjpeg is always configured using platform endianness, while our internal one *was* configured little endian (or the other way around, stock is always little endian and we configured platform endian). So on solaris if you used the image preview of the gnome file picker you got reversed colours in jpegs seeing as the internal jpeg symbols got used and the gnome dialog was built against the stock system jpeg. The various workaround aren't consistent so its a bit of a horror show at the moment anyway. As one aside, we should probably make the macosx system libs the stock baseline for all the unixes at this stage, i.e. system libxml2/xslt as well as the current system lz, libjpeg etc. In the general case though, anyone got any ideas about a less fragile more universal solution where we could automatically change sonames and tweak symbol names so that *only* our own libs use/are affected by symbols in these bundled libs ? As an aside, for prettyness, it would be nice to have the external headers and libs always installed in inc/external libs/external and add -I -L to the compiler/linker to find them. I gave a go at this at one stage but fell into some trap or other with the odbc headers IIRC C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.
On Mon, 05 Sep 2011 10:47:33 +0100 Caolán McNamara caol...@redhat.com wrote: A practical example was libjpeg, iirc the stock libjpeg is always configured using platform endianness, while our internal one *was* configured little endian (or the other way around, stock is always little endian and we configured platform endian). So on solaris if you used the image preview of the gnome file picker you got reversed colours in jpegs seeing as the internal jpeg symbols got used and the gnome dialog was built against the stock system jpeg. The various workaround aren't consistent so its a bit of a horror show at the moment anyway. As one aside, we should probably make the macosx system libs the stock baseline for all the unixes at this stage, i.e. system libxml2/xslt as well as the current system lz, libjpeg etc. In the general case though, anyone got any ideas about a less fragile more universal solution where we could automatically change sonames and tweak symbol names so that *only* our own libs use/are affected by symbols in these bundled libs ? As an aside, for prettyness, it would be nice to have the external headers and libs always installed in inc/external libs/external and add -I -L to the compiler/linker to find them. I gave a go at this at one stage but fell into some trap or other with the odbc headers IIRC To add fun to this there is a unversioned libjpeg in the libpath you need for compiling java-releated stuff (deployed from the jdk), which makes the whole thing even more interesting. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.
On Mon, Sep 5, 2011 at 4:47 AM, Caolán McNamara caol...@redhat.com wrote:
As an aside, for prettyness, it would be nice to have the external
headers and libs always installed in inc/external libs/external and add
-I -L to the compiler/linker to find them. I gave a go at this at one
stage but fell into some trap or other with the odbc headers IIRC
It may be easier to have --prefix=$(SOLARVER)/external (and then
things in external/lib external/include)
but then again why bother with 'external'. surely we don't want to
pick and choose between system header and our local one for the same
library.
if we have the local one we use it all he time right ?
What I did for zlib to keep, somewhat' the current behavior is a patch
that allow to specify the name of the library in configure:
With that I can ./configure + make + make install . no deliver, no
name mangling
But that solution was relatively easy for zlib because the configure
is actually not the standard autotools
I'm not sure that would transpose to other, more complicated external
libraries...
--- a/configure 2011-09-04 01:04:57.739956936 -0500
+++ b/configure 2011-09-04 01:11:25.436743937 -0500
@@ -18,8 +18,7 @@
CROSS_PREFIX=${CHOST}-
fi
-STATICLIB=libz.a
-LDFLAGS=${LDFLAGS} -L. ${STATICLIB}
+basename=libz
VER=`sed -n -e '/VERSION /s/.*\(.*\).*/\1/p' zlib.h`
VER3=`sed -n -e '/VERSION /s/.*\([0-9]*\\.[0-9]*\\.[0-9]*\).*/\1/p' zlib.h`
VER2=`sed -n -e '/VERSION /s/.*\([0-9]*\\.[0-9]*\)\\..*/\1/p' zlib.h`
@@ -67,9 +66,10 @@
echo 'usage:'
echo ' configure [--zprefix] [--prefix=PREFIX] [--eprefix=EXPREFIX]'
echo '[--static] [--64] [--libdir=LIBDIR] [--sharedlibdir=LIBDIR]'
- echo '[--includedir=INCLUDEDIR]'
+ echo '[--includedir=INCLUDEDIR] [--basename=BASELIBNAME]'
exit 0 ;;
-p*=* | --prefix=*) prefix=`echo $1 | sed 's/.*=//'`; shift ;;
+-b*=* | --basename=*) basename=`echo $1 | sed 's/.*=//'`; shift ;;
-e*=* | --eprefix=*) exec_prefix=`echo $1 | sed 's/.*=//'`; shift ;;
-l*=* | --libdir=*) libdir=`echo $1 | sed 's/.*=//'`; shift ;;
--sharedlibdir=*) sharedlibdir=`echo $1 | sed 's/.*=//'`; shift ;;
@@ -89,6 +89,9 @@
esac
done
+STATICLIB=${basename}.a
+LDFLAGS=${LDFLAGS} -L. ${STATICLIB}
+
test=ztest$$
cat $test.c EOF
extern int getchar();
@@ -118,7 +121,7 @@
uname=`(uname -s || echo unknown) 2/dev/null`
fi
case $uname in
- Linux* | linux* | GNU | GNU/* | *BSD | DragonFly)
LDSHARED=${LDSHARED-$cc -shared
-Wl,-soname,libz.so.1,--version-script,zlib.map} ;;
+ Linux* | linux* | GNU | GNU/* | *BSD | DragonFly)
LDSHARED=${LDSHARED-$cc -shared
-Wl,-soname,${basename}.so.1,--version-script,zlib.map} ;;
CYGWIN* | Cygwin* | cygwin* | OS/2*)
EXE='.exe' ;;
MINGW*|mingw*)
@@ -131,21 +134,21 @@
EXE='.exe' ;;
QNX*) # This is for QNX6. I suppose that the QNX rule below is for QNX2,QNX4
# (alain.bonne...@icbt.com)
- LDSHARED=${LDSHARED-$cc -shared -Wl,-hlibz.so.1} ;;
+ LDSHARED=${LDSHARED-$cc -shared -Wl,-h${basename}.so.1} ;;
HP-UX*)
LDSHARED=${LDSHARED-$cc -shared $SFLAGS}
case `(uname -m || echo unknown) 2/dev/null` in
ia64)
shared_ext='.so'
- SHAREDLIB='libz.so' ;;
+ SHAREDLIB='${basename}.so' ;;
*)
shared_ext='.sl'
- SHAREDLIB='libz.sl' ;;
+ SHAREDLIB='${basename}.sl' ;;
esac ;;
Darwin*) shared_ext='.dylib'
- SHAREDLIB=libz$shared_ext
- SHAREDLIBV=libz.$VER$shared_ext
- SHAREDLIBM=libz.$VER1$shared_ext
+ SHAREDLIB=${basename}$shared_ext
+ SHAREDLIBV=${basename}.$VER$shared_ext
+ SHAREDLIBM=${basename}.$VER1$shared_ext
LDSHARED=${LDSHARED-$cc -dynamiclib -install_name
$libdir/$SHAREDLIBM -compatibility_version $VER1 -current_version
$VER3} ;;
*) LDSHARED=${LDSHARED-$cc -shared} ;;
esac
@@ -164,21 +167,21 @@
case `(uname -m || echo unknown) 2/dev/null` in
ia64)
shared_ext='.so'
- SHAREDLIB='libz.so' ;;
+ SHAREDLIB='${basename}.so' ;;
*)
shared_ext='.sl'
- SHAREDLIB='libz.sl' ;;
+ SHAREDLIB='${basename}.sl' ;;
esac ;;
IRIX*) SFLAGS=${CFLAGS--ansi -O2 -rpath .}
CFLAGS=${CFLAGS--ansi -O2}
- LDSHARED=${LDSHARED-cc -shared -Wl,-soname,libz.so.1} ;;
+ LDSHARED=${LDSHARED-cc -shared -Wl,-soname,${basename}.so.1} ;;
OSF1\ V4*) SFLAGS=${CFLAGS--O -std1}
CFLAGS=${CFLAGS--O -std1}
LDFLAGS=${LDFLAGS} -Wl,-rpath,.
- LDSHARED=${LDSHARED-cc -shared -Wl,-soname,libz.so
-Wl,-msym -Wl,-rpath,$(libdir) -Wl,-set_version,${VER}:1.0} ;;
+ LDSHARED=${LDSHARED-cc -shared
-Wl,-soname,${basename}.so -Wl,-msym -Wl,-rpath,$(libdir)
Re: [Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.
On Mon, 2011-09-05 at 12:40 +0200, Bjoern Michaelsen wrote: To add fun to this there is a unversioned libjpeg in the libpath you need for compiling java-releated stuff (deployed from the jdk), which makes the whole thing even more interesting. I think we should be able to remove that entire -L/path/to/java/sdk/lib where that libjpeg lives from our universal link line. I think we only ever need to link to something in there for bean to link to lib[j]awt so we could add it in locally there and the problem, and the various silly workarounds for it in solenv, could go away ? C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.
On Mon, 2011-09-05 at 05:44 -0500, Norbert Thiebaud wrote: It may be easier to have --prefix=$(SOLARVER)/external (and then things in external/lib external/include) but then again why bother with 'external'. surely we don't want to pick and choose between system header and our local one for the same library. if we have the local one we use it all he time right ? Yeah, I can't think of a reason why we would want to mix and match. That definitely wasn't the goal anyway. I have a vague memory of --prefix=$(SOLARVER)/external being a good thing for some concrete reason. If I'm right, then it'll be quickly apparent that its a good thing to do :-). So I wouldn't worry about it. If its a good thing to do it'll lend itself as the fix automatically as you build through them. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.
On Mon, 05 Sep 2011 11:46:38 +0100 Caolán McNamara caol...@redhat.com wrote: I think we should be able to remove that entire -L/path/to/java/sdk/lib where that libjpeg lives from our universal link line. I think we only ever need to link to something in there for bean to link to lib[j]awt so we could add it in locally there and the problem, and the various silly workarounds for it in solenv, could go away ? IIRC, I avoided reimplementing that in gbuild (i.e. the default link never had a sdk in it). A fast grep on solenv for JAVALIB and JAVA_HOME looks rather clean by now, so I guess we only have to make sure they dont creep back in. ;) Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] gbuild of external libraries and question about apparently special case like zlib, jpeg etc.
I've been working on gbuildification of 'external libraires' taking the approach of untar - patch - configure - post_patch (sometimes it may be easier/useful to patch the result of configure, rather that the input) - make - make install (--prefix=solver) and make uninstall to clean the 'delivered stuff Th make install/uninstall approch seems nice because it avoid the need to enumerate the file to be delivered (hence reduce maintenance cost and mishap). sure it 'deliver' more than we strictly need (like man pages and the like) but overall I think that is still a win. Now, the question is: is there any scenario where one would build the internal library but only use the internal library for some module and the system library for others? iow, why does the current code use a separate name for the internal library, like libzlib or libjpeglib ? is this really (still) needed ? in the same vein, why is there zlib/zlib.h and external/zlib/zlib.h ? if it is still needed then for these modules I guess I will have to 'install' in workdir and still have a 'packaging' step to deliver to solver... or, when possible patch the external library (I did that to zlib to add a configure option to change the library name.. ) ps: I started a ExternalLib.mk extention of gbuild. use will look something like: $(eval $(call gb_ExternalLib_ExternalLib,zlib,autotools)) $(eval $(call gb_ExternalLib_set_src_package,zlib,c735eab2d659a96e5a594c9e8541ad63-zlib-1.2.5.tar.gz)) $(eval $(call gb_ExternalLib_add_patches,zlib, \ zlib/zlib-1.2.5.basename.patch \ )) $(eval $(call gb_ExternalLib_add_cflags,zlib,-fPIC)) $(eval $(call gb_ExternalLib_add_conf_arg,zlib,--zprefix --basename=libloz)) # vim: set noet sw=4 ts=4: note: the 3rd argument of gb_ExternalLib_ExternalLib is meant to allow for the support of different kind of build system (like ant, some custom script, etc.) I am planning also to expend it to have a 'fetch' target so that make fetch would be gbuildified too, and that would also allow for 'as-needed' download of external package, based on autogen settings... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
