-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libANGLE does not build on GCC 11 #214
Comments
Thanks for the details! A while back (late 2017), I took a stab at updating headless-gl's referenced version of libANGLE, but I didn't get very far as I had build tool problems as well as problems in passing the test suite. I'd love to try again, with a more recent patch of ANGLE, but I unfortunately don't have the time (or skill) to effectively tackle the problem myself. If you're willing, you can submit a patch, even if it's just to add the missing |
I upgraded dependencies on openSUSE Tumbleweed and also started getting build errors:
|
the workaround is:
|
@Rush Thanks for the extra detail and the workaround! |
That workaround, of course, depends on having GCC 10 installed. |
Don't we all depend on things being installed? ;) |
Yes, but depending on your distro, having multiple GCC versions installed can be troublesome. |
Cannot install gl at all, even with |
I ran into this issue trying to use gpu.js, which has headless-gl as a dependency. I made a modified version of libANGLE as well as a fork of headless-gl that points to my libANGLE as a git submodule. In my local headless-gl dev setup I'm able to get my fork to build just fine, but when I try to use my fork's git repo as a dependency i.e. using The relevant error seems to be:
Is there something else I need to do besides updating the submodule to get this to work? (Unfortunately, I'm unable to get the |
I also tried vendoring the libANGLE code into my fork of headless-gl, but that didn't work. But what did work was:
😄 |
I solved my issue when I was on Ubuntu 21.10 by running this command (may not work for everyone though): sudo apt install -y build-essential g++-10 libxi-dev libxext-dev libpixman-1-dev libcairo2-dev libpango1.0-dev libjpeg8-dev libgif-dev libjpeg-dev librsvg2-dev mesa-common-dev I also solved it on EndeavourOS but sadly my brain does not let me remember, I'll come back when I find out again |
I am now getting a different error message than previously noted in (gpujs/gpu.js#740)
|
Can someone please tell me what I need to understand that I don't... With my (broken) logic... this package is downloaded 22 515 per week as 61 packages depend on it, they have a CI toolchain doing some testing (I imagine) and some packages (including this one) have new releases in the last days or months... Why is it not working for me (and those above me who have commented on their problems) but not for anyone else... can someone explain to me what I need to understand to make it work ??? I hope I do not sound angry or sarcastic I am just asking questions (and trying to understand the irony of the situation)... EDITAfter thinking for myself I thought installing the GCC/G++ 10 could be an alternative but I am unable to find how... ❯ uname -a |
Their CI toolchain builds on Ubuntu 18.04, which is using an old enough GCC (and libstdc++, more importantly) version that the issue with the headers doesn't happen.
Most likely, most users of this package are using Node.js LTS versions (12, 14 or 16), for which prebuilt native libraries are provided by the project. So they don't end up compiling locally. |
Ho wow 🤩 thanks I hope it could be useful to me I will try this later. |
@Luxcium you may find better luck by running a versions of node that is LTS (or is destined to soon become LTS), for example even numbered versions (e.g. 12, 14, 16). These will have binaries prebuilt, so installation is smoother and quicker. Otherwise, the binary will have to be built from source each time you install, and the specifics of your environment (availability of certain build tools, locations of directories, headers, etc.) will determine if it builds or not. We can't test in every configuration, and have not found the right set of build tools to recommend that work across all variants of Linux. @qexat had some success on his Ubuntu install. Perhaps some of those packages/tools are available in your distribution's package installer. |
This information was new to me and I am going to take note of what you are telling me... Where should I have learned that before (other than in forums or issues)... I am just continually learning (who is not)... But it's a relief 😅😮💨 to know that... |
Yes, generally Node.js LTS versions tend to lead to fewer issues like this (although I would say you are unlikely to run into issues like this that often anyway).
Well, Node.js's download page does say this (note the "recommended for most users" under LTS), but (and forgive me for going on a tangent here) I feel like their versioning like this is a bit misleading, because if LTS is what is recommended, then that should be the stable version, and the "Current" version should be the Beta or next or whatever. (I'm sure they have their rationale for this current naming, so meh.)
To be honest, it should not be that tricky to have a reliable build; C/C++ dependency management is pretty standard nowadays on Linux systems, with pkg-config etc. And like I said in my original post, the issue in this case is an issue with upstream missing an Maybe I should just send in a patch to add the missing line. I had intended to find time to try to update libANGLE to a more recent version from upstream, but that doesn't seem like it will happen anytime soon... |
I am unsure about the "upstream" as I thought 💭 a fork was included in the project... how can I get unblocked say by installing myself a corrected version, since I am not fluent enough to send a PR to help everyone else I would be at least able to fix the problem for myself or anyone else who would be doing that same temporary workaround... |
There, I've made the PR on https://github.com/mikolalysenko/angle: mikolalysenko/angle#4. Not sure if @mikolalysenko is still active in this project though. @dhritzkiv, maybe it'll be better to make a fork of that repository in the stackgl organisation, and you can merge my commit over. Not sure. I'll leave that to you. |
@Luxcium good point about not being to find this information. I'll add it to the README later today |
@angelsl thanks for the patch. I think @mikolalysenko is not so active these days, but I can create a new repo and point this project at it. Creating a new fork will also make it just a little bit easier to update ANGLE (but as you mentioned, it's not super straightforward) I'll review your patch later today. W.r.t. node versions: we'd be more likely to support 'current' (non-LTS) node versions if we had more maintainers on the project. Right now, it's just me –even supporting only LTS versions is time consuming enough. P.S. thanks for answering @Luxcium's question earlier, a few minutes before I managed to. :) |
I also had some success on my EndeavourOS install, but as I said I forgot how I figured out to. Also, by the way, it's her* ^^ |
@qexat apologies! I didn't check your profile before posting and foolishly assumed |
I am unable to know how to do it by myself (I had forked Angle applied the PR forked this repo applied the submodule)... but I realize I do not know how to build ANGLE ...
|
@dhritzkiv Have you had a chance to look at the patch? |
Closed in v5.0.3 |
There is a missing
in libANGLE's
src/libANGLE/HandleAllocator.cpp
.Note that the upstream libANGLE does not have this issue because of
#include <mutex>
insrc/common/debug.h
, which indirectly includeslimits
. The (rather old) version of libANGLE used in this package does not have that.Not including
limits
directly is bad practice by upstream, but in any case, this package is broken.The text was updated successfully, but these errors were encountered: