Can't install on Linux #297
Comments
|
|
|
|
|
I see, hopped that you might know something... I also have no idea, looks weird indeed, it's a newly installed OS, had no chance to pollute it with garbage yet. I have only gcc now. |
|
If you manage to reproduce this inside Dockers I'd be interested and will follow up (perhaps more likely in the new year). |
|
It seems like the issue is caused by gblic starting from 2.34 version, I can reproduce it in docker with ubuntu:impish-20211102 for example, but with ubuntu:hirsute-20211107 all works well. |
|
That's great info, thanks! Can you share the Docker file(s)? |
|
Sure, you can find them here: https://gist.github.com/maximzxc/c9666de324737b4e27d12dbe56ab6d71 hirsute uses glibc 2.33 by default |
|
Hey @maximzxc, Thanks again for the report and the reproduction example. It turns out the same issue shows up in upstream NetHack. Or at least it did, until commit NetHack/NetHack@1cb5dc0 in early January (I wonder if this is a coincidence; it probably is). At any rate, this should be fixed in #299. To test this, note that you'd have to change your Dockerfile slightly to use the local sources: FROM ubuntu:impish-20211102
ARG PYTHON_VERSION=3.8
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -yq \
bison \
build-essential \
cmake \
curl \
flex \
git \
libbz2-dev \
ninja-build \
wget
WORKDIR /opt/conda_setup
RUN curl -o miniconda.sh https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh && \
chmod +x miniconda.sh && \
./miniconda.sh -b -p /opt/conda && \
/opt/conda/bin/conda install -y python=$PYTHON_VERSION && \
/opt/conda/bin/conda clean -ya
ENV PATH /opt/conda/bin:$PATH
COPY . /opt/nle/
WORKDIR /opt/nle
RUN pip install . # NOTE CHANGE HERE.
WORKDIR /workspace
CMD ["/bin/bash"] |
NetHack was trying to suppress warn_unused_result in include/tradstdc.h, by defining warn_unused_result to an empty string. That began causing a build error in a system-supplied header file cdefs.h when using 20.10 ubuntu impish. Try skipping that in tradstdc.h for any linux, unless the NetHack build defines GCC_URWARN to force it into play.
|
Hey @heiner, Thank you for the fix! It builds well now, can't test anything yet because after the build I got a new error: But probably the initial issue can be marked as fixed now. And this new one I'll try to resolve on weekends. |
|
Hey @maximzxc, Thanks for the quick response. The issue you encounter here has to do with the |
There was an issue in which, during compilation, this would crop up:
```
In file included from /usr/include/features.h:490,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdio.h:27,
from ../include/global.h:9,
from ../include/config.h:588,
from monst.c:6:
/usr/include/sys/cdefs.h:405:73: error: macro "__has_attribute" requires an identifier
405 | #if __GNUC_PREREQ (3,4) || __glibc_has_attribute (__warn_unused_result__)
| ^
```
I should note that this is something that cropped up months ago; this fix was
cherry-picked onto the 3.6 branch back in 2022-01-23. But I've been at school
so eh.
So this is a long-noticed issue that I'm only just cherry picking in now.
https://nethack.org/v366/bugs.html tracks this under S366-2, and notes that the
issue was with glibc.
This was addressed in the 3.7 branch in Nethack/Nethack#1cb5dc0:
> Work around ubuntu 20.10 build issue
>
> NetHack was trying to suppress warn_unused_result
> in include/tradstdc.h, by defining warn_unused_result
> to an empty string. That began causing a build error
> in a system-supplied header file cdefs.h
> when using 20.10 ubuntu impish.
>
> Try skipping that in tradstdc.h for any linux, unless
> the NetHack build defines GCC_URWARN to force it into
> play.
It was cherry picked in Nethack/Nethack#4a3d466, the documentation was added in
Nethack/Nethack#1b7ad11 and NetHack/NetHack#59b117c.
Also, and this is how I ended up finding out what was going on,
facebookresearch/nle#297 reports just this issue. It's fixed by
facebookresearch/nle#299 by just straight up cherry picking in that commit.
Maybe I should watch that project more carefully to figure out what I should be
doing. Maybe I should have just built this on top of that already existing and
honestly probably better API...
I've had to change `mkpatch` to include `include/tradstdc.h`, where the change
is located. The change itself is quite trivial.
The Lisp version has also been bumped to 0.13.2. The earliest compatible
version is still 0.12.0.
What bothers me is that when the time comes to do work with 3.7 NetHack, I'll
need to take things out of `mkpatch`. Just a little icky, and something to
remember.
As an aside, I do vaguely remember quite a few things breaking at the time
though (I use Arch). So no, not a coincidence, glibc updates are funky.
There was an issue in which, during compilation, this would crop up:
```
In file included from /usr/include/features.h:490,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdio.h:27,
from ../include/global.h:9,
from ../include/config.h:588,
from monst.c:6:
/usr/include/sys/cdefs.h:405:73: error: macro "__has_attribute" requires an identifier
405 | #if __GNUC_PREREQ (3,4) || __glibc_has_attribute (__warn_unused_result__)
| ^
```
I should note that this is something that cropped up months ago; this fix was
cherry-picked onto the 3.6 branch back in 2022-01-23. But I've been at school
so eh.
So this is a long-noticed issue that I'm only just cherry picking in now.
https://nethack.org/v366/bugs.html tracks this under S366-2, and notes that the
issue was with glibc.
This was addressed in the 3.7 branch in NetHack/NetHack@1cb5dc0:
> Work around ubuntu 20.10 build issue
>
> NetHack was trying to suppress warn_unused_result
> in include/tradstdc.h, by defining warn_unused_result
> to an empty string. That began causing a build error
> in a system-supplied header file cdefs.h
> when using 20.10 ubuntu impish.
>
> Try skipping that in tradstdc.h for any linux, unless
> the NetHack build defines GCC_URWARN to force it into
> play.
It was cherry picked in NetHack/NetHack@4a3d466, the documentation was added in
NetHack/NetHack@1b7ad11 and NetHack/NetHack@59b117c.
Also, and this is how I ended up finding out what was going on,
facebookresearch/nle#297 reports just this issue. It's fixed by
facebookresearch/nle#299 by just straight up cherry picking in that commit.
Maybe I should watch that project more carefully to figure out what I should be
doing. Maybe I should have just built this on top of that already existing and
honestly probably better API...
I've had to change `mkpatch` to include `include/tradstdc.h`, where the change
is located. The change itself is quite trivial.
The Lisp version has also been bumped to 0.13.2. The earliest compatible
version is still 0.12.0.
What bothers me is that when the time comes to do work with 3.7 NetHack, I'll
need to take things out of `mkpatch`. Just a little icky, and something to
remember.
As an aside, I do vaguely remember quite a few things breaking at the time
though (I use Arch). So no, not a coincidence, glibc updates are funky.
I'm getting the following error on
pip install nleEnvironment:
The text was updated successfully, but these errors were encountered: