You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
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.
I'll create an issue for it.
I didn't compile it myself, i downloaded from the releases. Could it be a problem there?
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:
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:
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:
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:
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:
The text was updated successfully, but these errors were encountered: