edison-fw / meta-intel-edison

Here is the meta-intel-edison that builds, tries to stay up to date. Master is based on Yocto Poky Gatesgarth LTS 5.10.yy vanilla kernels. It builds a 32bit kernel (Gatesgarth branch 64bit) with ACPI enabled and corresponding rootfs. Telegram group: https://t.me/IntelEdison Web-site:
https://edison-fw.github.io/meta-intel-edison/
MIT License
60 stars 38 forks source link

sumo branch build failure #56

Closed sjpeng closed 5 years ago

sjpeng commented 5 years ago

Build Configuration: BB_VERSION = "1.38.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "i686-poky-linux" MACHINE = "edison" DISTRO = "poky-edison" DISTRO_VERSION = "2.5.2" TUNE_FEATURES = "m32 corei7" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "sumo:623b77885051174d0e05198843e739110977bd18" meta-oe meta-python meta-networking = "sumo:8760facba1bceb299b3613b8955621ddaa3d4c3f" meta-intel = "sumo:90af97d23fb2a56187c2fe2a3f4f4190d7cc2605" meta-intel-edison-bsp meta-intel-edison-distro = "master:d0de39d612c6cb032f19acd3b89f2f4264c444b9" meta-acpi = "eds:477a31d2bad06de9c240753462695c46569cf162"

ERROR: Multiple versions of openssl are due to be built (/home/cloud/edison/out/linux64/poky/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb /home/cloud/edison/out/linux64/poky/meta/recipes-connectivity/openssl/openssl_1.0.2p.bb). Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION_openssl to select the correct version or don't depend on multiple versions.

Summary: There was 1 ERROR message shown, returning a non-zero exit code. Makefile:53: recipe for target 'edison-image' failed make: *** [edison-image] Error 1

htot commented 5 years ago

@sjpeng that is surprising. I never saw this one.And we actually do set PREFERRED_VERSION_openssl here: https://github.com/edison-fw/meta-intel-edison/blob/sumo32/meta-intel-edison-distro/conf/distro/poky-edison.conf.

Which branch did you checkout? (there is master, sumo32 and a sumo64-acpi)

sjpeng commented 5 years ago

@htot thank you for your fast reply, I'm using sumo32 branch.

htot commented 5 years ago

@sjpeng what steps did you follow? Have you seen this https://edison-fw.github.io/meta-intel-edison/2.0-Building-and-installing-the-image.html?

It seems like you are trying to build something that depends on openssl 1.0.2p. Did you add anything to the image https://github.com/edison-fw/meta-intel-edison/blob/sumo32/meta-intel-edison-distro/recipes-core/images/edison-image.bb?

sjpeng commented 5 years ago

@htot I'm reference from here: https://github.com/edison-fw/meta-intel-edison/blob/sumo32/README

In phase 2 (Get this layer), I have make sure checkout at sumo32 branch

htot commented 5 years ago

@sjpeng I can reproduce if I do new checkout of poky. Strange. Maybe due to change in poky/sumo.

Can you try this: in meta-intel-edison/meta-intel-edison-distro/conf/distro/poky-edison.conf remove the line: PREFERRED_VERSION_openssl ?= "1.1.0%"

sjpeng commented 5 years ago

@htot Yes, It's work when mark the line: PREFERRED_VERSION_openssl ?= "1.1.0%"

htot commented 5 years ago

@sjpeng are you able to successfully build the image? I would like to close this issue but I am experiencing build errors myself in:

It looks like sumo has been updated creating problems with gnulib and not all fixes have been up-streamed yet.

virtual:native:/home/ferry/Develop/tmp/out/linux64/poky/meta/recipes-devtools/bison/bison_3.0.4.bb:do_compile

| ../bison-3.0.4/lib/fseterr.c: In function 'fseterr':
| ../bison-3.0.4/lib/fseterr.c:77:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib."
| #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib."
| ^~~~~

/home/ferry/Develop/tmp/out/linux64/poky/meta/recipes-core/glibc/cross-localedef-native_2.27.bb:do_compile

| /home/ferry/Develop/tmp/out/linux64/build/tmp/hosttools/ld: argp-fmtstream.c:(.text+0x525): undefined reference to `_IO_fwide'
| /home/ferry/Develop/tmp/out/linux64/build/tmp/hosttools/ld: argp-help.o: in function `argp_failure':
| argp-help.c:(.text+0x20b3): undefined reference to `_IO_fwide'
| collect2: error: ld returned 1 exit status

virtual:native:/home/ferry/Develop/tmp/out/linux64/poky/meta/recipes-core/coreutils/coreutils_8.29.bb:do_compile

| ../coreutils-8.29/lib/freadseek.c: In function 'freadptrinc':
| ../coreutils-8.29/lib/freadseek.c:68:3: error: #error "Please port gnulib freadseek.c to your platform! Look at the definition of getc, getc_unlocked on your system, then report this to bug-gnulib."
| #error "Please port gnulib freadseek.c to your platform! Look at the definition of getc, getc_unlocked on your system, then report this to bug-gnulib."
| ^~~~~
sjpeng commented 5 years ago

@htot sure, I have successfully build the image

htot commented 5 years ago

@sjpeng I am guessing your host machine <> Ubuntu 18.10 and has another glibc then v2.28?

htot commented 5 years ago

@sjpeng I am on 18.10. It appears the build errors are cause by 18.10 using glibc v2.28. I have now created patches that solve the above build errors for 18.10. It would be very helpful if you could test to see if it still builds on your machine which presumably has a older version of glibc. I can imagine you don't want to wait hours for this to build from scratch. The quickest test would be:

If you could do this that would be great.

sjpeng commented 5 years ago

@htot Sorry, I am late in my rely. I'm build host machine is Ubuntu 16.04.

htot commented 5 years ago

@sjpeng it would be great to know if it build the current sumo32

sjpeng commented 5 years ago

@htot unfortunately build failed, If unmark PREFERRED_VERSION_openssl ?= "1.1.0%" the master branch has same as issue.

htot commented 5 years ago

With so my latest patches I mean. I force pushed so you might need to reset --hard against remote.

sjpeng commented 5 years ago

yes, I have do that.

https://imgur.com/a/YpoPI0w

htot commented 5 years ago

That would be 4b7e12986f31cf28336407eb251c228f4ad8f353

htot commented 5 years ago

Never mind, I just tested this on a xenial (16.04) container, I it builds just fine.

htot commented 5 years ago

Fix by PR #57