-
Notifications
You must be signed in to change notification settings - Fork 237
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
Error in VS2019 #382
Comments
We are using VS2022 currently. Any chance you cal use that instead. The linker errors are related to the c++ library. Skia is the dependent library, specifically tag m106. I must warn you though. Skia is a PAIN to build. @redtide Another addition to the dependency matrix of the pre-compiled headers: compiler version :-( |
@redtide The issue here is that we can't practically have all the precompiled binaries for all platforms, compilers, processors. And the glaring question is, what do we do when someone has a particular setup that is not included in our binaries for download? Do we just ask them to run the script? And then what? |
Until now other than Arm64 and x86_64 (32 is becoming old even for RPi and the like it seems) there was only a request for RiskV (in another project). That is also why I like the idea to use scripts instead embedding commands in CI, so people can use them locally to build. Maybe that way they can propose some PR to include some exception we don't cover? Though it seems already a lot of builds to support. As side note, the current JetBrains repo seems to have removed the compiler option, so I guess they now only build using GCC on Linux and MSVC on Windows. If were me I would force to use Clang everywhere instead since it's the one where Skia gives the maximum performances. IDK on Windows but using Clang on Linux is not that big pain for a C++ based project. WDYM with and then what? I guess they have to check first also that the Artist, Elements (maybe also Infra header only libraries?) code supports their setup. They can also maintain their own custom setup themselves using CI (both for Skia and Elements) if we can't support all the options in the world. |
That is correct. But I should have mentioned: compiler versions. As you see in this issue, a prebuilt library for VS 2019 is not necessarily compatible with VS 2020 or VS 2023. It's a combinatorial explosion. |
Here's a thought. What do you think about not pre-building at all using CI, but instead having the build script for Skia run, on demand, at install time on each platform, via cmake. That would mean, having python and all the build dependencies of Skia. The pre-built thing is looking like a nasty rabbit hole. |
I'm not sure I understand what you mean, run the build at install time? |
Build Skia using cmake, instead of downloading prebuilt binaries. |
OK, so if version is also an issue I'm starting wondering how JetBrains people have no issues with it, maybe users using it just use the same compiler and same version? Still the answer above could be a solution: want different setup/unsupported platform/whatever? BIY (build it yourself :D ), else use our setup and prebuilt bins.
Ah OK, so it's what I call "configuration time" (IDK if there are "standard names"), install time for me means when you install all the built artifacts in system. |
In brief, we could not add the option now, and add Skia to the configuration:
|
Because JetBrains' target is not a library. It is an app. They have control over everything. |
Sounds good to me. Basically, something like: we prepared prebuilt libraries for Skia for xxx-system and www-compler and zzz-processor. If we do not have a prebulit library for your target, the cmake build scipt will attempt to build Skia for you. In such cases, here are the requirements: this and that and so on... python etc... |
Please use the master (cairo) branch for now. Skia needs a LOT of work to get right. |
There was an error in VS2019.
2>skia.lib(gpu.GrDrawingManager.obj) : error LNK2001: unresolved external symbol __std_find_trivial_8
2>skia.lib(skia.SkSLVMCodeGenerator.obj) : error LNK2001: unresolved external symbol __std_max_element_8
2>skia.lib(skia.SkSLString.obj) : error LNK2001: unresolved external symbol __std_find_trivial_1
2>skia.lib(gpu.GrGLCaps.obj) : error LNK2001: unresolved external symbol __std_find_trivial_4
Is it possible to provide the source code of the dependent library so that we can compile it ourselves.
The text was updated successfully, but these errors were encountered: