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

Raylib and possible vendor improvements #33

Open
ygorpontelo opened this issue Nov 19, 2024 · 2 comments
Open

Raylib and possible vendor improvements #33

ygorpontelo opened this issue Nov 19, 2024 · 2 comments

Comments

@ygorpontelo
Copy link

ygorpontelo commented Nov 19, 2024

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
Copy link
Contributor

lerno commented Nov 21, 2024

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
Copy link
Author

  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?

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

2 participants