| Submitter | Khem Raj |
|---|---|
| Date | Feb. 6, 2012, 6:40 a.m. |
| Message ID | <c68f6de298c35c25638ea3a5adeb06c97cd74036.1328510189.git.raj.khem@gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/20741/ |
| State | New |
| Headers | show |
Comments
On 02/05/2012 10:40 PM, Khem Raj wrote: > Dont use autotools, it really not so autoconf like. > the configure script gets updated with every release of zlib > and we overwrite that. Instead use the upstream provided > configure > > copyright year was changed in zlib.h which caused change in > LIC_FILE_CHECKSUM > > fix.inverted.LFS.logic.patch is already applied upstream so drop it > > Drop the configure.ac and Makefile.am scripts since we do not > autoreconf anymore and do not inherit autotools anymore > Not sure what's up with this patch, but it is causing failures in other recipes that depend on libz, it seems like the libz.la is not getting installed correctly. | /bin/grep: /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la: No such file or directory | /bin/sed: can't read /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la: No such file or directory | i586-poky-linux-libtool: link: `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' is not a valid libtool archive Sau! > Signed-off-by: Khem Raj<raj.khem@gmail.com> > --- > meta/recipes-core/zlib/files/Makefile.am | 9 ---- > meta/recipes-core/zlib/files/configure.ac | 48 -------------------- > .../zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch | 20 -------- > meta/recipes-core/zlib/zlib_1.2.5.bb | 41 ----------------- > meta/recipes-core/zlib/zlib_1.2.6.bb | 26 +++++++++++ > 5 files changed, 26 insertions(+), 118 deletions(-) > delete mode 100644 meta/recipes-core/zlib/files/Makefile.am > delete mode 100644 meta/recipes-core/zlib/files/configure.ac > delete mode 100644 meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch > delete mode 100644 meta/recipes-core/zlib/zlib_1.2.5.bb > create mode 100644 meta/recipes-core/zlib/zlib_1.2.6.bb > > diff --git a/meta/recipes-core/zlib/files/Makefile.am b/meta/recipes-core/zlib/files/Makefile.am > deleted file mode 100644 > index b66d299..0000000 > --- a/meta/recipes-core/zlib/files/Makefile.am > +++ /dev/null > @@ -1,9 +0,0 @@ > -lib_LTLIBRARIES = libz.la > - > -libz_la_SOURCES = adler32.c compress.c crc32.c gzlib.c gzclose.c gzread.c \ > - gzwrite.c uncompr.c deflate.c trees.c zutil.c inflate.c \ > - infback.c inftrees.c inffast.c > - > -libz_la_LDFLAGS = -version-number 1:2:5 --version-script zlib.map > - > -include_HEADERS = zconf.h zlib.h zlibdefs.h > diff --git a/meta/recipes-core/zlib/files/configure.ac b/meta/recipes-core/zlib/files/configure.ac > deleted file mode 100644 > index 4761b7e..0000000 > --- a/meta/recipes-core/zlib/files/configure.ac > +++ /dev/null > @@ -1,48 +0,0 @@ > -AC_INIT(zlib,1.2.5) > -AC_CONFIG_SRCDIR(adler32.c) > -AM_INIT_AUTOMAKE(zlibs,1.2.5) > - > -AC_PREREQ([2.59]) > - > -AC_PROG_CC([gcc]) > -AC_PROG_LIBTOOL > - > -AC_HEADER_STDC > - > -zlib_save_CPPFLAGS=$CPPFLAGS > -CPPFLAGS="$CPPFLAGS -D_LARGEFILE64_SOURCE" > -AC_CHECK_TYPES(off64_t) > -CPPFLAGS=$zlib_save_CPPFLAGS > - > -AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], [zlib_cv_use_lfs64], [ > - zlib_cv_use_lfs64=no > - if test "$ac_cv_type_off64_t" = "yes"; then > - zlib_cv_use_lfs64=yes > - fi > -]) > - > -if test "$zlib_cv_use_lfs64" = "yes"; then > - CPPFLAGS="$CPPFLAGS -D_LARGEFILE64_SOURCE" > - > - #APR_ADDTO(CPPFLAGS, [-D_LARGEFILE64_SOURCE]) > -fi > - > -cat> zlibdefs.h<< EOF > -/* zlibdefs.h -- compile-time definitions for the zlib compression library > - * Copyright (C) 1995-2006 Jean-loup Gailly. > - * For conditions of distribution and use, see copyright notice in zlib.h > - */ > - > -#include<sys/types.h> /* for off_t */ > -#include<unistd.h> /* for SEEK_* and off_t */ > -#ifdef VMS > -# include<unixio.h> /* for off_t */ > -#endif > -#ifndef z_off_t > -# define z_off_t off_t > -#endif > -EOF > - > -AC_CONFIG_FILES([Makefile]) > - > -AC_OUTPUT > diff --git a/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch b/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch > deleted file mode 100644 > index 038c1a2..0000000 > --- a/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch > +++ /dev/null > @@ -1,20 +0,0 @@ > -Upstream-Status: Pending > - > -see > -https://bugs.gentoo.org/316377?id=316377 > -https://bugs.freedesktop.org/show_bug.cgi?id=33710 > -http://lists.freedesktop.org/archives/poppler-bugs/2011-January/006014.html > -for details > - > -diff -up zlib-1.2.5/zlib.h.pom zlib-1.2.5/zlib.h > ---- zlib-1.2.5/zlib.h.pom 2010-04-20 06:12:48.000000000 +0200 > -+++ zlib-1.2.5/zlib.h 2010-06-16 13:08:59.000000000 +0200 > -@@ -1578,7 +1578,7 @@ ZEXTERN int ZEXPORT inflateBackInit_ OF( > - # define gzoffset gzoffset64 > - # define adler32_combine adler32_combine64 > - # define crc32_combine crc32_combine64 > --# ifdef _LARGEFILE64_SOURCE > -+# ifndef _LARGEFILE64_SOURCE > - ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); > - ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int)); > - ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile)); > diff --git a/meta/recipes-core/zlib/zlib_1.2.5.bb b/meta/recipes-core/zlib/zlib_1.2.5.bb > deleted file mode 100644 > index b5756d9..0000000 > --- a/meta/recipes-core/zlib/zlib_1.2.5.bb > +++ /dev/null > @@ -1,41 +0,0 @@ > -SUMMARY = "Zlib Compression Library" > -DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data compression \ > -library which is used by many different programs." > -HOMEPAGE = "http://zlib.net/" > -SECTION = "libs" > -LICENSE = "Zlib" > -LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d" > - > -DEPENDS = "libtool-cross" > -PR = "r3" > - > -SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \ > - file://configure.ac \ > - file://Makefile.am \ > - file://fix.inverted.LFS.logic.patch" > - > -SRC_URI[md5sum] = "be1e89810e66150f5b0327984d8625a0" > -SRC_URI[sha256sum] = "239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307" > - > -inherit autotools > - > -do_configure_prepend () { > - cp ${WORKDIR}/configure.ac ${S}/ > - cp ${WORKDIR}/Makefile.am ${S}/ > -} > - > -do_install_append () { > - sed \ > - -e 's:@prefix@:${prefix}:' \ > - -e 's:@exec_prefix@:${exec_prefix}:' \ > - -e 's:@libdir@:${libdir}:' \ > - -e 's:@sharedlibdir@:${libdir}:' \ > - -e 's:@includedir@:${includedir}:' \ > - -e 's:@VERSION@:${PV}:' \ > - zlib.pc.in> zlib.pc > - > - install -d ${D}${libdir}/pkgconfig > - install -m 0644 zlib.pc ${D}${libdir}/pkgconfig/ > -} > - > -BBCLASSEXTEND = "native nativesdk" > diff --git a/meta/recipes-core/zlib/zlib_1.2.6.bb b/meta/recipes-core/zlib/zlib_1.2.6.bb > new file mode 100644 > index 0000000..a220773 > --- /dev/null > +++ b/meta/recipes-core/zlib/zlib_1.2.6.bb > @@ -0,0 +1,26 @@ > +SUMMARY = "Zlib Compression Library" > +DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data compression \ > +library which is used by many different programs." > +HOMEPAGE = "http://zlib.net/" > +SECTION = "libs" > +LICENSE = "Zlib" > +LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e66a9" > + > +SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \ > + " > +SRC_URI[md5sum] = "dc2cfa0d2313ca77224b4d932b2911e9" > +SRC_URI[sha256sum] = "fa3e3e4881fa5810b8903f2c7e0dcd5a0a673535f0438021c4bbb5db1b918c8e" > + > +do_configure (){ > + ./configure --prefix=${prefix} --shared --libdir=${libdir} > +} > + > +do_compile (){ > + oe_runmake > +} > + > +do_install() { > + oe_runmake DESTDIR=${D} install > +} > + > +BBCLASSEXTEND = "native nativesdk"
On Tue, Feb 7, 2012 at 12:08 AM, Saul Wold <sgw@linux.intel.com> wrote: > | /bin/grep: /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la: > No such file or directory thanks ok I did not catch it with sato image build. which package is failing with this error.
On 02/07/2012 07:31 AM, Khem Raj wrote: > On Tue, Feb 7, 2012 at 12:08 AM, Saul Wold<sgw@linux.intel.com> wrote: >> | /bin/grep: /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la: >> No such file or directory > > thanks ok I did not catch it with sato image build. which package is > failing with this > error. > pixman, gconf, polkit are the 3 I saw doing a world build. Sau!
On (07/02/12 07:59), Saul Wold wrote: > On 02/07/2012 07:31 AM, Khem Raj wrote: > >On Tue, Feb 7, 2012 at 12:08 AM, Saul Wold<sgw@linux.intel.com> wrote: > >>| /bin/grep: /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la: > >>No such file or directory > > > >thanks ok I did not catch it with sato image build. which package is > >failing with this > >error. > > > pixman, gconf, polkit are the 3 I saw doing a world build. I havent been able to reproduce it with eglibc I tried bitbake gconf pixman polkit it all liked well. Might be my machine is just nice to me but that said when I get to the culprit it mostly will be the package who is using .la in weird way since zlib already ships a .pc file it should have used that one instead > > Sau!
On 02/07/2012 03:12 PM, Khem Raj wrote: > On (07/02/12 07:59), Saul Wold wrote: >> On 02/07/2012 07:31 AM, Khem Raj wrote: >>> On Tue, Feb 7, 2012 at 12:08 AM, Saul Wold<sgw@linux.intel.com> wrote: >>>> | /bin/grep: /intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la: >>>> No such file or directory >>> >>> thanks ok I did not catch it with sato image build. which package is >>> failing with this >>> error. >>> >> pixman, gconf, polkit are the 3 I saw doing a world build. > > I havent been able to reproduce it with eglibc I tried bitbake gconf > pixman polkit it all liked well. Might be my machine is just nice to me > but that said when I get to the culprit it mostly will be the package > who is using .la in weird way since zlib already ships a .pc file it > should have used that one instead > Khem, Can you verify if you have a .la file in you sysroot? tmp/work/i586-poky-linux/zlib-1.2.5-r3/package/usr/lib: libz.a libz.la libz.so libz.so.1 libz.so.1.2.5 pkgconfig tmp/work/i586-poky-linux/zlib-1.2.6-r0/package/usr/lib: libz.a libz.so libz.so.1 libz.so.1.2.6 pkgconfig Very reproducible on my machine: | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [trap-crasher] Error 1 | make[2]: *** Waiting for unfinished jobs.... | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [fetch-test] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [region-test] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [pdf-op-test] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhERROR: Function failed: do_compile (see /intel/poky/builds/world/tmp/work/i586-poky-linux/pixman-1_0.24.2-r0/temp/log.do_compile.13548 for further information) | andled argument `=/usr/lib/libz.la' | make[2]: *** [oob-test] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [alpha-loop] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [a1-trap-test] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [region-translate-test] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [scaling-helpers-test] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [scaling-crash-test] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [gradient-crash-test] Error 1 | i586-poky-linux-libtool: link: cannot find the library `/intel/poky/builds/world/tmp/sysroots/qemux86/usr/lib/libz.la' or unhandled argument `=/usr/lib/libz.la' | make[2]: *** [region-contains-test] Error 1 | make[2]: Leaving directory `/intel/poky/builds/world/tmp/work/i586-poky-linux/pixman-1_0.24.2-r0/pixman-0.24.2/test' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/intel/poky/builds/world/tmp/work/i586-poky-linux/pixman-1_0.24.2-r0/pixman-0.24.2' | make: *** [all] Error 2 | ERROR: oe_runmake failed NOTE: package pixman-1_0.24.2-r0: task do_compile: Failed Sau! >> >> Sau! >
On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: > > Can you verify if you have a .la file in you sysroot? No its not there and thats the point we probably should learn to live with out it actually one of radical ideas I have is to get rid of all .la files in OE completely right now python modules e.g. have them and thats wrong since they never use it and there are other packages like that.
On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: >> >> Can you verify if you have a .la file in you sysroot? > > > No its not there and thats the point we probably should learn to live > with out it > actually one of radical ideas I have is to get rid of all .la files in > OE completely > right now python modules e.g. have them and thats wrong since they never use it > and there are other packages like that. FWIW, after a pull of oe-core today that included the zlib update I am getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb: | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such file or directory | /bin/sed: can't read /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such file or directory | arm-poky-linux-gnueabi-libtool: link: `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a valid libtool archive | make[4]: *** [libgdk-x11-2.0.la] Error 1 Steve
Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven: > On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: >>> >>> Can you verify if you have a .la file in you sysroot? >> >> >> No its not there and thats the point we probably should learn to live >> with out it >> actually one of radical ideas I have is to get rid of all .la files in >> OE completely >> right now python modules e.g. have them and thats wrong since they never use it >> and there are other packages like that. > > FWIW, after a pull of oe-core today that included the zlib update I am > getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb: > > | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: > No such file or directory > | /bin/sed: can't read > /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such > file or directory > | arm-poky-linux-gnueabi-libtool: link: > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a > valid libtool archive > | make[4]: *** [libgdk-x11-2.0.la] Error 1 It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc
On Fri, Feb 10, 2012 at 9:09 PM, Koen Kooi <koen@dominion.thruhere.net> wrote: > > Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven: > >> On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: >>>> >>>> Can you verify if you have a .la file in you sysroot? >>> >>> >>> No its not there and thats the point we probably should learn to live >>> with out it >>> actually one of radical ideas I have is to get rid of all .la files in >>> OE completely >>> right now python modules e.g. have them and thats wrong since they never use it >>> and there are other packages like that. >> >> FWIW, after a pull of oe-core today that included the zlib update I am >> getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb: >> >> | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: >> No such file or directory >> | /bin/sed: can't read >> /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such >> file or directory >> | arm-poky-linux-gnueabi-libtool: link: >> `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a >> valid libtool archive >> | make[4]: *** [libgdk-x11-2.0.la] Error 1 > > > It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc yeah libtool is very hard to get rid of see how many of files in your sysroot has zlib.la added to other .la files. You need to clean all those I wrote a small script which grepped oe-core for occurrence of all zlib.la in *.la files in sysroot and then dumps the ipks content to figure out which package provided that .la then bumped PRs of those recipes which were providing those ipks. unfortunately this script was in tmdir and got deleted. > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Sat, Feb 11, 2012 at 12:15 AM, Khem Raj <raj.khem@gmail.com> wrote: > On Fri, Feb 10, 2012 at 9:09 PM, Koen Kooi <koen@dominion.thruhere.net> wrote: >> >> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven: >> >>> On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: >>>>> >>>>> Can you verify if you have a .la file in you sysroot? >>>> >>>> >>>> No its not there and thats the point we probably should learn to live >>>> with out it >>>> actually one of radical ideas I have is to get rid of all .la files in >>>> OE completely >>>> right now python modules e.g. have them and thats wrong since they never use it >>>> and there are other packages like that. >>> >>> FWIW, after a pull of oe-core today that included the zlib update I am >>> getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb: >>> >>> | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: >>> No such file or directory >>> | /bin/sed: can't read >>> /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such >>> file or directory >>> | arm-poky-linux-gnueabi-libtool: link: >>> `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a >>> valid libtool archive >>> | make[4]: *** [libgdk-x11-2.0.la] Error 1 >> >> >> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc > > yeah libtool is very hard to get rid of see how many of files in your > sysroot has zlib.la added to other .la files. You need to clean all > those > > I wrote a small script which grepped oe-core for occurrence of all > zlib.la in *.la files in sysroot > and then dumps the ipks content to figure out which package provided > that .la then bumped PRs of those recipes which were providing those > ipks. > unfortunately this script was in tmdir and got deleted. ah screen saved a snapshot here is the script sysroot=/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemux86 deploy="/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/deploy/ipk/i586 /home/kraj/work/angstrom/sources/ openembedded-core/build/tmp-eglibc/deploy/ipk/qemux86" las=$(find $sysroot -name *.la|xargs grep -Hns libz.la | cut -d':' -f 1) for f in $las do ff=`basename $f` for fff in $(find $deploy -name '*.ipk') do dpkg-deb -c $fff | grep $ff >& /dev/null if [ $? = 0 ] then ls $fff break fi done done
Op 11 feb. 2012 om 09:15 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven: > On Fri, Feb 10, 2012 at 9:09 PM, Koen Kooi <koen@dominion.thruhere.net> wrote: >> >> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven: >> >>> On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: >>>>> >>>>> Can you verify if you have a .la file in you sysroot? >>>> >>>> >>>> No its not there and thats the point we probably should learn to live >>>> with out it >>>> actually one of radical ideas I have is to get rid of all .la files in >>>> OE completely >>>> right now python modules e.g. have them and thats wrong since they never use it >>>> and there are other packages like that. >>> >>> FWIW, after a pull of oe-core today that included the zlib update I am >>> getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb: >>> >>> | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: >>> No such file or directory >>> | /bin/sed: can't read >>> /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such >>> file or directory >>> | arm-poky-linux-gnueabi-libtool: link: >>> `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a >>> valid libtool archive >>> | make[4]: *** [libgdk-x11-2.0.la] Error 1 >> >> >> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc > > yeah libtool is very hard to get rid of see how many of files in your > sysroot has zlib.la added to other .la files. You need to clean all > those > > I wrote a small script which grepped oe-core for occurrence of all > zlib.la in *.la files in sysroot > and then dumps the ipks content to figure out which package provided > that .la then bumped PRs of those recipes which were providing those > ipks. > unfortunately this script was in tmdir and got deleted. rpmdebs Will break during do_rootfs, no time to look into that, ipk works >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Sat, Feb 11, 2012 at 06:09:52AM +0100, Koen Kooi wrote: > > Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven: > > > On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: > >> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: > >>> > >>> Can you verify if you have a .la file in you sysroot? > >> > >> > >> No its not there and thats the point we probably should learn to live > >> with out it > >> actually one of radical ideas I have is to get rid of all .la files in > >> OE completely > >> right now python modules e.g. have them and thats wrong since they never use it > >> and there are other packages like that. > > > > FWIW, after a pull of oe-core today that included the zlib update I am > > getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb: > > > > | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: > > No such file or directory > > | /bin/sed: can't read > > /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such > > file or directory > > | arm-poky-linux-gnueabi-libtool: link: > > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a > > valid libtool archive > > | make[4]: *** [libgdk-x11-2.0.la] Error 1 > > > It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc list for me evas ecore fsogsmd pidgin elementary fsodeviced fsoaudiod subversion python-evas libsoup-2.4 libeflvala efreet fsotdld poppler fsosystemd fsousaged fsonetworkd gtk+ python-gst emotion mysql5 libfsotransport libfsobasics gd libgsm0710mux gst-plugins-base iksemel fsodatad webkit-gtk fsodatad epdf librsvg curl libsexy libfsosystem orbit2 libfso-glib pango eeze libshr-glib farsight2 id3lib gst-plugins-good gst-plugins-ugly libnice libgpewidget matchbox-panel-2 edbus vte ethumb glib-networking libgisi libfsoresource edje libfsoframework gconf file libglade json-glib ethumb libcroco gnome-keyring libsdl-image neon qt4-x11-free python-pygobject msmcomm-specs gnome-keyring libphone-ui shr-wizard matchbox-keyboard matchbox-panel-2 And this isn't even on fully built feed :/.
On Sun, Feb 12, 2012 at 11:48 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Sat, Feb 11, 2012 at 06:09:52AM +0100, Koen Kooi wrote: >> >> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven: >> >> > On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >> >> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: >> >>> >> >>> Can you verify if you have a .la file in you sysroot? >> >> >> >> >> >> No its not there and thats the point we probably should learn to live >> >> with out it >> >> actually one of radical ideas I have is to get rid of all .la files in >> >> OE completely >> >> right now python modules e.g. have them and thats wrong since they never use it >> >> and there are other packages like that. >> > >> > FWIW, after a pull of oe-core today that included the zlib update I am >> > getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb: >> > >> > | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: >> > No such file or directory >> > | /bin/sed: can't read >> > /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such >> > file or directory >> > | arm-poky-linux-gnueabi-libtool: link: >> > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a >> > valid libtool archive >> > | make[4]: *** [libgdk-x11-2.0.la] Error 1 >> >> >> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc > > list for me > > evas ecore fsogsmd pidgin elementary fsodeviced fsoaudiod subversion > python-evas libsoup-2.4 libeflvala efreet fsotdld poppler fsosystemd > fsousaged fsonetworkd gtk+ python-gst emotion mysql5 libfsotransport > libfsobasics gd libgsm0710mux gst-plugins-base iksemel fsodatad > webkit-gtk fsodatad epdf librsvg curl libsexy libfsosystem orbit2 > libfso-glib pango eeze libshr-glib farsight2 id3lib gst-plugins-good > gst-plugins-ugly libnice libgpewidget matchbox-panel-2 edbus vte ethumb > glib-networking libgisi libfsoresource edje libfsoframework gconf file > libglade json-glib ethumb libcroco gnome-keyring libsdl-image neon > qt4-x11-free python-pygobject msmcomm-specs gnome-keyring libphone-ui > shr-wizard matchbox-keyboard matchbox-panel-2 > > And this isn't even on fully built feed :/. Indeed! I gave up on trying to determine an exhaustive list and just blew away tmp and sstate and rebuilt everything -- including package repositories :-( We need to find a way to prevent or warn of disruptive changes like this zlib patch. For those of us trying to make a living using Yocto, losing a day of productivity to things like this really stings. Steve
On Mon, Feb 13, 2012 at 05:23:18AM -0800, Steve Sakoman wrote: > On Sun, Feb 12, 2012 at 11:48 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > > On Sat, Feb 11, 2012 at 06:09:52AM +0100, Koen Kooi wrote: > >> > >> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven: > >> > >> > On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: > >> >> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: > >> >>> > >> >>> Can you verify if you have a .la file in you sysroot? > >> >> > >> >> > >> >> No its not there and thats the point we probably should learn to live > >> >> with out it > >> >> actually one of radical ideas I have is to get rid of all .la files in > >> >> OE completely > >> >> right now python modules e.g. have them and thats wrong since they never use it > >> >> and there are other packages like that. > >> > > >> > FWIW, after a pull of oe-core today that included the zlib update I am > >> > getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb: > >> > > >> > | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: > >> > No such file or directory > >> > | /bin/sed: can't read > >> > /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such > >> > file or directory > >> > | arm-poky-linux-gnueabi-libtool: link: > >> > `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a > >> > valid libtool archive > >> > | make[4]: *** [libgdk-x11-2.0.la] Error 1 > >> > >> > >> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc > > > > list for me > > > > evas ecore fsogsmd pidgin elementary fsodeviced fsoaudiod subversion > > python-evas libsoup-2.4 libeflvala efreet fsotdld poppler fsosystemd > > fsousaged fsonetworkd gtk+ python-gst emotion mysql5 libfsotransport > > libfsobasics gd libgsm0710mux gst-plugins-base iksemel fsodatad > > webkit-gtk fsodatad epdf librsvg curl libsexy libfsosystem orbit2 > > libfso-glib pango eeze libshr-glib farsight2 id3lib gst-plugins-good > > gst-plugins-ugly libnice libgpewidget matchbox-panel-2 edbus vte ethumb > > glib-networking libgisi libfsoresource edje libfsoframework gconf file > > libglade json-glib ethumb libcroco gnome-keyring libsdl-image neon > > qt4-x11-free python-pygobject msmcomm-specs gnome-keyring libphone-ui > > shr-wizard matchbox-keyboard matchbox-panel-2 > > > > And this isn't even on fully built feed :/. > > Indeed! I gave up on trying to determine an exhaustive list and just > blew away tmp and sstate and rebuilt everything -- including package > repositories :-( > > We need to find a way to prevent or warn of disruptive changes like > this zlib patch. For those of us trying to make a living using Yocto, > losing a day of productivity to things like this really stings. I have 131 items in my list now, will send PR bumps today. > Steve > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Op 13 feb. 2012, om 05:23 heeft Steve Sakoman het volgende geschreven: > On Sun, Feb 12, 2012 at 11:48 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> On Sat, Feb 11, 2012 at 06:09:52AM +0100, Koen Kooi wrote: >>> >>> Op 11 feb. 2012, om 06:05 heeft Steve Sakoman het volgende geschreven: >>> >>>> On Tue, Feb 7, 2012 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>> On Tue, Feb 7, 2012 at 4:19 PM, Saul Wold <sgw@linux.intel.com> wrote: >>>>>> >>>>>> Can you verify if you have a .la file in you sysroot? >>>>> >>>>> >>>>> No its not there and thats the point we probably should learn to live >>>>> with out it >>>>> actually one of radical ideas I have is to get rid of all .la files in >>>>> OE completely >>>>> right now python modules e.g. have them and thats wrong since they never use it >>>>> and there are other packages like that. >>>> >>>> FWIW, after a pull of oe-core today that included the zlib update I am >>>> getting similar failures on meta/recipes-gnome/gtk+/gtk+_2.24.8.bb: >>>> >>>> | /bin/grep: /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: >>>> No such file or directory >>>> | /bin/sed: can't read >>>> /media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la: No such >>>> file or directory >>>> | arm-poky-linux-gnueabi-libtool: link: >>>> `/media/Work/yocto/tmp/sysroots/omap3-multi/usr/lib/libz.la' is not a >>>> valid libtool archive >>>> | make[4]: *** [libgdk-x11-2.0.la] Error 1 >>> >>> >>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc >> >> list for me >> >> evas ecore fsogsmd pidgin elementary fsodeviced fsoaudiod subversion >> python-evas libsoup-2.4 libeflvala efreet fsotdld poppler fsosystemd >> fsousaged fsonetworkd gtk+ python-gst emotion mysql5 libfsotransport >> libfsobasics gd libgsm0710mux gst-plugins-base iksemel fsodatad >> webkit-gtk fsodatad epdf librsvg curl libsexy libfsosystem orbit2 >> libfso-glib pango eeze libshr-glib farsight2 id3lib gst-plugins-good >> gst-plugins-ugly libnice libgpewidget matchbox-panel-2 edbus vte ethumb >> glib-networking libgisi libfsoresource edje libfsoframework gconf file >> libglade json-glib ethumb libcroco gnome-keyring libsdl-image neon >> qt4-x11-free python-pygobject msmcomm-specs gnome-keyring libphone-ui >> shr-wizard matchbox-keyboard matchbox-panel-2 >> >> And this isn't even on fully built feed :/. > > Indeed! I gave up on trying to determine an exhaustive list and just > blew away tmp and sstate and rebuilt everything -- including package > repositories :-( > > We need to find a way to prevent or warn of disruptive changes like > this zlib patch. For those of us trying to make a living using Yocto, > losing a day of productivity to things like this really stings. A while ago there were 2 weeks with absolutely no breakage which I really liked. Then people can back from their xmas holidays....
On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote: > We need to find a way to prevent or warn of disruptive changes like > this zlib patch. Aren't these sorts of things meant to get tested on the Yocto autobuilder before being merged? I thought that was how it was supposed to work. p.
On Mon, Feb 13, 2012 at 7:39 AM, Phil Blundell <philb@gnu.org> wrote: > On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote: >> We need to find a way to prevent or warn of disruptive changes like >> this zlib patch. > > Aren't these sorts of things meant to get tested on the Yocto > autobuilder before being merged? I thought that was how it was supposed > to work. > The patch takes care of packages in oe-core but essentially relied upon layers to consider the update and I also posted a script that would help in identifying recipes which need updates.
>>>> >>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc >>> I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue? Best Regards, Lianhao
On Mon, Feb 13, 2012 at 8:52 PM, Lu, Lianhao <lianhao.lu@intel.com> wrote: >>>>> >>>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc >>>> > > I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue? try to find which native .la files have libz,la in deps and rebuild them too > > Best Regards, > Lianhao > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tue, Feb 14, 2012 at 04:52:30AM +0000, Lu, Lianhao wrote: > >>>> > >>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc > >>> > > I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue? one .la still with libz.la in dependency tree is enough to pollute all .la files even when they get rebuild thanks to PR bump. That's why I sent another wider round of PR bumps to oe-core and also to all layers (oe-core, meta-openembedded/*, meta-smartphone/*) I'm using at once, because ie libsoup-2.4 from meta-efl wasn't PR bumped and was still pulling libz.la to all .la files depending on libsoup :/. And even my wider PR bump round isn't 100% complete for everybody, because it's based on sysroot popultated by my builds and you can have different .la files there (from different recipe versions or different layers). Cheers,
On Mon, 2012-02-13 at 22:24 -0800, Khem Raj wrote: > On Mon, Feb 13, 2012 at 8:52 PM, Lu, Lianhao <lianhao.lu@intel.com> wrote: > >>>>> > >>>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc > >>>> > > > > I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue? > > try to find which native .la files have libz,la in deps > and rebuild them too Can we not just put libz.la back in zlib? Having to spend hours hunting out and rebuilding things, and/or bumping PR on half the .bb files in the repository, seems like an unsatisfactory state of affairs. As far as I know the presence of libz.la wasn't previously causing us any trouble so I'm not entirely clear why heroic measures are justified in trying to get rid of it. p.
Op 13 feb. 2012, om 22:53 heeft Martin Jansa het volgende geschreven: > On Tue, Feb 14, 2012 at 04:52:30AM +0000, Lu, Lianhao wrote: >>>>>> >>>>>> It works if you -c cleansstate on a bunch of recipes, pango, cairo, fontconfig, gtk+, etc >>>>> >> >> I tried rpm-native after "-c cleansstate", but it still asks for libz.la? Anyone has the clue? > > one .la still with libz.la in dependency tree is enough to pollute all > .la files even when they get rebuild thanks to PR bump. > > That's why I sent another wider round of PR bumps to oe-core and also to > all layers (oe-core, meta-openembedded/*, meta-smartphone/*) I'm using at once, > because ie libsoup-2.4 from meta-efl wasn't PR bumped and was still pulling > libz.la to all .la files depending on libsoup :/. > > And even my wider PR bump round isn't 100% complete for everybody, > because it's based on sysroot popultated by my builds and you can have > different .la files there (from different recipe versions or different > layers). Saul and I discussed this yesterday and we also suspect using --as-needed in LDFLAGS limits the impact of this problem. But still, PR bumps are needed to keep the -dev packages in the feeds working. regards, Koen
On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote: > Indeed! I gave up on trying to determine an exhaustive list and just > blew away tmp and sstate and rebuilt everything -- including package > repositories :-( > > We need to find a way to prevent or warn of disruptive changes like > this zlib patch. For those of us trying to make a living using Yocto, > losing a day of productivity to things like this really stings. I agree this change sucked and showed us we have some real issues. I will point out that if we had been using the basichash signature generator, it would likely have picked up this change and rebuild all the appropriate pieces. This illustrates why we do really need to switch to the basichash dependency model even if some things are going to rebuild a bit more often as humans make bad judges of what needs rebuilding... Cheers, Richard
On Mon, 2012-02-13 at 15:39 +0000, Phil Blundell wrote: > On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote: > > We need to find a way to prevent or warn of disruptive changes like > > this zlib patch. > > Aren't these sorts of things meant to get tested on the Yocto > autobuilder before being merged? I thought that was how it was supposed > to work. It was tested, there were some issues, it was thought they were relatively easily resolved, that turned out not to be the case. I get put under immense pressure to merge patches 'yesterday'. Please keep this kind of issue in mind next time you ask me to hurry up and merge something ;-). We've been able to catch a lot of things but its the ones that slip through that people notice :/. Cheers, Richard
Op 22 feb. 2012, om 00:01 heeft Richard Purdie het volgende geschreven: > On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote: >> Indeed! I gave up on trying to determine an exhaustive list and just >> blew away tmp and sstate and rebuilt everything -- including package >> repositories :-( >> >> We need to find a way to prevent or warn of disruptive changes like >> this zlib patch. For those of us trying to make a living using Yocto, >> losing a day of productivity to things like this really stings. > > I agree this change sucked and showed us we have some real issues. I > will point out that if we had been using the basichash signature > generator, it would likely have picked up this change and rebuild all > the appropriate pieces. Rebuild yes, but not fix all the -dev packages in the feeds. regards, Koen
On Wed, 2012-02-22 at 09:03 +0100, Koen Kooi wrote: > Op 22 feb. 2012, om 00:01 heeft Richard Purdie het volgende geschreven: > > > On Mon, 2012-02-13 at 05:23 -0800, Steve Sakoman wrote: > >> Indeed! I gave up on trying to determine an exhaustive list and just > >> blew away tmp and sstate and rebuilt everything -- including package > >> repositories :-( > >> > >> We need to find a way to prevent or warn of disruptive changes like > >> this zlib patch. For those of us trying to make a living using Yocto, > >> losing a day of productivity to things like this really stings. > > > > I agree this change sucked and showed us we have some real issues. I > > will point out that if we had been using the basichash signature > > generator, it would likely have picked up this change and rebuild all > > the appropriate pieces. > > Rebuild yes, but not fix all the -dev packages in the feeds. The PR service using the hash changes would have allowed that though... Cheers, Richard
Patch
diff --git a/meta/recipes-core/zlib/files/Makefile.am b/meta/recipes-core/zlib/files/Makefile.am deleted file mode 100644 index b66d299..0000000 --- a/meta/recipes-core/zlib/files/Makefile.am +++ /dev/null @@ -1,9 +0,0 @@ -lib_LTLIBRARIES = libz.la - -libz_la_SOURCES = adler32.c compress.c crc32.c gzlib.c gzclose.c gzread.c \ - gzwrite.c uncompr.c deflate.c trees.c zutil.c inflate.c \ - infback.c inftrees.c inffast.c - -libz_la_LDFLAGS = -version-number 1:2:5 --version-script zlib.map - -include_HEADERS = zconf.h zlib.h zlibdefs.h diff --git a/meta/recipes-core/zlib/files/configure.ac b/meta/recipes-core/zlib/files/configure.ac deleted file mode 100644 index 4761b7e..0000000 --- a/meta/recipes-core/zlib/files/configure.ac +++ /dev/null @@ -1,48 +0,0 @@ -AC_INIT(zlib,1.2.5) -AC_CONFIG_SRCDIR(adler32.c) -AM_INIT_AUTOMAKE(zlibs,1.2.5) - -AC_PREREQ([2.59]) - -AC_PROG_CC([gcc]) -AC_PROG_LIBTOOL - -AC_HEADER_STDC - -zlib_save_CPPFLAGS=$CPPFLAGS -CPPFLAGS="$CPPFLAGS -D_LARGEFILE64_SOURCE" -AC_CHECK_TYPES(off64_t) -CPPFLAGS=$zlib_save_CPPFLAGS - -AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], [zlib_cv_use_lfs64], [ - zlib_cv_use_lfs64=no - if test "$ac_cv_type_off64_t" = "yes"; then - zlib_cv_use_lfs64=yes - fi -]) - -if test "$zlib_cv_use_lfs64" = "yes"; then - CPPFLAGS="$CPPFLAGS -D_LARGEFILE64_SOURCE" - - #APR_ADDTO(CPPFLAGS, [-D_LARGEFILE64_SOURCE]) -fi - -cat > zlibdefs.h << EOF -/* zlibdefs.h -- compile-time definitions for the zlib compression library - * Copyright (C) 1995-2006 Jean-loup Gailly. - * For conditions of distribution and use, see copyright notice in zlib.h - */ - -#include <sys/types.h> /* for off_t */ -#include <unistd.h> /* for SEEK_* and off_t */ -#ifdef VMS -# include <unixio.h> /* for off_t */ -#endif -#ifndef z_off_t -# define z_off_t off_t -#endif -EOF - -AC_CONFIG_FILES([Makefile]) - -AC_OUTPUT diff --git a/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch b/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch deleted file mode 100644 index 038c1a2..0000000 --- a/meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch +++ /dev/null @@ -1,20 +0,0 @@ -Upstream-Status: Pending - -see -https://bugs.gentoo.org/316377?id=316377 -https://bugs.freedesktop.org/show_bug.cgi?id=33710 -http://lists.freedesktop.org/archives/poppler-bugs/2011-January/006014.html -for details - -diff -up zlib-1.2.5/zlib.h.pom zlib-1.2.5/zlib.h ---- zlib-1.2.5/zlib.h.pom 2010-04-20 06:12:48.000000000 +0200 -+++ zlib-1.2.5/zlib.h 2010-06-16 13:08:59.000000000 +0200 -@@ -1578,7 +1578,7 @@ ZEXTERN int ZEXPORT inflateBackInit_ OF( - # define gzoffset gzoffset64 - # define adler32_combine adler32_combine64 - # define crc32_combine crc32_combine64 --# ifdef _LARGEFILE64_SOURCE -+# ifndef _LARGEFILE64_SOURCE - ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); - ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int)); - ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile)); diff --git a/meta/recipes-core/zlib/zlib_1.2.5.bb b/meta/recipes-core/zlib/zlib_1.2.5.bb deleted file mode 100644 index b5756d9..0000000 --- a/meta/recipes-core/zlib/zlib_1.2.5.bb +++ /dev/null @@ -1,41 +0,0 @@ -SUMMARY = "Zlib Compression Library" -DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data compression \ -library which is used by many different programs." -HOMEPAGE = "http://zlib.net/" -SECTION = "libs" -LICENSE = "Zlib" -LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=084e9c30e4e6272c3b057b13c6467f3d" - -DEPENDS = "libtool-cross" -PR = "r3" - -SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \ - file://configure.ac \ - file://Makefile.am \ - file://fix.inverted.LFS.logic.patch" - -SRC_URI[md5sum] = "be1e89810e66150f5b0327984d8625a0" -SRC_URI[sha256sum] = "239aead2f22f16bfcfa6a6a5150dcbd6d6f2e4d1eaa8727b5769ea014120b307" - -inherit autotools - -do_configure_prepend () { - cp ${WORKDIR}/configure.ac ${S}/ - cp ${WORKDIR}/Makefile.am ${S}/ -} - -do_install_append () { - sed \ - -e 's:@prefix@:${prefix}:' \ - -e 's:@exec_prefix@:${exec_prefix}:' \ - -e 's:@libdir@:${libdir}:' \ - -e 's:@sharedlibdir@:${libdir}:' \ - -e 's:@includedir@:${includedir}:' \ - -e 's:@VERSION@:${PV}:' \ - zlib.pc.in > zlib.pc - - install -d ${D}${libdir}/pkgconfig - install -m 0644 zlib.pc ${D}${libdir}/pkgconfig/ -} - -BBCLASSEXTEND = "native nativesdk" diff --git a/meta/recipes-core/zlib/zlib_1.2.6.bb b/meta/recipes-core/zlib/zlib_1.2.6.bb new file mode 100644 index 0000000..a220773 --- /dev/null +++ b/meta/recipes-core/zlib/zlib_1.2.6.bb @@ -0,0 +1,26 @@ +SUMMARY = "Zlib Compression Library" +DESCRIPTION = "Zlib is a general-purpose, patent-free, lossless data compression \ +library which is used by many different programs." +HOMEPAGE = "http://zlib.net/" +SECTION = "libs" +LICENSE = "Zlib" +LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f3351471727e66a9" + +SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \ + " +SRC_URI[md5sum] = "dc2cfa0d2313ca77224b4d932b2911e9" +SRC_URI[sha256sum] = "fa3e3e4881fa5810b8903f2c7e0dcd5a0a673535f0438021c4bbb5db1b918c8e" + +do_configure (){ + ./configure --prefix=${prefix} --shared --libdir=${libdir} +} + +do_compile (){ + oe_runmake +} + +do_install() { + oe_runmake DESTDIR=${D} install +} + +BBCLASSEXTEND = "native nativesdk"
Dont use autotools, it really not so autoconf like. the configure script gets updated with every release of zlib and we overwrite that. Instead use the upstream provided configure copyright year was changed in zlib.h which caused change in LIC_FILE_CHECKSUM fix.inverted.LFS.logic.patch is already applied upstream so drop it Drop the configure.ac and Makefile.am scripts since we do not autoreconf anymore and do not inherit autotools anymore Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-core/zlib/files/Makefile.am | 9 ---- meta/recipes-core/zlib/files/configure.ac | 48 -------------------- .../zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch | 20 -------- meta/recipes-core/zlib/zlib_1.2.5.bb | 41 ----------------- meta/recipes-core/zlib/zlib_1.2.6.bb | 26 +++++++++++ 5 files changed, 26 insertions(+), 118 deletions(-) delete mode 100644 meta/recipes-core/zlib/files/Makefile.am delete mode 100644 meta/recipes-core/zlib/files/configure.ac delete mode 100644 meta/recipes-core/zlib/zlib-1.2.5/fix.inverted.LFS.logic.patch delete mode 100644 meta/recipes-core/zlib/zlib_1.2.5.bb create mode 100644 meta/recipes-core/zlib/zlib_1.2.6.bb