Closed ozzyyzzo4096 closed 5 years ago
Ok the problem with graphite has been solved by using : apt install libisl-0.18-dev
There is now a problem with fatal error: GLES2/gl2platform.h
i've tried to apt-get install libgles2-mesa-dev without success while rebuilding the toolchain.
Hmm, ok that's infortunate I was expecting libisl-dev to be installed by one of:
sudo apt-get build-dep $GCC_VERSION_PKG sudo apt-get build-dep --arch-only sdcc
Could you tell which distro you're using in WSL so I can try to replicate locally?
Also, the OpenGL setup is quite convoluted as the headers can be picked from many different places and I've tried to make it compatible with both OpenGL (regular desktop) and OpenGLES (raspberry). I don't remember out of the top of head whether WSL normally uses OpenGL or OpenGLES, but I do remember you're supposed to give ngdevkit the header files from GLEW.
Silly question, did you follow the steps in README-mingw.md, or did you run the stock make?
Hello , I'm using 'Debian GNU/Linux buster/sid' distro under WSL. Yes i've followed the steps from README-mingw.md So currently i'm just able to compile examples but without the GL2 header gngeo has not been built. I'm surprised that apt-get install libgles2-mesa-dev has not helped.
Ok looking into it, I'll report shortly :)
Indeed, Debian unstable now ships libisl-dev 0.20 as a build-dep of gcc:
$ apt-cache policy libisl-dev
libisl-dev:
Installed: 0.20-2
Candidate: 0.20-2
Version table:
*** 0.20-2 500
500 http://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status
Thanks for the tip of forcing a specific libisl version, I'll rework the README(s) to make it work for all debian derivatives.
I'm also rebuilding the devkit on Ubuntu Xenial to figure out what could differ w.r.t OpenGL, I'll keep you posted.
OK so the gngeo compilation failure is due to two unrelated things:
In gngeo's configure script, I made use of uname -p to distinguish between 32bits and 64bits Win platforms. It turns out this doesn't work with a recent Debian, so I fixed it in gngeo [1]
Unfortunately, recent versions of autoconf-archive have changed the way they autodetect OpenGL [2] as well as the variables they sets, so the configure scripts needs to be amended to work (stop relying on GL_LDFLAGS).
I'm testing a few things to fix the second bug and will update shortly.
EDIT: force-pushed the commit in [1] due to a bad commit log
[1] https://github.com/dciabrin/gngeo/commit/62494427cd0acc002fb58b2cac03f733ebc71e20 [2] https://github.com/autoconf-archive/autoconf-archive/commit/985e769cd7ad0c54d6adb5105b37b4ed724fa94a
Hey @ozzyyzzo4096
I updated the doc according to your previous comment regarding libisl 0.18. With the updated gngeo repo, this issue should be fixed now.
If you want to rebuild gngeo without recompiling the entire toolkit, you should be able to do so with:
rm -rf build/gngeo toolchain/gngeo
make -f Makefile.mingw download-emulator build-emudbg build-emulator build-emulator-config install-emulator-dll
make -f Makefile.mingw download-shaders
Hello,
First of all, nice piece of work for WSL support which now makes ngdevkit available for Windows users ;-) (for the moment i'm using Neodev but i really would like to switch to ngdevkit!)
While building the toolchain there are errors concerning 'graphite' ->![graphite-error](https://user-images.githubusercontent.com/12113109/50355201-89477a00-0556-11e9-8656-57775e088d1e.jpg)
More generally speaking now, what will be your advice concerning an active neogeo dev forum ? It will be nice to get in touch with some active coders to share knowledge and other stuff.. Maybe it would be a nice idea to set up one ?