On (11/03/11 23:34), Eric Bénard wrote:
> Signed-off-by: Eric Bénard <[email protected]>

Acked-by: Khem Raj <[email protected]>

> ---
>  recipes/libpcre/libpcre-native_8.10.bb |   19 +++++++++++
>  recipes/libpcre/libpcre_8.10.bb        |   52 
> ++++++++++++++++++++++++++++++++
>  2 files changed, 71 insertions(+), 0 deletions(-)
>  create mode 100644 recipes/libpcre/libpcre-native_8.10.bb
>  create mode 100644 recipes/libpcre/libpcre_8.10.bb
> 
> diff --git a/recipes/libpcre/libpcre-native_8.10.bb 
> b/recipes/libpcre/libpcre-native_8.10.bb
> new file mode 100644
> index 0000000..9e5c62b
> --- /dev/null
> +++ b/recipes/libpcre/libpcre-native_8.10.bb
> @@ -0,0 +1,19 @@
> +SECTION = "unknown"
> +require libpcre_${PV}.bb
> +inherit native
> +FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/libpcre-${PV}"
> +
> +# NOTE: multiple providers are available (libpcre, libpcre-native);
> +# NOTE: consider defining PREFERRED_PROVIDER_pcre
> +PROVIDES = ""
> +
> +do_compile () {
> +     # The generation of dftables can lead to timestamp problems with ccache
> +     # because the generated config.h seems newer.  It is sufficient to 
> ensure that the
> +     # attempt to build dftables inside make will actually work 
> (foo_FOR_BUILD is
> +     # only used for this).
> +     oe_runmake CC_FOR_BUILD="${BUILD_CC}" CFLAGS_FOR_BUILD="-DLINK_SIZE=2 
> -I${S}/include" LINK_FOR_BUILD="${BUILD_CC}"
> +}
> +
> +SRC_URI[md5sum] = "780867a700e9d4e4b9cb47aa5453e4b2"
> +SRC_URI[sha256sum] = 
> "7ac4e016f6bad8c7d990e6de9bce58c04ff5dd8838be0c5ada0afad1d6a07480"
> diff --git a/recipes/libpcre/libpcre_8.10.bb b/recipes/libpcre/libpcre_8.10.bb
> new file mode 100644
> index 0000000..92a9d32
> --- /dev/null
> +++ b/recipes/libpcre/libpcre_8.10.bb
> @@ -0,0 +1,52 @@
> +DESCRIPTION = "Perl-compatible regular expression library. PCRE has its own 
> native \
> +API, but a set of 'wrapper' functions that are based on the POSIX API \
> +are also supplied in the library libpcreposix. Note that this just \
> +provides a POSIX calling interface to PCRE; the regular expressions \
> +themselves still follow Perl syntax and semantics. The header file for \
> +the POSIX-style functions is called pcreposix.h."
> +SECTION = "devel"
> +PR = "r0"
> +LICENSE = "BSD"
> +SRC_URI = "${SOURCEFORGE_MIRROR}/pcre/pcre-${PV}.tar.bz2 \
> +           file://pcre-cross.patch"
> +S = "${WORKDIR}/pcre-${PV}"
> +
> +PROVIDES = "pcre"
> +
> +inherit autotools binconfig
> +
> +PARALLEL_MAKE = ""
> +
> +CFLAGS_append = " -D_REENTRANT"
> +CXXFLAGS_powerpc += "-lstdc++"
> +EXTRA_OECONF = " --with-link-size=2 --enable-newline-is-lf 
> --with-match-limit=10000000 --enable-rebuild-chartables --enable-utf8"
> +
> +do_compile () {
> +     # stop libtool from trying to link with host libraries - fix from #33
> +     # this resolve build problem on amd64 - #1015
> +     if [ -e ${S}/${TARGET_SYS}-libtool ] ; then
> +             sed -i 's:-L\$:-L${STAGING_LIBDIR} -L\$:' 
> ${S}/${TARGET_SYS}-libtool
> +     else
> +             ln -sf ${S}/libtool ${S}/${TARGET_SYS}-libtool
> +             sed -i 's:-L\$:-L${STAGING_LIBDIR} -L\$:' 
> ${S}/${TARGET_SYS}-libtool    
> +     fi
> +
> +     # The generation of dftables can lead to timestamp problems with ccache
> +     # because the generated config.h seems newer.  It is sufficient to 
> ensure that the
> +     # attempt to build dftables inside make will actually work 
> (foo_FOR_BUILD is
> +     # only used for this).
> +     oe_runmake CC_FOR_BUILD="${BUILD_CC}" CFLAGS_FOR_BUILD="-DLINK_SIZE=2 
> -I${S}/include" LINK_FOR_BUILD="${BUILD_CC} -L${S}/lib"
> +}
> +
> +do_install_append () {
> +    install -d ${STAGING_BINDIR}
> +    install -m 0755 ${D}${bindir}/pcre-config ${STAGING_BINDIR}/
> +}
> +
> +FILES_${PN} = "${libdir}/lib*${SOLIBS}"
> +FILES_${PN}-dev += "${bindir}/*"
> +
> +LEAD_SONAME = "libpcre.so.*"
> +
> +SRC_URI[md5sum] = "780867a700e9d4e4b9cb47aa5453e4b2"
> +SRC_URI[sha256sum] = 
> "7ac4e016f6bad8c7d990e6de9bce58c04ff5dd8838be0c5ada0afad1d6a07480"
> -- 
> 1.7.0.4
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> [email protected]
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
-Khem

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Reply via email to