[build] Yet another issue with Makefile and the documentation

[vbarboza]

Please, correct me if I'm wrong opening this issue as I have seen already issues #332, #336 and #401 dealing with different approaches (build on Linux, cmake and packaging). I've also read somewhere we are not deprecating the Makefile and changing the dependencies on openAL and GLFW, so here is my problem.

Yesterday I started reading the docs (https://github.com/raysan5/raylib/wiki/Compile-for-GNU-Linux) and building on my Linux Mint 18 (Ubuntu 16.04 LTS for all the matters), x86_64. The raylib compiles alright, but the examples/ and games/ don't.

In examples/ I had to allow multiple function definitions or it wouldn't compile: -Wl,-allow-multiple-definition, install libopenal-dev and add it to the LDLIBS.

In games/ I had to change the -lglfw3 to -lglfw as I read somewhere around the mentioned issues (but I missed comments or documentation regarding this, so I'm opening this). My solution added a GLFW_LIBTYPE which I'm not sure is the best way to go.

My changes were commited to my fork (https://github.com/vbarboza/raylib/tree/develop) - not sure if a PR is appropriate.

[a3f]

Could you paste the link errors and the exact build commands?

[RDR8]

The issue with GLFW3 is because it builds with those different linker names depending upon if it was built as static or shared. The wiki instructions to build GLFW3 result in a static library known as lglfw3 and that is what the Makefile is looking for by default. If one has installed GLFW3 with a package manager, it is the shared variety named lglfw. I might have the names crossed but I think it's right. Making use of GLFW_LIBTYPE seems like a logical addition if you want that control. Basically, it's a switch for the linker name? I'm not seeing your changes for some reason. You are right, more documentation will help too.

BTW, you may know this already but, raylib now bundles GLFW3 and there is no need to link to it unless you want to. Are you passing USE_EXTERNAL_GLFW=TRUE to make? If it's FALSE, one shouldn't have this problem.

On build systems, raysan5 develops raylib with make and that's not likely to change. You can use cmake if you prefer. There's even some meson stuff in project/Builder if you want to go that route.

[vbarboza]

Thanks for your replies. I started a clean installation and got stuck with the same issues.

• First, the examples/:

$ make PLATFORM=PLATFORM_DESKTOP

gcc -o core/core_basic_window core/core_basic_window.c -O1 -s -Wall -std=c99 -D_DEFAULT_SOURCE -fgnu89-inline -Wno-missing-braces -no-pie -D_DEFAULT_SOURCE -I. -I/usr/local/include/raysan5 -I../release/include -I../src -I../src/external -L. -L/usr/local/lib/raysan5 -L../release/libs/linux -L../src -lraylib -lGL -lm -lpthread -ldl -lrt -lX11 -DPLATFORM_DESKTOP
/usr/local/lib/raysan5/libraylib.a(textures.o): In function 'stb_perlin_noise3':
textures.c:(.text+0x69cc): multiple definition of 'stb_perlin_noise3'
/usr/local/lib/raysan5/libraylib.a(textures.c.o):textures.c:(.text+0xf6): first defined here
/usr/local/lib/raysan5/libraylib.a(textures.o): In function 'stb_perlin_ridge_noise3':
textures.c:(.text+0x6d69): multiple definition of 'stb_perlin_ridge_noise3'
...

My solution was adding -Wl,-allow-multiple-definition to the Makefile, which doesn't seem right to me.

• Then, I had the openAL problem:

/usr/local/lib/raysan5/libraylib.a(audio.c.o): In function InitAudioDevice': audio.c:(.text+0x9714): undefined reference to alcOpenDevice'
audio.c:(.text+0x974b): undefined reference to `alcCreateContext'
...
Makefile:395: recipe for target 'audio/audio_sound_loading' failed
make: *** [audio/audio_sound_loading] Error 1

And my solution was adding the -lopenal to the Makefile.

• Finally, in games/ the -lglfw3 issue.

@RDR8 The GLFW_LIBTYPE would be in fact a switch and using USE_EXTERNAL_GLFW isn't working for me (I should double check it and the Makefile). And in fact, I followed the Wiki instructions to link raylib with system GLFW (which is a shared lib due to -DBUILD_SHARED_LIBS=ON, correct?).

[RDR8]

My solution was adding -Wl,-allow-multiple-definition to the Makefile, which doesn't seem right to me.

@a3f I wonder if this has anything to do with raylib.h differing in raylib/src and raylib/release/include?

I had a compile time issue with textures_image_generation/"perlinnoises" when using raylib/release/include/raylib.h which went away after raylib/src/ make installing a copy of raylib/src/raylib.h, and passing -I$(RAYLIB_H_INSTALL_PATH) in examples/Makefile. raylib.h may be included twice in there somewhere when building the examples.

@vbarboza I have not done anything with an external, compiled static or distro-packaged shared, GLFW since raysan5 started bundling it. It was working ok except for that -lglfw(3) oddity. Since your line aboves show that you are using libraylib.a, you shouldn't have had any problems. You're deviating from the standard setup in two ways, USE_EXTERNAL_GLFW=TRUE and having a distro-packaged version of GLFW. The default setup seemed alright to me but it's possible the dual-inclusion problem above was introduced by my updates to the Makefiles, but the edits were mostly limited to RAYLIB_LIBTYPE=SHARED. I'll review the docs and usage of the default static build target and USE_EXTERNAL_GLFW when I get a chance. Holler back if you figure it out.

As far as I know, -DBUILD_SHARED_LIBS=ON in src/Makefile is just referring to libraylib.so if one is doing make RAYLIB_LIBTYPE=SHARED ... .

[vbarboza]

I'll review the docs and usage of the default static build target and USE_EXTERNAL_GLFW when I get a chance. Holler back if you figure it out.

@RDR8

Today I checked the games/Makefile and it doesn't check fot the USE_EXTERNAL_GLFW compilation option as the other Makefiles, passing -lglfw3 when building for Linux.

@a3f
Regarding the multiple defitions, as I am not familiar with the library architecture, no clue on the issue.

[RDR8]

@vbarboza Tracking down the multiple defs, Do you have raylib installed with make install? If so, gcc may be looking at two versions of raylib.h. Try removing -I$(RAYLIB_PATH)/release/includes temporarily from INCLUDE_PATHS at about examples/Makefile:226 or 248. If the problem goes away, hmm.. well better lucky than good. RAYLIB_H_INSTALL_PATH is the location where raylib.h is placed by make install ... If you remove that from INCLUDE_PATHS instead, and get the same error, maybe the problem is due to the difference between the newer src/raylib.h and older release/include/raylib.h. The "installed" version is a copy of src/raylib.h since it's newer and what we build against. release/include/raylib.h is provided, I think, for the binaries that come with raylib. I'm not sure why it's not been updated.

I haven't looked over games/ or templates/ makefiles in a while. I am working on extending and documenting the install : target and usage of the examples. If that works out well, I'll try to push the _PATHs out to the other makefiles. I still don't really know the ins and outs of your use case.

[RDR8]

I saw
/usr/local/lib/raysan5/libraylib.a(textures.o): In function 'stb_perlin_noise3': textures.c:(.text+0x69cc): multiple definition of 'stb_perlin_noise3' /usr/local/lib/raysan5/libraylib.a(textures.c.o):textures.c:(.text+0xf6): first defined here /usr/local/lib/raysan5/libraylib.a(textures.o): In function 'stb_perlin_ridge_noise3': textures.c:(.text+0x6d69): multiple definition of 'stb_perlin_ridge_noise3'

briefly, but it went away for unknown reasons after some tinkering. ../examples$ make seems to work with the provided libraylib.a in ../release/libs/linux before make clean or after git checkout ../release/libs/linux/libraylib.a. It also seems to be working with our built version after ../src$ make and after ../src$ make install. The shared varieties also seem to be working. I am using the makefiles staged at #480 . I would still like to know the cause of the error and will review it occasionally.

[RDR8]

@vbarboza I can only recreate your problem compiling the texture example in one scenario. It only happens with a brand new copy of raylib source tree. The raylib source package comes with a pre-built libraylib and some other object files so that one can compile the examples without makeing raylib in ../src. If in ../src, you make without ever having run make clean, you are building on top of the old library. It is the file differential that is exposing the problem but once make clean has been run in src/, the problem goes away forever. If this works for you, please report. Thank you!

[raysan5]

It should work ok now. Just closing this issue. Feel free to reopen it if problem persists.