Raylib and possible vendor improvements

[ygorpontelo]

I was investigating cross compilation and decided to try out the vendor raylib. I had a problem with linking glfw, so i looked at the this configuration:

"linux-x64" : {
  "link-args" : [],
  "dependencies" : [],
  "linked-libraries" : ["raylib", "GLESv2", "glfw", "c"]
},
"windows-x64" : {
  "linked-libraries" : ["raylib", "opengl32", "kernel32", "user32", "gdi32", "winmm", "winspool", "comdlg32", "advapi32", "shell32", "ole32", "oleaut32", "uuid", "odbc32", "odbccp32"],
  "wincrt": "none"
},

Considering the pre compiled library available at the vendor is compiled without any modifications on the options on the build or even obtained by the Releases in github from raylib itself, then linking against glfw is not needed as it's already compiled along the library. The same thing would apply to the windows target, with the exception of two dependencies which they specify need to be linked: GDI32 and WinMM. Check here.

Those two targets then would look like this:

"linux-x64" : {
  "link-args" : [],
  "dependencies" : [],
  "linked-libraries" : ["raylib"]
},
"windows-x64" : {
  "linked-libraries" : ["raylib", "gdi32", "winmm"],
  "wincrt": "none"
},

Specifying to link extra libraries doesn't yield an error given that you have those in the system, however it's best in my opinion to minimize the extra efforts if possible, specially because linking with GLESv2 doesn't seem to change anything either. I'm not sure what is "wincrt": "none", but it seems to be required.

The second error i observed was in the naming of the .libs for windows when compiling in linux, for instance:

lld-link: error: could not open 'gdi32.lib': No such file or directory
lld-link: error: could not open 'winmm.lib': No such file or directory
lld-link: error: could not open 'dbghelp.lib': No such file or directory
lld-link: error: could not open 'kernel32.lib': No such file or directory
lld-link: error: could not open 'user32.lib': No such file or directory
lld-link: error: could not open 'Shlwapi.lib': No such file or directory
lld-link: error: could not open 'Ws2_32.lib': No such file or directory
lld-link: error: could not open 'MSVCRT.lib': No such file or directory
lld-link: error: could not open 'OLDNAMES.lib': No such file or directory
lld-link: error: could not open 'uuid.lib': No such file or directory
Failed to create an executable: (null)

Those libs exist, considering we ran the python script to create the directory, but the problem are that the names are matching with case sensitive. Renaming the .libs in the directory made it work. So we either make the script convert the names for us, or we the compiler grabs those with case insensitive.

I'm not sure if it is as intended, but the vendor-fetch on linux yielded this error:

Error: vendor-fetch only available when compiled with cURL.

Would be great if there was a way to know the vendor options. It would also be good to allow us to specify different compiled library options besides the one packed with the vendor, for example if i compiled raylib to use a different opengl version and want to use that instead.

Compiler info:

C3 Compiler Version:       0.6.4 (Pre-release, Nov  5 2024 09:51:35)
Installed directory:       /home/ygor/c3_lang/
Git Hash:                  08d1b29301eb057494a5b6c59278200f0db33ad4
Backends:                  LLVM
LLVM version:              17.0.6
LLVM default target:       x86_64-pc-linux-gnu

[lerno]

I think the linked libraries are taken from the examples for raylib. If there is a smaller set then that is fine. Just make sure it's not because those libraries are linked from other sources anyway.

Re the windows-on-linux issue: fixing the case by doing it when copying in the python script seems to be the only solution from what I'm hearing on the discord. It's worth filing an issue for it.

As for vendor-fetch not being present: this is if it's compiled without curl being found on the system.

[ygorpontelo]

1. As far as i'm aware the deps are all bundled into the lib, with the exception of the two on windows i mentioned. Someone else could help verify this as well.
2. I'll create an issue for it.
3. I didn't compile it myself, i downloaded from the releases. Could it be a problem there?

[sudokit]

On the topic of raylib improvements, could it be possible to ditch the Vector2 raylib structure, and just use builtin float[<2>]? it should? and would make code allot easier to write without having to always write a conversion function and call it etc.

[lerno]

No, it's important in order to get ABI compatibility. Although I think replacing the Vector2 structure with float[2] would be possible, and float[<2>] are implicitly convertible between each other. If you want some convenience right now though you can use splat:

float[<2>] vec = ...
call_with_vector2({ ...vec })

[Book-reader]

Considering the pre compiled library available at the vendor is compiled without any modifications on the options on the build or even obtained by the Releases in github from raylib itself, then linking against glfw is not needed as it's already compiled along the library.

this appears to be true, when I run raylib5.c3l on a system that does not have the glfw libs installed it runs fine when linked-libraries is ["raylib", "c"]

with the default linked-libraries it gives a linker error cannot find -lglfw: No such file or directory cannot find -lGLESv2: No such file or directory