[build] Compilation issues under linux

[define-private-public]

I'm off of the branch develop right now. But instead of using the latest commit (like in this issue), I grabbed the commit from that pull request of mine you accepted. I'm trying to compiled a shared raylib and I've run into a few hiccups.

I've found a few problems:

1. Ubuntu's libglfw3-dev package is out of date, so I had to compile and install glfw3 from source (which isn't hard), but when I tried to run make SHARED_LIBRARY=YES, it failed. When compiling and installing from source, the .so is installed to /usr/local/lib, but under the name libglfw.so. Right now src/Makefile is trying to link -lglfw3 for Linux. that 3 at the end was causing a "library not found" issue. Removing it made compilation work. What would be a good solution for this? I'm not sure if just purging the 3 will not break other things
2. That -lglfw3 issue was also in examples/Makefile, so that needs to be addressed.
3. examples/Makefile is also looking for raylib under RAYLIB_PATH ?= C:\raylib\raylib. This is incorrect. Setting it to ../ will make it work. this is also the same case for compiling the examples under OS X. I think one of those PLATFORM_OS checks needs to be added here
4. Examples compile fine until it hits models_heightmap.c.

gcc -o models/models_heightmap models/models_heightmap.c -O2 -s -Wall -std=c99 -D_DEFAULT_SOURCE -I. -I..//release/linux -I..//src -I..//src/external  -I/usr/local/include/raylib -L. -L..//release/linux -L..//src  -lraylib -lglfw -lGL -lopenal -lm -lpthread -ldl -lX11 -lXrandr -lXinerama -lXi -lXxf86vm -lXcursor -DPLATFORM_DESKTOP 
/tmp/cc5Nbwjh.o: In function `main':
models_heightmap.c:(.text.startup+0x119): undefined reference to `LoadHeightmap'
collect2: error: ld returned 1 exit status
Makefile:488: recipe for target 'models/models_heightmap' failed
make: *** [models/models_heightmap] Error 1

Interestingly enough, when I was trying to get the Nim bindings working, LoadHeightmap was also giving me dynamic linking problems.

[define-private-public]

I think the .so on Linux is broke. I'm trying to figure out what it might be. I think it might have something to do with adding a -Wl,-rpath... option to the linking step, but I keep on coming up empty.

So far this is what I get if I try to make the examples with a shared library:

ben@linux:examples$ ./core/core_basic_window 
./core/core_basic_window: error while loading shared libraries: libraylib.so: cannot open shared object file: No such file or directory
ben@linux:examples$ ldd core/core_basic_window
	linux-vdso.so.1 =>  (0x00007ffce77fd000)
	libraylib.so => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd94a51b000)
	/lib64/ld-linux-x86-64.so.2 (0x00005602f47af000)

Any ideas?

[tmerr]

I think libraylib.so and libglfw.so.3 both install to /usr/local/lib which isn't in ubuntu's default library search path, but it's not hard to set up:

https://ubuntuforums.org/showthread.php?t=420008
https://stackoverflow.com/questions/4743233/is-usr-local-lib-searched-for-shared-libraries

[raysan5]

Hi @define-private-public! As @tmerr commented it's mainly a path issue... just added some additional checks to makefile (9272966).

About GLFW, right version should be 3 but I thinks that's a Linux distribution dependant issue...

About LoadHeightmap() just removed that function and replaced it by a better approach, just uploaded reviewed example: 1633399

Some parts of the library have been redesigned in raylib 1.8 for better consistency and PBR materials support. Here it is more info on new features.

[define-private-public]

When I get home I'll take a look at these things. Thinking about the glfw3 thing, I'm a little confused on what was is going on now with it. On my desktop machine, it needed -lglfw3 whereas my laptop (which is what I was on last night) needed the -lglfw. On the laptop, I did an install from source. It's been a while for the desktop, so I'll see how I installed it. Both machines are running Ubuntu 16.04 and glfw 3.2.1, which makes this even more odd. There has got to be some proper way for that...

As a side note, might I propose a slightly better branch system:

• master -> What is the last current stable release. Might also be good to rename this branch to release
• develop -> The latest and greatest of the source. What we should be merging code into
• build -> Similar to develop, but is verified to build fine without any compilation/linking issues.

[raysan5]

About branch system, I feel confortable with current one. Actually, master is the github recommended naming convention for main branch. It's based on this model. develop branch is usually verified to build... I try to avoid uploading code that doesn't build.

[RDR8]

Shared and static versions of glfw have different names no matter where you get them. -lglfw for shared, as per typical distro package installation and -lglfw3 for the static version generated by default when building glfw as per raysan's instructions on the wiki. BTW, Xenial's stock GLFW 3.1.2 IS horribly out of date.

[RDR8]

I guess editing the Makefile to suit a particular case is the way to go.

[define-private-public]

Well I found something interesting in the glfw3 source. By default it will make static libraries if you build it from source, and will produce a libglfw3.a file. But, at the cmake step, if you specify -DBUILD_SHARED_LIBRARIES=ON, it will then produce a libglfw.so file. On my desktop I had it statically built. That's why there was that weirdness!

I'm going to go report this to the GLFW devs and see what they think.

EDIT:
Reported: glfw/glfw#1051

[RDR8]

As far as I know, @raysan5 mostly develops on Windows and is rightfully leery of any particular build system on Linux. There are so many tools and systems, it's very distracting to a beginner just looking for exposure to video game programming. In the Linux world, the expectation seems to be that, as developers, it's on us to know where our towels are, so to speak. If you have a handle on make, gcc, and cpp, you are doing well. I'm not sure what your level is, but I had these same issues a few months ago and learned a lot researching them.

[RDR8]

@define-private-public Are you interested in Cmake support for raylib? We might be able to simplify some of the Linux specific logic in the makefiles as well as add handling for library types or other #defines such as CC, DEBUG, and RELEASE. It's important, for me at least, to remember that distributing raylib is somewhat different than distributing a game made with it. Truthfully, I don't know much about Cmake or any other Linux build system. At one time, @raysan5 mentioned premake, which is cross-platform with Windows. That might make his job as little easier, stuck between a rock and a hard place as he is. Anyway, I'm interested in your ideas and if I can help, I will.

[define-private-public]

I can understand where he's coming from. It's a mess sometimes trying to figure out what to use and what not to use. The only thing that I can think of that might simplify these issues is to try switching the build system to CMake instead hand written Makefiles.

GLFW has CMake support (and they use it too), so that dependency would be easily covered. CMake would also help ensuring that targets will build and run correctly on their systems. It might be worth a shot to try.

[RDR8]

Well, maybe we should identify a couple of initial targets to implement. @raysan5 likes to keep dependencies down and I think there may be times when we want raylib, GLFW, and whatever else one might want to add, built in to the distributable. I know it's not the Unix way, but it does effectively extend the range and stability of a particular product. For example, the Steam runtime exists for this purpose. Just compile against it with the Source SDK and those libraries are guaranteed to exist when you distribute through Steam.

Anyway, we could start with mirroring what happens now. When that works, add in handling of shared libraries, install locations and distro variables.

Coming up with a nice template for developing games is another thing to think about. Game-specific makefiles, etc

Just so you know, I'm starting at square one with Cmake and am more than willing to just test anything you make. (^;

[RDR8]

How are you editing and managing files? We don't have anything like the Windows notepad project. I've been using Geany. Providing a pre-configured project is a side goal.

[define-private-public]

(neo)vim, command line git, bash, & your standard linux/unix utils; I'm just that hardcore.

I'm not too familiar with CMake or how to work it properly, but I've used it a few times. It's a pretty solid build system.

[define-private-public]

Reporting in that the .so's (with the tweaked command line flags noted above) will work on Linux, and with the examples! (That means I can get back to work on the Nim bindings!!). But they do need to be installed to /usr/lib/local. Which means a sudo make install SHARED_RAYLIB=YES.

Before anything else it touched, I think it would be a good idea to hear back from the GLFW folks about that dropped 3 for the .so.

[raysan5]

Hi @define-private-public and @RDR8, just my two cents on this issue.

About glfw3 vs glfw on shared library, thanks for the investigation, let's wait for an answer on their side.

About raylib building, one of the goals of raylib is keeping things as simple and possible for the user, I prepared the library to be as easy to setup and start coding games (at least on Windows), it is great for my students. But I understand that now the scope of the library is wider (more advance users) and also building options have increased (multiple platforms, build mode, configuration flags...). Personally I don't like CMake (despite I know it's pretty standard), I've used it several times and I don't find it user-friendly; plain Makefiles are not way better but at least they do not usually require any external dependency, most compiling packages support them. After some investigation I found premake and it seems pretty powerful, easy and simple to use, very aligned with raylib philosophy... haven't tried yet but Blizzard using it gives me some security and confidence with that tool.

In any case, I don't have enough time to work on that, so any contribution on that field is welcomed.

Coming up with a nice template for developing games is another thing to think about. Game-specific makefiles, etc

Here there are some game templates (with their own Makefiles): raylib/templates

(neo)vim, command line git, bash, & your standard linux/unix utils; I'm just that hardcore.

Wow! Amazing! :D

[define-private-public]

sigh: It looks like OS X also has this inconsistent 3 issue too...

The only solution I can think of now is that when you build GLFW for OS X or Linux, it will also include some things for pkg-config. So then we would have to shove pkg-config glfw3 --cflags --libs, and it would resolve the proper library and include directory for us on those platforms .

Only thing would now to be telling our users that they need pkg-config for OS X & Linux. I don't think that pkg-config is on Linux by default, but it's a very common tool. As for OS X, I can't remember how I grabbed it (maybe from a homebrew dependency?).

I'd rather see what the GLFW devs have to say about the 3 issue first though.

[define-private-public]

I've been toying around with cmake a bit. And I was able to get an equivalent .so using that as a building system to work on Linux. If you want to take a look at the branch, it's here: https://github.com/define-private-public/raylib/tree/cmake_test

I'm going to play around some more to see if this works well. @raysan5 If it does, would you be interesting in switching the build system over from handmade Makefiles to generated ones with CMake? I understand where you're coming from wanting things to be a simple as possible for the end users, but telling them to do mkdir build; cd build; cmake ..; make Isn't that hard. You might find it much easier (and more maintainable) to manage that handbuilt stuff.

TODO:

• .so on Linux
• .a on Linux
• .dylib on OS X (need to add -Xlinker -rpath . when linking the binary)
• .a on OS X (be sure to cp libraylib.a ../../release/osx before building the examples)

Could you also see how my branch works for you on Windows? By default it builds static libraries, but if you toggle the SHARED_RAYLIB variable to ON then you'll get the .dll

EDIT:
Damn, static and shared works on those two OSes with CMake!! I'll try testing this on Windows next, but I don't have a Microsoft Machine really that well setup... Anyone else want to try for me?

[raysan5]

I prefer to keep current handmade Makefiles, they are more clear to me and also support other platforms like RPI or Android. But it could be useful to add the CMake option as an alternative for users that prefer this appoach. Another user also implemented meson building: #176

[define-private-public]

The CMake things I'm doing right now are more of a test than anything. I plan on adding targets for RPi, Android, and web. But those will come after Desktop.

[define-private-public]

So you develop on Windows. What exactly is your workflow and environment there? MinGW or MSVC? Say if you were given a clean Windows machine, how would you get setup?

[raysan5]

Well, it could sound crazy but all raylib has been developed using Notepad++ with custom compiling scripts preconfigured for MinGW as default compiler. On a clean Windows machine just download and run raylib installer and everything is setup (and portable) to start developing games or modifying the library. For a student, that automatic environment setup is perfect, no brainer!

A part of that, I use GitHub to sync the project and I also have a Visual Studio 2015 project (included in installation) in case I need a debugger or some more detailed code analysis... but most of the time I only use Notepad++ with the custom compiling scripts (basically command line direct calls).

[define-private-public]

Okay thanks for that info. When I can get my Windows machine back up and running, I'll see if I can get the CMake files to work for that workflow.

In other news, I got the examples partially working. So if you check out my cmake_test branch. then do mkdir build && cd build && cmake .. && make -k It will build raylib and any of the examples that don't have issues.

I know you're hesitant on using this is the main build system, but so far what I've written has already cleared up the headaches I've had with getting shared and non shared to work on Linux & OS X, and resolving the GLFW issue. If I can get this to be more robust, would you be willing to give it a shot? CMake is not really scary; it just looks that way.

I also know that there is already a CMake ticket out there. Instead of reviving it, is it okay if I can go make a fresh one? I'd like a clean working space.

[raysan5]

I'm hesitant to use CMake, I know it's pretty standard in software dev but I prefer to keep a build system with no-dependencies that I can maintain by myself, just in case.

In any case, adding support for CMake to raylib is really welcome, once implemented we can find some way to manage both systems (or any other ones).

You can open a new ticket for clean discussion, it's ok. :)

[raysan5]

Just closing as per #336.