hanni76 Posted May 26, 2017 Posted May 26, 2017 Hello guys, I tried to build v3.* starting from here https://github.com/armbian/build, my build environment is Hiper-V & Ubuntu 16.04 x64. I have chosen OrangePi One board to build u-boot & kernel of v3.* but got issue with compiling kernel. Looking into log & scripts I found the compiler version assigned for kernel is > 6.x but looks like the code base (or whatever) is not ready for this high version. Logs attached. Can you help, please ? Thank you logs-26_05_2017-14_26_00.tgz
zador.blood.stained Posted May 26, 2017 Posted May 26, 2017 3 minutes ago, ssuloev said: I tried to build v3.* starting from here https://github.com/armbian/build, my build environment is Hiper-V & Ubuntu 16.04 x64. Doesn't match the logs: Displaying message: Build host OS release yakkety info Displaying message: Host system support was not tested yakkety wrn Displaying message: Please don't ask for support if anything doesn't work Yakkety is Ubuntu 16.10, not 16.04
hanni76 Posted May 26, 2017 Author Posted May 26, 2017 Thank you for reply. But this is an error in build script. How does host OS matter here ? Regards
zador.blood.stained Posted May 26, 2017 Posted May 26, 2017 Just now, ssuloev said: But this is an error in build script. No. Build script documentation and README clearly says that the only supported OS release is Ubuntu 16.04 LTS (x64). 1 minute ago, ssuloev said: How does host OS matter here ? Relying on default compiler versions where it is possible. 5.3.1/5.4.0 on ubuntu 16.04 is perfectly suitable for compiling some kernels and we don't have resources to test every pissible kernel and compiler combination, so we are relying on a tested build environment.
hanni76 Posted May 26, 2017 Author Posted May 26, 2017 But I got 99% feeling that is not an OS-issue... Can you help me find where the compiler version for kernel is specified (maybe config file or whatever)? Sorry, I am new to this. Thanks
Igor Posted May 26, 2017 Posted May 26, 2017 4 minutes ago, ssuloev said: But I got 99% feeling that is not an OS-issue... We are 100% where is the problem. 5 minutes ago, ssuloev said: I am new to this. We do this every day for past few years.
hanni76 Posted May 26, 2017 Author Posted May 26, 2017 Thanks, Igor, for the reply. Sorry for bothering again, but how can you explain that I can successfully build kernel/u-boot for v.4.* on the same machine ? I.e.the issue is related to configuration IMHO. Regards.
zador.blood.stained Posted May 26, 2017 Posted May 26, 2017 8 minutes ago, ssuloev said: Can you help me find where the compiler version for kernel is specified (maybe config file or whatever)? config/sources/sun8i.conf Since KERNEL_USE_GCC is not specified there for the "default" branch, system default toochain (arm-linux-gnueabihf- ) is used. As I said, Ubuntu 16.04.x has arm-linux-gnueabihf-gcc 5.4.0 which is perfectly suitabe for this kernel.
zador.blood.stained Posted May 26, 2017 Posted May 26, 2017 1 minute ago, ssuloev said: Sorry for bothering again, but how can you explain that I can successfully build kernel/u-boot for v.4.* on the same machine ? Older u-boots and kernels usually fail to compile with newer GCC versions. 2 minutes ago, ssuloev said: I.e.the issue is related to configuration IMHO. As I said, default configuration targets Ubuntu 16.04 and it works there, so I can't call this an issue.
tkaiser Posted May 26, 2017 Posted May 26, 2017 46 minutes ago, ssuloev said: my build environment is Hiper-V & Ubuntu 16.04 x64 You might try it now again.
hanni76 Posted May 26, 2017 Author Posted May 26, 2017 LOL thank you for not allowing compilation at all
hanni76 Posted May 26, 2017 Author Posted May 26, 2017 Thank you guys for the answers, now I know the reason and how to tweak the things I need.
tkaiser Posted May 26, 2017 Posted May 26, 2017 14 minutes ago, ssuloev said: thank you for not allowing compilation at all IMO the only way to deal with situations like this (Armbian developers not developing anything useful any more since only being trapped in unnecessary first level support situations). Documentation mentions that only 16.04 is supported build environment (14.04 was ok for kernel only compilation but that has been removed now too). You use 16.10, get a warning that 16.10 isn't supported, ignore this warning (you had to press [enter] to confirm what you do), fail as expected and ask for support (you confirmed before to not do this) now telling us you would use 16.04. Since 16.04 is the supported environment Armbian developers try to solve the problem (hunt for a bug) and look into your logs just to realize that your claim to use 16.04 doesn't match reality And then they also waste their time to explain why our recommendations are not written just for fun but to guide developers and trying to save both external devs as well as Armbian core team members from wasting their time on well known issues @Igor and @zador.blood.stained: what about immediately trashing the .wip files for crapboards now to focus back on important stuff? 1
zador.blood.stained Posted May 26, 2017 Posted May 26, 2017 17 minutes ago, tkaiser said: @Igor and @zador.blood.stained: what about immediately trashing the .wip files for crapboards now to focus back on important stuff? We may still want those to be accessible for internal testing purposes, so hiding "Show WIP" button (unless, for example, EXPERT=yes hidden option is supplied) may be a better solution 2
martinayotte Posted May 26, 2017 Posted May 26, 2017 Yes, Zador is right ! We shouldn't "trash" the WIPs, but simply hide them and make them visible with EXPERT=yes. Otherwise, it will be a pain even for experts ... 1
tkaiser Posted May 26, 2017 Posted May 26, 2017 [x] done. @ssuloev: BTW: I didn't want to be offensive above. Just give the other devs the idea that 'trying to be friendly/polite' is sometimes wrong. Overreading/ignoring warnings is just human (even providing partially wrong information when requesting support) and if recommendations turn into requirements (as it's the case with 'Ubuntu 16.04 only' now) then we should switch warnings into errors too. Saves everyone time and hassles. And also we should rethink answering questions in the forums. Now we have an infrastructure where commits below https://github.com/armbian/documentation almost immediately show up on https://docs.armbian.com. So when questions arise we should think twice about why (eg. 'why 16.04?' Nowhere answered below docs.armbian.com but multiple times in the forum) and then prefer to commit an unstructured entry to a yet not existing developer and user FAQ, wait until it shows up over at docs.armbian.com and then post a link to it? 1
hanni76 Posted May 26, 2017 Author Posted May 26, 2017 3 minutes ago, tkaiser said: BTW: I didn't want to be offensive above It is all fine, I agree with you in general. I am not going to argue with you but here is just a small remark: for this particular issue I wouldn't disallow compilation but I would spend a very little time to make the whole thing compilable on all ubuntu flavours because it is only a matter of configuration and the build process does not depend on host OS features.
tkaiser Posted May 26, 2017 Posted May 26, 2017 7 minutes ago, ssuloev said: I would spend a very little time to make the whole thing compilable on all ubuntu flavours I highly appreciate you doing this and I'll also invite you to become moderator of 'Random Ubuntu flavours as build system chaos' subforum. You should keep in mind that you'll soon deal with important questions like 'Why is Linux Mint not supported?! It's based on Ubuntu!!' and 'What about Bash environement for windows 10 with xenial distribution' and other ways to deal with everything that smells like Ubuntu. Of course you should first test through all 22 linux families currently supported with all kernel and u-boot variants (that's the funny thing with that: we have some combinations where u-boot needs GCC below 5.4 in 32-bit while the kernel only compiles with 64-bit GCC 6.1 or above). Of course you also need all boards to test through (maybe a Kickstarter? The few hundred bucks for the hardware aren't the problem but your new full-time job will be) Maybe that's already enough to understand that this 'very little time' is better spent on real improvements? Besides that we recommend a virtualized environment for OS images for a single reason (not mentionend anywhere yet except forum): If there's ever just a little error when dealing with image creation (happens as root using dd and trying to overwrite sectors of the image) the build system can overwrite your whole OS or at least renders it unbootable! The main reason people like to use something else than Ubuntu 16.04 is that they already run something else that's Ubuntu-ish. And that's bad and should be avoided. So forcing users to setup an own virtual machine wit 16.04 is already fighting lazyness and preventing a mess if something ever goes wrong. 1
pfeerick Posted May 27, 2017 Posted May 27, 2017 Oh my... you should make a mod of the 'Random Ubuntu flavours as build system chaos' sub-forum as well... at least I can guarantee zero results as I'll do absolutely nothing but say "Use 16.04... the Armbian devs chose to base off a LTS build for a reason". You foolish devs... what will you require next... that all 'aspiring devs' should actually compile stuff on an actual computer instead of one drawn on paper? :-P And why for the love of god is Windows Subsystem for Linux not supported... I mean... what can go wrong? A crappy linux emulation running inside a crappy microshaft os? They've only just recently added support for mounting external drives in the linux subsystem... what's not to love hate? Right... even I've wandered in and said something... someone should lock this thread soon before this gets absolutely loopey and bat-shit crazy. Hell, I can't get ayufan's jenkins/docker builds to work for the pinebook images, but at least I didn't turn around and say "thou must make it work for me because it can't be a PBKAC"... I've kept fiddling, and will be contritely asking soon "wtf am I doing wrong here". I haven't tried the armbian build system yet, but I'm sure I can screw even it up somehow... but I'll at least read the warnings and follow them!
elegant.sand8729 Posted May 27, 2017 Posted May 27, 2017 FYI WSL can't be supported because you can't install the armhf qemu tools. https://github.com/Microsoft/BashOnWindows/issues/2103
pfeerick Posted May 28, 2017 Posted May 28, 2017 @AdFad666lol.... why doesn't that surprise me? WSL is a toy at best at the moment... it's fun to play with, but is missing too much stuff for usage. VirtualBox + Ubuntu still trumps it for linux on windows that actually works! To the OP, in the spirit of helping you resolve your issues, I ask this: Have you tried ensuring that your hyper-v (hiper-v???) linux build environment is running 16.04. If not, please do so. To not do so will simply result in flame threads like these, because you didn't read the most basic requirement which is that the build environment must be ubuntu xenial / 16.04, due to compiler versions and known compatibility. Vagrant may also be another option for you... there is a Vagrant config file distributed with Armbian which works great on Linux (and even a readme guide you can follow) and I presume would work on Windows as well as Vagrant is available over there, and uses Virtualbox under the covers to provide the guest OS emulation. If you or anyone else reading this happens to use Vagrant on linux to simple provide a clean build environment, make sure you download the package files from their website, and not use the ones in the software repositories, as they are out of date, and the disk resize plugin won't be installed properly. I've also run Armbian image builds on my native Ubuntu 16.04, and didn't have any issues whatsoever there, so that does indeed work flawlessly. I tried systemd-nspawn, and IIRC it compiled kernel packages fine, but bugged out on trying to do a image build due to loopback device issues. And the workarounds don't seem to work any more, so I wouldn't recommend it. I was going to try docker, but didn't like the fact it resets the build environment back every time you shut it down, so I would have to fiddle with that further to see if I can get it to co-operate best.
elegant.sand8729 Posted May 28, 2017 Posted May 28, 2017 WSL really isn't a toy. It's already compatible enough for 90% of use cases. QEMU will work eventually. The biggest 'blocker' would be the inability to run linux services without bash open, but for tasks that involve direct interaction it's very good. We use it daily in our production environments without issue. Anyway, I'm out.
Recommended Posts