Re: [yocto] Creating a new recipe
I made some further steps.
I attach the layer package that I am creating. You can add it to
conf/bblayers.conf.
The error that I the following. Let me know what you thing of it.
Thank you,
Giuseppe
$ bitbake bazel
Parsing recipes: 100%
|#|
Time: 0:00:32
Parsing of 1774 .bb files complete (0 cached, 1774 parsed). 2490 targets,
149 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal-4.8"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE = "zc702-zynq7"
DISTRO= "poky"
DISTRO_VERSION= "2.2.1"
TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard
cortexa9"
TARGET_FPU= "hard"
meta = "morty:924e576b8930fd2268d85f0b151e5f68a3c2afce"
meta-xilinx = "morty:1ddfc0ba94f597822e619395fa0b35fb322e26af"
meta-poky
meta-tensorflow = "morty:924e576b8930fd2268d85f0b151e5f68a3c2afce"
meta-xilinx-tools = "rel-v2017.1:64847a5afcffcb73e4bcf2137911819b55537308"
meta-yocto-bsp= "morty:924e576b8930fd2268d85f0b151e5f68a3c2afce"
meta-oe
meta-python = "morty:fe5c83312de11e80b85680ef237f8acb04b4b26e"
meta-java = "HEAD:67e48693501bddb80745b9735b7b3d4d28dce9a1"
workspace = ":"
Initialising tasks: 100%
|##|
Time: 0:00:01
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: bazel-0.4.5-r0 do_compile: Function failed: do_compile (log file is
located at
/home/giuseppe/research/projects/zynq/yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/bazel/0.4.5-r0/temp/log.do_compile.4221)
ERROR: Logfile of failure stored in:
/home/giuseppe/research/projects/zynq/yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/bazel/0.4.5-r0/temp/log.do_compile.4221
Log data follows:
| DEBUG: Executing shell function do_compile
| INFO: You can skip this first step by providing a path to the bazel
binary as second argument:
| INFO:./compile.sh compile /path/to/bazel
| � Building Bazel from scratch...
| � Building Bazel with Bazel.
| .WARNING: /tmp/bazel_tTNeGhsI/out/external/bazel_tools/WORKSPACE:1:
Workspace name in /tmp/bazel_tTNeGhsI/out/external/bazel_tools/WORKSPACE
(@io_bazel) does not match the name given in the repository's definition
(@bazel_tools); this will cause a build error in future versions.
| INFO: Loading package: src
| INFO: Loading package: @bazel_tools//tools/cpp
| INFO: Loading package: @local_config_xcode//
| ERROR: in target '//external:cc_toolchain': no such package
'@local_config_cc//': Traceback (most recent call last):
| File
"/tmp/bazel_tTNeGhsI/out/external/bazel_tools/tools/cpp/cc_configure.bzl",
line 684
| _find_cc(repository_ctx)
| File
"/tmp/bazel_tTNeGhsI/out/external/bazel_tools/tools/cpp/cc_configure.bzl",
line 398, in _find_cc
| repository_ctx.which(cc_name)
| Program argument of which() may not contains a / or a \
('arm-poky-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon
-mfloat-abi=hard -mcpu=cortex-a9
--sysroot=/home/giuseppe/research/projects/zynq/yocto/build/tmp/sysroots/zc702-zynq7'
given).
| INFO: Elapsed time: 1.004s
|
| ERROR: Could not build Bazel
| WARNING:
/home/giuseppe/research/projects/zynq/yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/bazel/0.4.5-r0/temp/run.do_compile.4221:1
exit 2 from 'bash ./compile.sh'
| ERROR: Function failed: do_compile (log file is located at
/home/giuseppe/research/projects/zynq/yocto/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/bazel/0.4.5-r0/temp/log.do_compile.4221)
ERROR: Task
(/home/giuseppe/research/projects/zynq/yocto/poky/meta-tensorflow/recipes/bazel/bazel_0.4.5.bb:do_compile)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 1370 tasks of which 1369 didn't need to be
rerun and 1 failed.
Summary: 1 task failed:
/home/giuseppe/research/projects/zynq/yocto/poky/meta-tensorflow/recipes/bazel/bazel_0.4.5.bb:
do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
On Fri, May 5, 2017 at 1:04 PM, Andrea Galbusera wrote:
> On Fri, May 5, 2017 at 4:40 PM, Giuseppe Di Guglielmo <
> giuseppe.diguglie...@gmail.com> wrote:
>
>> Hi all,
>> I am trying to create a new recipe for Bazel (from Google):
>> https://bazel.build/versions/master/docs/install-compile-source.html
>>
>> The standard compilation flow is relatively simple: "Unzip the archive
>> and call bash ./compile.sh; this will create a bazel binary in
>> output/bazel. This binary is self-contained, so it can be copied to a
>> directory on the PATH (such as /usr/local/
Re: [yocto] Creating a new recipe
On Fri, May 5, 2017 at 4:40 PM, Giuseppe Di Guglielmo < giuseppe.diguglie...@gmail.com> wrote: > Hi all, > I am trying to create a new recipe for Bazel (from Google): > https://bazel.build/versions/master/docs/install-compile-source.html > > The standard compilation flow is relatively simple: "Unzip the archive > and call bash ./compile.sh; this will create a bazel binary in > output/bazel. This binary is self-contained, so it can be copied to a > directory on the PATH (such as /usr/local/bin) or used in-place." > > I need some support on how to debug the recipe file that I attach. > > In do_compile(), I run bash ./compile.sh. This requires the JAVA_HOME > variable that I export hard-coded because at the moment I do not know how > to fetch that path in a recipe. At this point the compile.sh fails and I do > not know how to debug. Please, can you have a look at it and provide me > some comments? > How does it fail? What is the log from bitbake? Please also provide the layers configuration that bitbake shows. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Creating a new recipe
Hi all,
I am trying to create a new recipe for Bazel (from Google):
https://bazel.build/versions/master/docs/install-compile-source.html
The standard compilation flow is relatively simple: "Unzip the archive and
call bash ./compile.sh; this will create a bazel binary in output/bazel.
This binary is self-contained, so it can be copied to a directory on the
PATH (such as /usr/local/bin) or used in-place."
I need some support on how to debug the recipe file that I attach.
In do_compile(), I run bash ./compile.sh. This requires the JAVA_HOME
variable that I export hard-coded because at the moment I do not know how
to fetch that path in a recipe. At this point the compile.sh fails and I do
not know how to debug. Please, can you have a look at it and provide me
some comments?
do_compile () {
export
JAVA_HOME=/home/giuseppe/research/projects/zynq/yocto/build/tmp/work/zc702_zynq7-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs/usr/lib/jvm/openjdk-8
bash ./compile.sh
}
Giuseppe
bazel.bb
Description: Binary data
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Enabling tpm from meta-security for AGL
On Fri, May 5, 2017 at 9:13 AM, Patrick Ohly wrote:
> On Fri, 2017-05-05 at 08:45 -0400, Khem Raj wrote:
>> Set
>>
>> SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
>
> But that's just a workaround, right? Ideally the build rules of
> tpm2.0-tools should be fixed to not need that.
>
yes it can be solved in components own build system
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Enabling tpm from meta-security for AGL
On Fri, 2017-05-05 at 08:45 -0400, Khem Raj wrote:
> Set
>
> SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
But that's just a workaround, right? Ideally the build rules of
tpm2.0-tools should be fixed to not need that.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Enabling tpm from meta-security for AGL
On Fri, May 5, 2017 at 6:12 AM, Dominig Ar Foll
wrote:
> Hello,
>
> I am trying to enable tpm on an Intel target using yocto (morty) from
> meta-security
>
> When I activate the tpm-tools-2.0 feature in my configuration, I have
> a compilation error (see log bellow)
> Search for line:
> | /usr/src/debug/glibc/2.24-r0/git/csu/../sysdeps/x86_64/start.S:104:
> undefined reference to `main'
>
> Would someone knows what I could be missing?
Set
SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
>
> Regards
> --
> Dominig ar Foll
> Senior Software Architect
> Intel Open Source Technology Centre
>
> - log extract
>
> | x86_64-agl-linux-libtool: link: (cd "tcti/.libs" && rm -f
> "libtcti-device.so.0" && ln -s "libtcti-device.so.0.0.0"
> "libtcti-device.so.0")
> | x86_64-agl-linux-libtool: link: (cd "tcti/.libs" && rm -f
> "libtcti-device.so" && ln -s "libtcti-device.so.0.0.0"
> "libtcti-device.so")
> | x86_64-agl-linux-libtool: link: ( cd "tcti/.libs" && rm -f
> "libtcti-device.la" && ln -s "../libtcti-device.la"
> "libtcti-device.la" )
> | x86_64-agl-linux-libtool: link: x86_64-agl-linux-g++ -m64
> -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2
> --sysroot=/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64 -fPIC
> -DPIC -shared -nostd
> lib
> /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/Scrt1.o
> /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/crti.o
> /home/dominig/AGL/build/tmp/sysroots/intel-cor
> ei7-64/usr/lib/../lib/x86_64-agl-linux/6.2.0/crtbeginS.o
> tcti/.libs/tcti_libtcti_socket_la-platformcommand.o
> sysapi/sysapi_util/.libs/tcti_libtcti_socket_la-changeEndian.o
> tcti/.libs/tcti_libtcti_sock
> et_la-tcti_socket.o tcti/.libs/tcti_libtcti_socket_la-commonchecks.o
> common/.libs/tcti_libtcti_socket_la-sockets.o
> common/.libs/tcti_libtcti_socket_la-debug.o
> -L/home/dominig/AGL/build/tmp/sysroots/x
> 86_64-linux/usr/lib/x86_64-agl-linux/gcc/x86_64-agl-linux/6.2.0
> -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/lib/../lib
> -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/x
> 86_64-agl-linux/6.2.0
> -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/x86_64-agl-linux/6.2.0
> -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib
> -L/home/dominig/AGL/bui
> ld/tmp/sysroots/intel-corei7-64/lib
> -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib
> /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/libstdc++.so
> -lm /home/dominig/AGL/build/
> tmp/sysroots/intel-corei7-64/usr/lib/libssp_nonshared.a -lc -lgcc_s
> -lgcc
> /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/x86_64-agl-linux/6.2.0/crtendS.o
> /home/dominig/AGL/build/tm
> p/sysroots/intel-corei7-64/usr/lib/../lib/crtn.o -m64 -march=corei7
> -mtune=corei7 -mfpmath=sse -msse4.2
> --sysroot=/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64 -O2 -g
> -fstack-protector-strong -
> Wl,--no-undefined
> -Wl,--version-script=../TPM2.0-TSS/tcti/tcti_socket.map -Wl,-O1
> -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z
> -Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,libtcti
> -socket.so.0 -o tcti/.libs/libtcti-socket.so.0.0.0
> | /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/Scrt1.o:
> In function `_start':
> | /usr/src/debug/glibc/2.24-r0/git/csu/../sysdeps/x86_64/start.S:104:
> undefined reference to `main'
> |
> /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/libc_nonshared.a(elf-init.oS):
> In function `__libc_csu_init':
> | /usr/src/debug/glibc/2.24-r0/git/csu/elf-init.c:86: undefined
> reference to `__init_array_start'
> |
> /home/dominig/AGL/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-agl-linux/gcc/x86_64-agl-linux/6.2.0/ld:
> /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/libc_nonshared.a(elf-init.oS
> ): relocation R_X86_64_PC32 against undefined hidden symbol
> `__init_array_start' can not be used when making a shared object
> |
> /home/dominig/AGL/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-agl-linux/gcc/x86_64-agl-linux/6.2.0/ld:
> final link failed: Bad value
> | collect2: error: ld returned 1 exit status
> | Makefile:2696: recipe for target 'tcti/libtcti-socket.la' failed
> | make: *** [tcti/libtcti-socket.la] Error 1
> | make: *** Waiting for unfinished jobs
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Enabling tpm from meta-security for AGL
On Fri, 2017-05-05 at 12:12 +0200, Dominig Ar Foll wrote:
> Hello,
>
> I am trying to enable tpm on an Intel target using yocto (morty) from
> meta-security
>
> When I activate the tpm-tools-2.0 feature in my configuration, I have
> a compilation error (see log bellow)
> Search for line:
> | /usr/src/debug/glibc/2.24-r0/git/csu/../sysdeps/x86_64/start.S:104:
> undefined reference to `main'
g++ ends up trying to link an executable instead of a shared objection.
If I remember correctly, -fstack-protector-strong in CFLAGS causes that.
The order of parameters must be ${CFLAGS) $(LDFLAGS).
I've tried with meta-security master and it doesn't happen there, so
perhaps it was already fixed.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Enabling tpm from meta-security for AGL
Hello, I am trying to enable tpm on an Intel target using yocto (morty) from meta-security When I activate the tpm-tools-2.0 feature in my configuration, I have a compilation error (see log bellow) Search for line: | /usr/src/debug/glibc/2.24-r0/git/csu/../sysdeps/x86_64/start.S:104: undefined reference to `main' Would someone knows what I could be missing? Regards -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre - log extract | x86_64-agl-linux-libtool: link: (cd "tcti/.libs" && rm -f "libtcti-device.so.0" && ln -s "libtcti-device.so.0.0.0" "libtcti-device.so.0") | x86_64-agl-linux-libtool: link: (cd "tcti/.libs" && rm -f "libtcti-device.so" && ln -s "libtcti-device.so.0.0.0" "libtcti-device.so") | x86_64-agl-linux-libtool: link: ( cd "tcti/.libs" && rm -f "libtcti-device.la" && ln -s "../libtcti-device.la" "libtcti-device.la" ) | x86_64-agl-linux-libtool: link: x86_64-agl-linux-g++ -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64 -fPIC -DPIC -shared -nostd lib /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/Scrt1.o /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/crti.o /home/dominig/AGL/build/tmp/sysroots/intel-cor ei7-64/usr/lib/../lib/x86_64-agl-linux/6.2.0/crtbeginS.o tcti/.libs/tcti_libtcti_socket_la-platformcommand.o sysapi/sysapi_util/.libs/tcti_libtcti_socket_la-changeEndian.o tcti/.libs/tcti_libtcti_sock et_la-tcti_socket.o tcti/.libs/tcti_libtcti_socket_la-commonchecks.o common/.libs/tcti_libtcti_socket_la-sockets.o common/.libs/tcti_libtcti_socket_la-debug.o -L/home/dominig/AGL/build/tmp/sysroots/x 86_64-linux/usr/lib/x86_64-agl-linux/gcc/x86_64-agl-linux/6.2.0 -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/lib/../lib -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/x 86_64-agl-linux/6.2.0 -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/x86_64-agl-linux/6.2.0 -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib -L/home/dominig/AGL/bui ld/tmp/sysroots/intel-corei7-64/lib -L/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/libstdc++.so -lm /home/dominig/AGL/build/ tmp/sysroots/intel-corei7-64/usr/lib/libssp_nonshared.a -lc -lgcc_s -lgcc /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/x86_64-agl-linux/6.2.0/crtendS.o /home/dominig/AGL/build/tm p/sysroots/intel-corei7-64/usr/lib/../lib/crtn.o -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/home/dominig/AGL/build/tmp/sysroots/intel-corei7-64 -O2 -g -fstack-protector-strong - Wl,--no-undefined -Wl,--version-script=../TPM2.0-TSS/tcti/tcti_socket.map -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,libtcti -socket.so.0 -o tcti/.libs/libtcti-socket.so.0.0.0 | /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/../lib/Scrt1.o: In function `_start': | /usr/src/debug/glibc/2.24-r0/git/csu/../sysdeps/x86_64/start.S:104: undefined reference to `main' | /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init': | /usr/src/debug/glibc/2.24-r0/git/csu/elf-init.c:86: undefined reference to `__init_array_start' | /home/dominig/AGL/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-agl-linux/gcc/x86_64-agl-linux/6.2.0/ld: /home/dominig/AGL/build/tmp/sysroots/intel-corei7-64/usr/lib/libc_nonshared.a(elf-init.oS ): relocation R_X86_64_PC32 against undefined hidden symbol `__init_array_start' can not be used when making a shared object | /home/dominig/AGL/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-agl-linux/gcc/x86_64-agl-linux/6.2.0/ld: final link failed: Bad value | collect2: error: ld returned 1 exit status | Makefile:2696: recipe for target 'tcti/libtcti-socket.la' failed | make: *** [tcti/libtcti-socket.la] Error 1 | make: *** Waiting for unfinished jobs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Pre-compiling Python Byte Code
On 3 May 2017 at 19:50, Chris Trobridge wrote: > The following works, as it uses the native python3 compiled by bitbake but > it feels a little contrived. Is there a better way of specifying the > native python3 interpreter, or a better way of getting my python byte code > compiled prior to generating the packages? > > If you inherit python3native then "python3" will be the native python3. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Pre-compiling Python Byte Code
On 3 May 2017 at 21:50, Chris Trobridge wrote:
> To improve startup speed I have decided to pre-compile python3 byte code
in my bb recipe. This is done semi automatically with the rpm build for
Fedora but I've not found anything similar for Yocto.
>
> I initially tried to use compileall:
>
> python3 -m compileall ${D}/opt/test_app/python
>
> This almost worked but it uses the host python3 to failed with a slight
difference in magic.
>
> The following works, as it uses the native python3 compiled by bitbake
but it feels a little contrived. Is there a better way of specifying the
native python3 interpreter, or a better way of getting my python byte code
compiled prior to generating the packages?
>
> ${STAGING_BINDIR_NATIVE}/python3-native/python3 -m compileall
${D}/opt/test_app/python
Looks fine to me. I believe distutils/setuptools would do this for you
though.
Jussi
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
