* [meta-oe][PATCH] llvm3.2: new recipe
@ 2013-06-02 9:33 Jonathan Liu
2013-06-02 9:55 ` Marcin Juszkiewicz
0 siblings, 1 reply; 9+ messages in thread
From: Jonathan Liu @ 2013-06-02 9:33 UTC (permalink / raw)
To: openembedded-devel
arm_fenv_uclibc.patch was copied from llvm2.9 recipe.
Signed-off-by: Jonathan Liu <net147@gmail.com>
---
.../llvm/llvm3.2/arm_fenv_uclibc.patch | 14 +++
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb | 116 +++++++++++++++++++++
2 files changed, 130 insertions(+)
create mode 100644 meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch
create mode 100644 meta-oe/recipes-core/llvm/llvm3.2_3.2.bb
diff --git a/meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch b/meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch
new file mode 100644
index 0000000..c3ae494
--- /dev/null
+++ b/meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch
@@ -0,0 +1,14 @@
+Index: llvm-2.9/include/llvm/Support/FEnv.h
+===================================================================
+--- llvm-2.9.orig/include/llvm/Support/FEnv.h 2010-11-29 20:44:50.000000000 +0100
++++ llvm-2.9/include/llvm/Support/FEnv.h 2011-11-18 18:42:22.580161297 +0100
+@@ -17,6 +17,9 @@
+
+ #include "llvm/Config/config.h"
+ #include <cerrno>
++
++#undef HAVE_FENV_H
++
+ #ifdef HAVE_FENV_H
+ #include <fenv.h>
+ #endif
diff --git a/meta-oe/recipes-core/llvm/llvm3.2_3.2.bb b/meta-oe/recipes-core/llvm/llvm3.2_3.2.bb
new file mode 100644
index 0000000..cfdc68c
--- /dev/null
+++ b/meta-oe/recipes-core/llvm/llvm3.2_3.2.bb
@@ -0,0 +1,116 @@
+DESCRIPTION = "The Low Level Virtual Machine"
+HOMEPAGE = "http://llvm.org"
+# 3-clause BSD-like
+LICENSE = "NCSA"
+LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=60fdd7739841f04a2ce2171a726be8f3"
+
+DEPENDS = "libffi llvm-common"
+
+SRC_URI = "http://llvm.org/releases/${PV}/llvm-${PV}.src.tar.gz"
+SRC_URI_append_libc-uclibc = " file://arm_fenv_uclibc.patch "
+
+SRC_URI[md5sum] = "71610289bbc819e3e15fdd562809a2d7"
+SRC_URI[sha256sum] = "125090c4d26740f1d5e9838477c931ed7d9ad70d599ba265f46f3a42cb066343"
+
+S = "${WORKDIR}/llvm-${PV}.src"
+
+inherit autotools perlnative pythonnative
+
+LLVM_ARCH = "${@get_llvm_arch(d)}"
+LLVM_BUILD_DIR = "${WORKDIR}/llvm-${PV}.build"
+LLVM_INSTALL_DIR = "${WORKDIR}/llvm-install"
+LLVM_RELEASE = "3.2"
+LLVM_DIR = "llvm${LLVM_RELEASE}"
+
+EXTRA_OECONF += "--disable-assertions \
+ --enable-debug-runtime \
+ --disable-expensive-checks \
+ --enable-bindings=none \
+ --enable-keep-symbols \
+ --enable-libffi \
+ --enable-optimized \
+ --enable-shared \
+ --enable-targets=${LLVM_ARCH}"
+EXTRA_OEMAKE += "REQUIRES_RTTI=1"
+FILES_${PN} = "${libdir}/lib*.so \
+ ${libdir}/${LLVM_DIR}/*"
+FILES_${PN}-dbg = "${bindir}/${LLVM_DIR}/.debug \
+ ${libdir}/${LLVM_DIR}/.debug \
+ ${libdir}/.debug \
+ /usr/src/debug"
+FILES_${PN}-dev = "${bindir}/${LLVM_DIR} \
+ ${includedir}/${LLVM_DIR} \
+ ${libdir}/${LLVM_DIR}/BugpointPasses.so \
+ ${libdir}/${LLVM_DIR}/LLVMHello.so"
+FILES_${PN}-static-dev = "${libdir}/${LLVM_DIR}/*.a"
+FILES_SOLIBSDEV = ""
+
+do_configure_prepend() {
+ # Remove RPATHs
+ sed -i 's:$(RPATH) -Wl,$(\(ToolDir\|LibDir\|ExmplDir\))::g' Makefile.rules
+
+ # Drop "svn" suffix from version string
+ sed -i 's/3\.2svn/3.2/g' configure
+
+ # Fix paths in llvm-config
+ sed -i "s|sys::path::parent_path(CurrentPath))|sys::path::parent_path(sys::path::parent_path(CurrentPath)))|g" tools/llvm-config/llvm-config.cpp
+ sed -i "s|/bin|/bin/${LLVM_DIR}|g" tools/llvm-config/llvm-config.cpp
+ sed -i "s|/include|/include/${LLVM_DIR}|g" tools/llvm-config/llvm-config.cpp
+ sed -i "s|/lib|/lib/${LLVM_DIR}|g" tools/llvm-config/llvm-config.cpp
+
+ # Fails to build unless using separate directory from source
+ mkdir -p ${LLVM_BUILD_DIR}
+ cd ${LLVM_BUILD_DIR}
+}
+
+do_compile() {
+ cd ${LLVM_BUILD_DIR}
+ oe_runmake CC=${BUILD_CC} CXX=${BUILD_CXX} cross-compile-build-tools
+ oe_runmake
+}
+
+do_install() {
+ cd ${LLVM_BUILD_DIR}
+ oe_runmake DESTDIR=${LLVM_INSTALL_DIR} install
+
+ mv ${LLVM_INSTALL_DIR}${bindir}/${HOST_SYS}-llvm-config-host ${LLVM_INSTALL_DIR}/llvm-config-host
+
+ install -d ${D}${bindir}/${LLVM_DIR}
+ mv ${LLVM_INSTALL_DIR}${bindir}/* ${D}${bindir}/${LLVM_DIR}/
+
+ install -d ${D}${includedir}/${LLVM_DIR}
+ mv ${LLVM_INSTALL_DIR}${includedir}/* ${D}${includedir}/${LLVM_DIR}/
+
+ install -d ${D}${libdir}/${LLVM_DIR}
+ mv ${LLVM_INSTALL_DIR}${libdir}/* ${D}${libdir}/${LLVM_DIR}/
+
+ install -d ${D}${docdir}/${LLVM_DIR}
+ mv ${LLVM_INSTALL_DIR}${prefix}/docs/llvm/* ${D}${docdir}/${LLVM_DIR}
+}
+
+SYSROOT_PREPROCESS_FUNCS += "llvm_sysroot_preprocess"
+
+llvm_sysroot_preprocess() {
+ install -d ${SYSROOT_DESTDIR}${bindir_crossscripts}
+ mv ${LLVM_INSTALL_DIR}/llvm-config-host ${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config${LLVM_RELEASE}
+}
+
+def get_llvm_arch(d):
+ import bb;
+
+ arch = bb.data.getVar('TARGET_ARCH', d, 1)
+
+ if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
+ arch = "x86"
+ elif arch == "x86_64":
+ arch = "x86_64"
+ elif arch == "arm":
+ arch = "arm"
+ elif arch == "mipsel" or arch == "mips":
+ arch = "mips"
+ elif arch == "powerpc" or arch == "powerpc64":
+ arch = "powerpc"
+ else:
+ bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
+
+ return arch
--
1.8.3
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [meta-oe][PATCH] llvm3.2: new recipe
2013-06-02 9:33 [meta-oe][PATCH] llvm3.2: new recipe Jonathan Liu
@ 2013-06-02 9:55 ` Marcin Juszkiewicz
2013-06-03 4:30 ` Jonathan Liu
2013-06-11 7:48 ` Khem Raj
0 siblings, 2 replies; 9+ messages in thread
From: Marcin Juszkiewicz @ 2013-06-02 9:55 UTC (permalink / raw)
To: openembedded-devel
W dniu 02.06.2013 11:33, Jonathan Liu pisze:
> +def get_llvm_arch(d):
> + import bb;
> +
> + arch = bb.data.getVar('TARGET_ARCH', d, 1)
> +
> + if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
> + arch = "x86"
> + elif arch == "x86_64":
> + arch = "x86_64"
> + elif arch == "arm":
> + arch = "arm"
> + elif arch == "mipsel" or arch == "mips":
> + arch = "mips"
> + elif arch == "powerpc" or arch == "powerpc64":
> + arch = "powerpc"
> + else:
> + bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
> +
> + return arch
Can we get rid of such blocks? They are worthless and only generate
extra support questions when OE newbies use OE with 'not supported'
architectures.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [meta-oe][PATCH] llvm3.2: new recipe
2013-06-02 9:55 ` Marcin Juszkiewicz
@ 2013-06-03 4:30 ` Jonathan Liu
2013-06-11 7:48 ` Khem Raj
1 sibling, 0 replies; 9+ messages in thread
From: Jonathan Liu @ 2013-06-03 4:30 UTC (permalink / raw)
To: openembedded-devel
On 2 June 2013 19:55, Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> wrote:
> W dniu 02.06.2013 11:33, Jonathan Liu pisze:
>> +def get_llvm_arch(d):
>> + import bb;
>> +
>> + arch = bb.data.getVar('TARGET_ARCH', d, 1)
>> +
>> + if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
>> + arch = "x86"
>> + elif arch == "x86_64":
>> + arch = "x86_64"
>> + elif arch == "arm":
>> + arch = "arm"
>> + elif arch == "mipsel" or arch == "mips":
>> + arch = "mips"
>> + elif arch == "powerpc" or arch == "powerpc64":
>> + arch = "powerpc"
>> + else:
>> + bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
>> +
>> + return arch
>
> Can we get rid of such blocks? They are worthless and only generate
> extra support questions when OE newbies use OE with 'not supported'
> architectures.
Done in v3 patch.
Regards,
Jonathan
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [meta-oe][PATCH] llvm3.2: new recipe
2013-06-02 9:55 ` Marcin Juszkiewicz
2013-06-03 4:30 ` Jonathan Liu
@ 2013-06-11 7:48 ` Khem Raj
2013-06-11 7:55 ` Marcin Juszkiewicz
1 sibling, 1 reply; 9+ messages in thread
From: Khem Raj @ 2013-06-11 7:48 UTC (permalink / raw)
To: openembeded-devel
On Sun, Jun 2, 2013 at 2:55 AM, Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> wrote:
> W dniu 02.06.2013 11:33, Jonathan Liu pisze:
>> +def get_llvm_arch(d):
>> + import bb;
>> +
>> + arch = bb.data.getVar('TARGET_ARCH', d, 1)
>> +
>> + if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
>> + arch = "x86"
>> + elif arch == "x86_64":
>> + arch = "x86_64"
>> + elif arch == "arm":
>> + arch = "arm"
>> + elif arch == "mipsel" or arch == "mips":
>> + arch = "mips"
>> + elif arch == "powerpc" or arch == "powerpc64":
>> + arch = "powerpc"
>> + else:
>> + bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
>> +
>> + return arch
>
> Can we get rid of such blocks? They are worthless and only generate
> extra support questions when OE newbies use OE with 'not supported'
> architectures.
why do you think they are worthless ? when they give good information
instead of failing to build
and then generating support question which need more work to come to
same conclusion
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [meta-oe][PATCH] llvm3.2: new recipe
2013-06-11 7:48 ` Khem Raj
@ 2013-06-11 7:55 ` Marcin Juszkiewicz
2013-06-11 8:03 ` Khem Raj
0 siblings, 1 reply; 9+ messages in thread
From: Marcin Juszkiewicz @ 2013-06-11 7:55 UTC (permalink / raw)
To: openembedded-devel
W dniu 11.06.2013 09:48, Khem Raj pisze:
> On Sun, Jun 2, 2013 at 2:55 AM, Marcin Juszkiewicz
> <marcin@juszkiewicz.com.pl> wrote:
>> W dniu 02.06.2013 11:33, Jonathan Liu pisze:
>>> +def get_llvm_arch(d):
>>> + import bb;
>>> +
>>> + arch = bb.data.getVar('TARGET_ARCH', d, 1)
>>> +
>>> + if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
>>> + arch = "x86"
>>> + elif arch == "x86_64":
>>> + arch = "x86_64"
>>> + elif arch == "arm":
>>> + arch = "arm"
>>> + elif arch == "mipsel" or arch == "mips":
>>> + arch = "mips"
>>> + elif arch == "powerpc" or arch == "powerpc64":
>>> + arch = "powerpc"
>>> + else:
>>> + bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
>>> +
>>> + return arch
>>
>> Can we get rid of such blocks? They are worthless and only generate
>> extra support questions when OE newbies use OE with 'not supported'
>> architectures.
> why do you think they are worthless ? when they give good information
> instead of failing to build and then generating support question
> which need more work to come to same conclusion
$ MACHINE=genericarmv8 bitbake nano
"llvm is not supported"
"openjdk is not supported"
"another-thing-you-do-not-care-for-this-build is not supported"
This is how your builds look for not supported architectures.
OE has COMPATIBLE_HOST variable which can be used by recipe maintainers
to mark which architectures are supported.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [meta-oe][PATCH] llvm3.2: new recipe
2013-06-11 7:55 ` Marcin Juszkiewicz
@ 2013-06-11 8:03 ` Khem Raj
2013-06-11 8:54 ` Marcin Juszkiewicz
0 siblings, 1 reply; 9+ messages in thread
From: Khem Raj @ 2013-06-11 8:03 UTC (permalink / raw)
To: openembeded-devel
On Tue, Jun 11, 2013 at 12:55 AM, Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> wrote:
> W dniu 11.06.2013 09:48, Khem Raj pisze:
>> On Sun, Jun 2, 2013 at 2:55 AM, Marcin Juszkiewicz
>> <marcin@juszkiewicz.com.pl> wrote:
>>> W dniu 02.06.2013 11:33, Jonathan Liu pisze:
>>>> +def get_llvm_arch(d):
>>>> + import bb;
>>>> +
>>>> + arch = bb.data.getVar('TARGET_ARCH', d, 1)
>>>> +
>>>> + if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
>>>> + arch = "x86"
>>>> + elif arch == "x86_64":
>>>> + arch = "x86_64"
>>>> + elif arch == "arm":
>>>> + arch = "arm"
>>>> + elif arch == "mipsel" or arch == "mips":
>>>> + arch = "mips"
>>>> + elif arch == "powerpc" or arch == "powerpc64":
>>>> + arch = "powerpc"
>>>> + else:
>>>> + bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
>>>> +
>>>> + return arch
>>>
>>> Can we get rid of such blocks? They are worthless and only generate
>>> extra support questions when OE newbies use OE with 'not supported'
>>> architectures.
>
>> why do you think they are worthless ? when they give good information
>> instead of failing to build and then generating support question
>> which need more work to come to same conclusion
>
> $ MACHINE=genericarmv8 bitbake nano
> "llvm is not supported"
> "openjdk is not supported"
> "another-thing-you-do-not-care-for-this-build is not supported"
>
it could be said if you do not care for such recipes then BBMASK them
and message
well may be it could be make bb.note instead of bb.warn to make it
more of FYI kind of thing
> This is how your builds look for not supported architectures.
>
> OE has COMPATIBLE_HOST variable which can be used by recipe maintainers
> to mark which architectures are supported.
in this case arch does not map to what OE's target arch is so you have
to do it twice if you want
to use COMPATIBLE_HOST
and suppose a non supported arch becomes supported you have to change
both places.
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [meta-oe][PATCH] llvm3.2: new recipe
2013-06-11 8:03 ` Khem Raj
@ 2013-06-11 8:54 ` Marcin Juszkiewicz
2013-06-11 9:07 ` Khem Raj
0 siblings, 1 reply; 9+ messages in thread
From: Marcin Juszkiewicz @ 2013-06-11 8:54 UTC (permalink / raw)
To: openembedded-devel
W dniu 11.06.2013 10:03, Khem Raj pisze:
> On Tue, Jun 11, 2013 at 12:55 AM, Marcin Juszkiewicz
>> W dniu 11.06.2013 09:48, Khem Raj pisze:
>>> why do you think they are worthless ? when they give good information
>>> instead of failing to build and then generating support question
>>> which need more work to come to same conclusion
>>
>> $ MACHINE=genericarmv8 bitbake nano
>> "llvm is not supported"
>> "openjdk is not supported"
>> "another-thing-you-do-not-care-for-this-build is not supported"
>
> it could be said if you do not care for such recipes then BBMASK them
> and message
> well may be it could be make bb.note instead of bb.warn to make it
> more of FYI kind of thing
"NOTE: llvm does not support aarch64 yet" looks better. But still is
worthless.
>> This is how your builds look for not supported architectures.
>>
>> OE has COMPATIBLE_HOST variable which can be used by recipe maintainers
>> to mark which architectures are supported.
> in this case arch does not map to what OE's target arch is so you have
> to do it twice if you want to use COMPATIBLE_HOST
It has 7 OE architectures: i.86, x86_64, arm, mips(el), powerpc(64)
which are then mapped into 5 llvm ones. Can be gathered into one
COMPATIBLE_HOST (copied from kexec-tools):
COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux)'
"mips.*" probably needs to be changed to "mips(el)?" to not cover mips64.
> and suppose a non supported arch becomes supported you have to change
> both places.
Once it gets supported you will need to add/edit recipe anyway.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [meta-oe][PATCH] llvm3.2: new recipe
2013-06-11 8:54 ` Marcin Juszkiewicz
@ 2013-06-11 9:07 ` Khem Raj
2013-06-11 9:10 ` Marcin Juszkiewicz
0 siblings, 1 reply; 9+ messages in thread
From: Khem Raj @ 2013-06-11 9:07 UTC (permalink / raw)
To: openembedded-devel
On Jun 11, 2013, at 1:54 AM, Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> wrote:
>> in this case arch does not map to what OE's target arch is so you have
>> to do it twice if you want to use COMPATIBLE_HOST
>
> It has 7 OE architectures: i.86, x86_64, arm, mips(el), powerpc(64)
> which are then mapped into 5 llvm ones. Can be gathered into one
> COMPATIBLE_HOST (copied from kexec-tools):
>
> COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux)'
>
> "mips.*" probably needs to be changed to "mips(el)?" to not cover mips64.
and how will you fold it into -DLLVM_TARGETS_TO_BUILD=<arch>
where arch is not same as OE's target arch so you need the mapping function
anyway was my point.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [meta-oe][PATCH] llvm3.2: new recipe
2013-06-11 9:07 ` Khem Raj
@ 2013-06-11 9:10 ` Marcin Juszkiewicz
0 siblings, 0 replies; 9+ messages in thread
From: Marcin Juszkiewicz @ 2013-06-11 9:10 UTC (permalink / raw)
To: openembedded-devel
W dniu 11.06.2013 11:07, Khem Raj pisze:
>
> On Jun 11, 2013, at 1:54 AM, Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> wrote:
>
>>> in this case arch does not map to what OE's target arch is so you have
>>> to do it twice if you want to use COMPATIBLE_HOST
>>
>> It has 7 OE architectures: i.86, x86_64, arm, mips(el), powerpc(64)
>> which are then mapped into 5 llvm ones. Can be gathered into one
>> COMPATIBLE_HOST (copied from kexec-tools):
>>
>> COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux)'
>>
>> "mips.*" probably needs to be changed to "mips(el)?" to not cover mips64.
>
> and how will you fold it into -DLLVM_TARGETS_TO_BUILD=<arch>
>
> where arch is not same as OE's target arch so you need the mapping function
> anyway was my point.
+def get_llvm_arch(d):
+ import bb;
+
+ arch = bb.data.getVar('TARGET_ARCH', d, 1)
+
+ if arch == "x86_64" or arch == "i486" or arch == "i586" or arch ==
"i686":
+ arch = "x86"
+ elif arch == "x86_64":
+ arch = "x86_64"
+ elif arch == "arm":
+ arch = "arm"
+ elif arch == "mipsel" or arch == "mips":
+ arch = "mips"
+ elif arch == "powerpc" or arch == "powerpc64":
+ arch = "powerpc"
+
+ return arch
And done. If you try to build recipe secured by COMPATIBLE_HOST for not
compatible architecture then you have to deal with effects.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-06-11 9:11 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-02 9:33 [meta-oe][PATCH] llvm3.2: new recipe Jonathan Liu
2013-06-02 9:55 ` Marcin Juszkiewicz
2013-06-03 4:30 ` Jonathan Liu
2013-06-11 7:48 ` Khem Raj
2013-06-11 7:55 ` Marcin Juszkiewicz
2013-06-11 8:03 ` Khem Raj
2013-06-11 8:54 ` Marcin Juszkiewicz
2013-06-11 9:07 ` Khem Raj
2013-06-11 9:10 ` Marcin Juszkiewicz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox