still no luck
Was just about to turn in and thought of one thing… on a DO droplet if you’re using a 512M one you may (I stress may) be running out of memory - it’s a long shot/unlikely, but, it could give that error. Do you have swap space setup? Issue command;
At command prompt. It should output something like;
total used free shared buffers cached
Mem: 501780 470116 31664 308 22392 343488
-/+ buffers/cache: 104236 397544
Swap: 2097148 1116 2096032
If swap says 0 for total column then you don’t have any and may easily run out of physical memory during compiles - even at the early stages as it evaluates things. You can see in mine I have approx 2G swap configured.
If you don’t have swap the easiest way on a DO droplet is to run following commands;
fallocate -l 2G /swapfile
chmod 600 /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
echo 'vm.swappiness=10' >> /etc/sysctl.conf
echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.conf
Do NOT run this if you have swap already or are unsure.
First you will need 1GB of ram on your droplet to compile HiFi now unless you do the method @OmegaHeron shows to create the swap file.
Second of all I fixed this by just updating the Ubuntu 14.04 container I use with their QT compile. I will write a more detailed tutorial on it later but the basics of what I use is from: https://alphas.highfidelity.io/t/basic-outline-only-how-to-compile-hifi-in-ubuntu-14-04-again/9010
I use 14.04 LTS now because HiFi basically maintains what is needed for it to run under that version.
Well - here we go again. QT5Webchannel seems to have come on stage. Not seeing a candidate to offer that in the Ubuntu 15.10 QT packages.
Nor in Debian, even unstable branch (which is currently in sync with testing branch for Qt libs)
All the references (very few) I see to it speak of that as a windows only thing - but that could be wrong considering the limited info available about it.
Ok - so it’s not a linux only thing - it’s just not being made for any dpkg binary installers yet unless another PPA happens to hold it. Looks like luck on being able to do via packages for per-requisites is finally running out. Now to see if Ubuntu 16 anticipates adding this package.
Requirement for WebChannel removed in latest GIT push, but, I’m still investigating getting it in place for future - just in case.
That (removing it) was a temporary rollback as there was a missing referenced file that was creating a crash. It should actually be back by now.
As far as the OffscreenQmlSurface requiring 5.5.1, I don’t think the interface for the class has changed at all, so if you rolled that one file back to the version before it referenced prepareThread, it might compile under 5.4. However, 5.5 and 5.6 are definitely on the horizon for better support of UI elements inside the rendered environment and better support for customizing web requesting using Qt’s Chromium-based WebEngine component. Also likely to support migration to QJSEngine to replace the deprecated QScriptEngine.
I understand it must be frustrating to have the application racing ahead like this when it makes it difficult to build on Linux. The only consolation I can offer is that while we may not make it easy, we make it easier than everyone else.
I’ve grown tired of trying to do it with packages on Linux – something I’ve only stuck to as it’s easier to help others setup. So - I’m going to make my Docker based system use locally compiled QT5.5.1 with all its possible modules enabled, then once that’s done and Jenkins can happily compile again - I’ll make a second Docker container for running stack - using libraries compiled on build box to fill in gaps for QT as even Ubuntu 16 doesn’t seem to be moving to offer enough to catch up to HiFi.
While I generally agree with that - it would make it a hell of a lot easier if we didn’t have to have our only way knowing something is coming and be ready is to constantly watch every GIT push for possible changes.
Hopefully I can get this Docker system clean enough for lesser geeks to use and make this less a nightmare someday. I know it can work well - I’ve been running stack in a docker container for almost a year now and it’s pretty much easy mode to deploy. For instance - grab a digital ocean droplet, run a script to properly configure swap and install docker then one command to pull docker stack image and be happy. That will work on any 64 bit Linux OS machine with a kernel capable of running Docker - even back to Ubuntu 12.04 with some added help.
I’m happy to stay out of date, although I would go so far as to say Linux is probably more important than windows since more servers on the internet today run Linux (Ubuntu being the most popular flavor). As far as interface goes, most users will just download binaries.
Most of the new dependencies should only be in the client. Are you saying that the server projects are depending on QWebChannel?
No, I haven’t updated in a while because of this thread. Lol.
Yes. At least in so far as cmake defines it as a requirement - if there’s a cmake flag to tell it to continue on even if a dep is missing for pacakge_x I suppose one could pass that and try to see if assignment-client and domain-server compile, or, edit the cmake file to drop QTWebChannel for a test.
Can anyone of you give me an advice?
I’ve found an issue where a new dependency on QWebChannel was added to the script engine, and thus to the server code. I have a PR up that should fix it.
Just to be clear, and take into account this may be an obvious answer to some, but… QWebChannel will still block cmake due to missing dependency on QWebChannel, right?
Even if the unintentional dep on server building to QWebChannel is removed won’t we still fail running cmake before we can even get to make assignment-client or make domain-server?
It’s not a problem here as my auto-build box now is happy again with its self-compiled full QT5.5.1, but, I’m wondering if this blockage to others will continue.
Actually after reading what you said, @Jherico, for the 4th time, maybe you’re saying – for now – nothing will need QTWebChannel thus nullifying cmake issue. Apologies if that’s the case. Monday.
No, the UI library still depends on QWebChannel. However, if you wanted to do a server only build, you should be able to remove line
add_subdirectory(interface) from the top level CMakeLists.txt file to prevent it trying to build the non-server code.
Dec 19 2015 Ubuntu 14.04.3LTS cmake errors
Thanks - that muddies the process for lesser geeks, but, at least is a workaround for now. Maybe, someday, it would make sense to have a server only cmake mechanism? I’m concerned that establishing procedure to manually remove that dep will come back to haunt should server side start to actually need it in future.
Debian Unstable just took delivery of 5.6.0.
Accepted qtbase-opensource-src 5.6.0~beta+dfsg-1 (source) into experimental
Will look into installing and seeing how a compile goes in a while.