Skip to content
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

Problems with building( Cmake and Sdl2) #136

Open
mrhatkat opened this issue Jan 3, 2019 · 29 comments
Open

Problems with building( Cmake and Sdl2) #136

mrhatkat opened this issue Jan 3, 2019 · 29 comments

Comments

@mrhatkat
Copy link

mrhatkat commented Jan 3, 2019

Hi everyone,
I've been having problems with building the game engine. I tried following the steps on the wiki and the README but couldn't find the proper files like build.bat. I was able to get everything but sdl2 to work in cmake by adding the locations of the config.cmake for every library,but for some reason I can't get this approach to work for sdl2. I am on a windows machine running Windows 10 and had to install glew,zlib,boost,glm,and freetype2 to get this far. Is there an easier way to build this that I am missing or is something else wrong?

@Quaker762
Copy link
Member

Hi,

The README and wiki are horribly out of date, as I haven't worked on this in a while (though I have recently restarted to project in a modular form, called OpenHill that'll support both SH2 and SH3. The Engine's a shared library that can be used by either game for more common stuff like lighting, but I digress). It's currently a private repository, but I can make it public if you'd like to help work on it.

If you at #132, and look at the files changed, you should be able to get it to build on Windows. Both @z33ky and myself both developed this on Linux, so Windows was a bit of an afterthought.

Let me know if I you need anymore assistance.

Cheers,
Jesse

@mrhatkat
Copy link
Author

mrhatkat commented Jan 4, 2019

OpenHill sounds like an interesting project. I'd love to take a look at it and see if I can help out. I'm also going to try looking at #132. Thanks for the help!

@mrhatkat
Copy link
Author

mrhatkat commented Jan 6, 2019

Still no luck. I tried making the build.bat file from issue #132 and the sdl.cmake file,but I still ran into problems:

CMake Error at platform/win32/cmake/FindSDL2.cmake:188 (include):
include could not find load file:

C:/Users/Austin/Desktop/sh3/sh3redux/platform/win32/cmake/FindPackageHandleStandardArgs.cmake
Call Stack (most recent call first):
tests/CMakeLists.txt:7 (find_package)

Could NOT find SDL (missing: SDL_LIBRARY) (found version "2.0.9")

CMake Error at tests/CMakeLists.txt:15 (include_directories):
include_directories given empty-string as include directory.

CMake Error at tests/CMakeLists.txt:16 (include_directories):
include_directories given empty-string as include directory.

@z33ky
Copy link
Collaborator

z33ky commented Jan 6, 2019

Do you use a package-manager like MinGW or Cygwin, did you download pre-build libraries or did you compile the libraries yourself from source?
And if one of the latter, do you use Visual Studio?

@mrhatkat
Copy link
Author

mrhatkat commented Jan 6, 2019

I tried just downloading the libraries manually, building them using cmake, and then manually linking the include directories and libraries using the cmake GUI. Would you recommend using Cygwin or MinGW? Also after messing around with the cmakelists, I was able to get a visual studio solution as output from cmake,but I was unable to build the solution.

@z33ky
Copy link
Collaborator

z33ky commented Jan 6, 2019

Same as @Quaker762, I use Linux. I just wanted to get a clearer picture of your setup.
MinGW and Cygwin impose a more Linux-like environment, which would probably make it easier, but ideally we should try and fix up our build-scripts.

In theory, after building the libraries you should just be able to set the directories/files for each library in cmake-gui and you should be good to go. Like with the error above, where it complains about missing SDL_LIBRARY, you should just be able to set that variable to the path of your SDL2.dll and it should proceed from there.

Can you post your changes to the CMakeLists.txt? Even if you just hard-coded some paths, we should be able to improve our scripts based on the changes you needed to make.
Are you getting any error messages from attempting to build your generated solution?

@mrhatkat
Copy link
Author

mrhatkat commented Jan 6, 2019

All I did was comment out a few lines of code in the tests/cmakelists.txt:
#include_directories(SYSTEM "${OPENGL_INCLUDE_DIR}") #include_directories(SYSTEM "${SDL2_INCLUDE_DIRS}")

and source/cmakelists.txt:
#include_directories(SYSTEM "${OPENGL_INCLUDE_DIR}") include_directories(SYSTEM "${SDL2_INCLUDE_DIR}")
I also changed DIRS to DIR in these two lines. I'm starting to think that might have caused the errors in my solution though, since the error messages say that a lot of header files and the sdl library are missing. I also included the SDL2.cmake file from https://github.com/tcbrindle/sdl2-cmake-scripts in my cmake module directory.

I'm thinking I also don't have the libraries set up correctly. I have pretty strong familiarity with Linux, what are the steps you would take for installing the libraries and I'll see if i can figure out how to do that in Windows.

@z33ky
Copy link
Collaborator

z33ky commented Jan 6, 2019

Yeah, the directives you've commented out are needed.
You don't need to do anything special to install the libraries, you just need to know where to find the DLL/so-files and where to find the header files.
When you run the CMakeLists.txt with cmake-gui and click on "Configure" you should get a list of variables. Where CMake is unable to find stuff in their standard paths, you can just insert the paths where you downloaded the library. The *_INCLUDE_DIR usually need to point to a include-subdirectory and the *_LIBRARY should point to your built DLLs (or maybe the .lib-files, I can't remember).
As for DIR vs DIRS, CMake scripts are inconsistent about that. I think it should work as is, but I could just as well be off on some.

SDL2 should build a corresponding CMake script (see https://hg.libsdl.org/SDL/file/6a5107360fbc/CMakeLists.txt#l1820), which obsolete the Find*.cmake script as far as I understand. If you set SDL2_ROOT_DIR EDIT: sorry, that's SDL2_DIR to the directory that contains the built SDL2Config.cmake-file, the include- and library paths should get set correctly. If that variable doesn't exist you can just add it manually and it should be picked up when you hit "Configure" again.

I think the OpenGL-headers are somewhere in the MSVC folder. Do a file-search for "gl.h" in there.

@z33ky
Copy link
Collaborator

z33ky commented Jan 6, 2019

Also try replacing "${SDL2_LIBRARIES}" in the CMakeLists.txt with SDL2 and remove the lines saying include_directories(SYSTEM "${SDL2_INCLUDE_DIR}"). It seems like SDL2 only supports imported targets, which don't define those variables anymore.

@mrhatkat
Copy link
Author

mrhatkat commented Jan 6, 2019

That makes it so that I can get through Cmake, but I'm still having 145 errors in the visual studio solution.

@z33ky
Copy link
Collaborator

z33ky commented Jan 6, 2019

Are they related to SDL2? It might need SDL2::SDL2 instead.
Otherwise paste the errors on a Github Gist or something, they may be incompatibilities between compilers.

@mrhatkat
Copy link
Author

mrhatkat commented Jan 6, 2019

Sdl2 seems fine, the problem seems to be with zlib using unistd.h which doesn't exist on windows, and API Entry is undefined which I think is an OpenGL problem.

@z33ky
Copy link
Collaborator

z33ky commented Jan 6, 2019

Try replacing if(CYGWIN) in the top-level CMakeLists.txt, line 117 by if(CYGWIN OR MSVC). That should fix your APIENTRY issue.
For zlib/unistd.h, an Internet search suggests that this is due to an incorrectly generated zconf.h within the zlib build. Did you also build zlib via Visual Studio?

EDIT:
You can try applying these changes to your zconf.h: http://trac.wxwidgets.org/attachment/ticket/17745/minor-changes-to-make-MSVC-happy.patch

@mrhatkat
Copy link
Author

mrhatkat commented Jan 6, 2019

I used something called "GNUWin32" which I read was a zlib library for Windows,but that might be causing the problems.

@z33ky
Copy link
Collaborator

z33ky commented Jan 6, 2019

Yeah, that likely used something like MinGW, which provides a unistd.h.
Try finding a version of it built with MSVC - or build it yourself. Note that all the libraries you downloaded must be built with MSVC, possibly even with the same version, I'm not sure.

As I said before, using something like MinGW or Cygwin (I think the former is more popular) is probably easier, but still I appreciate you trying and sticking with it so far :)

@mrhatkat
Copy link
Author

mrhatkat commented Jan 6, 2019

Yeah, part of me actually finds this fun. I'm going to try doing it from scratch one more time, and then I'll try switching to MinGW or Cygwin. Thanks for all the help.

@z33ky
Copy link
Collaborator

z33ky commented Jan 6, 2019

Note that zlib provides MSVC-project files in contrib/vstudio.

@mrhatkat
Copy link
Author

mrhatkat commented Jan 7, 2019

Do you know how to use OpenGL through Cygwin? There's a package for everything else but that.

@Quaker762
Copy link
Member

Quaker762 commented Jan 7, 2019

@mrhatkat If I remember correctly, the OpenGL lib should be part of Windows? You should be able to link with -lGL or -lOpenGL32 or something similar. I wasn't using Cygwin when I was on Windows, as I think it's horrible. I mostly just use cmd and Powershell, with msys (if a desperately need some kind of unix interface) and mingw, as using such made porting to Linux much easier, as we wouldn't have too many crazy issues with compilers spitting out different code. I highly recommend using mingw-w64 which can be found here: https://mingw-w64.org/doku.php. I'm using gcc 8.1.0 with POSIX and SLJL if you want to install it yourself. For an IDE, I've started using Eclipse cpp on Windows. It's got an autocomplete, tasks list etc just as good as Visual Studio in my opinion. From there I open a terminal window and do my compilation on that.

By the way, @z33ky, I've created another repo here https://github.com/Palm-Studios/OpenHill. This time the engine is a shared library (.dll on Windows, currently untested on Linux), where I'm using premake instead of cmake to simplify things a bit. I feel this will make it a lot easier to just port over to any other Silent Hill we encounter, instead of having to hack together a heap of stuff in the executable itself. Let me know what you think. I'm currently rolling all the math stuff myself, but I'm more than happy to not reinvent the wheel and just pull glm into it if you're happy to do so (or stay on this repo).

@z33ky
Copy link
Collaborator

z33ky commented Jan 7, 2019

Iirc Cygwin requires a X11 server for graphical applications, so if you can install xorg-server or something similar, that might come with the OpenGL library.

@mrhatkat
Copy link
Author

mrhatkat commented Jan 7, 2019

Sorry to say, but I'm giving up on this for now. I can't get it to work in Cygwin because the GLEW libraries mysteriously vanish after installing them, and I don't know what to do with MinGW. Maybe I'll try to boot up Ubuntu and see if I can get it to work there. Thanks for all the help though!

@Quaker762
Copy link
Member

@mrkathat Just install MinGW to your C drive, then add the bin/ folder to your path. MinGW is just a build of gcc for windows. Then gather the appropriate gcc libs for windows and you should be good.

Failing that, Linux will just work out of the box.

@z33ky
Copy link
Collaborator

z33ky commented Jan 7, 2019

You could also try Conan or vcpkg.

@mrhatkat
Copy link
Author

mrhatkat commented Jan 8, 2019

Ah man, I am having the worst luck with this. I keep trying to use the MinGW Makefiles generator in cmake but it keeps giving me the error:

The C++ compiler

"C:/MinGW/bin/g++.exe"

is not able to compile a simple test program.

@mrhatkat
Copy link
Author

mrhatkat commented Jan 8, 2019

I managed to finally get it close to working on Linux, I end up with 5 shared libraries( cam,input,sh3rd,tex,and vao),but where is the executable? Is there another step I'm missing? To clarify, I used cmake then I used make on the root directory,source directory,and tests directory.

@Quaker762
Copy link
Member

Ah man, I am having the worst luck with this. I keep trying to use the MinGW Makefiles generator in cmake but it keeps giving me the error:

That is very strange. You are using mingw-w64 yes? It could be cmake being a little bit screwy, we might be changing soon though so don't worry about it too much.

I managed to finally get it close to working on Linux, I end up with 5 shared libraries( cam,input,sh3rd,tex,and vao),but where is the executable? Is there another step I'm missing? To clarify, I used cmake then I used make on the root directory,source directory,and tests directory.

These are test executables that can be run. For example:

./tex

Will run the texture render test application. We didn't actually get into any engine dev besides formats, but I'm going to lay out a roadmap using the kanban(?) cards on this repo so that we can actually some work done, instead of sporadically implementing formats and features (the main reason for this was us having to reverse engineer a lot of stuff, thankfully there's someone that's done a lot of this for us already).

If you're comfortable enough to start making changes, however, go right ahead on your fork :)

@Quaker762
Copy link
Member

Hi @mrhatkat,

I've been working on getting a Windows build system working for you, and I've had somewhat of a breakthrough. If you go to my fork of the repo here: https://github.com/Quaker762/sh3redux/tree/build_sys you should be able to build all the dependencies by running build.bat. I've switched over to using premake5 (which can be found here: https://premake.github.io/download.html). Put this program in your path, run build.bat from build/platform/windows and then open a Command Prompt window from the root directory (where build is located) and type make. You will get an executable located in the bin directory.

Let me know if this doesn't work for you, I've got it working on my machine. You can also, optionally edit build.bat to support the visual studio compiler instead of MinGW, if you so choose, however, I've specifially set the premake5 file to use gcc flags, so I'm not sure of the compatibility of the two.

@mrhatkat
Copy link
Author

No such luck. I had to change line 25 of the batch file to cd ../../../ in order for it to find the premake5.lua file, but I still get a ton of errors. Here's a pastebin of the output: https://pastebin.com/1RDF8RNs . Also, I think it might be trying to build in 64 bit instead of 32 bit. I'm going to attempt using vcpkg and cmake, since I think my MinGw install is bugged. If that doesn't work, I'll try clean installing MinGW. Thanks for the help.

@Quaker762
Copy link
Member

Quaker762 commented Jan 28, 2019

Also, I think it might be trying to build in 64 bit instead of 32 bit. I'm going to attempt using vcpkg and cmake, since I think my MinGw install is bugged.

This definitely seems like it is the case, I have no clue why this would be happening, though Lord of Compilers, professor @z33ky might have some idea (hahaha). I'll upload the installer I used to install my version of mingw-w64 if Visual Studio doesn't work. If you do choose to go ahead with reinstalling. Do the following:

  1. Remove all traces of the old versions of mingw and verify by trying gcc --version at the command prompt.
  2. Download the following file: https://ufile.io/kq0ml (SHA-256 is 19B9A267A5B79913BF6A3A53CDA83C3F7711CB6C879D48CCB97B4ED15C21FCF1, size = 960504 bytes (937 KiB))
  3. Use the following settings to install:
  • version = 8.1.0
  • architecture = x86_64
  • threads = posix
  • exception = sljl
  • build revision = 0

Install it to the root directory (i.e C:).

  1. Then add the compiler to your path. Mine is C:\mingw-w64\x86_64-8.1.0-posix-sjlj-rt_v6-rev0\mingw64\bin

This should then work for you. If not, I'll have another look into it. Are you running Windows 10?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants