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

Error in VS2019 #382

Open
jampha opened this issue Mar 16, 2024 · 13 comments
Open

Error in VS2019 #382

jampha opened this issue Mar 16, 2024 · 13 comments
Assignees
Labels

Comments

@jampha
Copy link

jampha commented Mar 16, 2024

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.

@djowel
Copy link
Member

djowel commented Mar 16, 2024

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

redtide commented Mar 16, 2024

OK

@djowel
Copy link
Member

djowel commented Mar 17, 2024

@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?

@redtide
Copy link
Contributor

redtide commented Mar 18, 2024

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).
Compilers? GCC, Clang and MSVC seems enough to me, maybe MingW64? Platforms... when you cover Linux/BSD, macOS and Windows, later maybe Android, IOS and WebAssembly IDK what else. Just check the current repo at JetBrains. There is a limit (we have limits), else... yes, DIY.

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.
In that case CI can also build Elements, so they can download the static lib directly for their project.

@djowel
Copy link
Member

djowel commented Mar 18, 2024

Compilers? GCC, Clang and MSVC seems enough to me

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.

@djowel
Copy link
Member

djowel commented Mar 18, 2024

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.

@redtide
Copy link
Contributor

redtide commented Mar 18, 2024

I'm not sure I understand what you mean, run the build at install time?
Don't we need to build Skia before Elements and then link to it when Elements' build finishes?
From my POV you can add another option, say ELEMENTS_USE_SKIA_PREBUILD set to false by default, and run a custom CMake command that calls the python scripts. So if people like me don't want to build Skia, can use prebuilt binaries and set the option true/on.

@djowel
Copy link
Member

djowel commented Mar 18, 2024

I'm not sure I understand what you mean, run the build at install time?

Build Skia using cmake, instead of downloading prebuilt binaries.

@redtide
Copy link
Contributor

redtide commented Mar 18, 2024

Compilers? GCC, Clang and MSVC seems enough to me

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.

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.

Build Skia using cmake, instead of downloading prebuilt binaries.

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.
Yes, the idea is that after CMake do its tests/detections when configuring, it checks for the prebuilt bins option and if set it starts download binaries, else do nothing downloads and prepare Skia requirements/tools (default) and builds Skia when build starts.

@redtide
Copy link
Contributor

redtide commented Mar 18, 2024

In brief, we could not add the option now, and add Skia to the configuration:

  • add its dependencies in CMake
  • rename the build.py command to configure.py and remove the ninja build command
  • run checkout.py and configure.py during CMake configuration
  • at build time, before Elements, call Skia' ninja build command

@djowel
Copy link
Member

djowel commented Mar 18, 2024

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?

Because JetBrains' target is not a library. It is an app. They have control over everything.

@djowel
Copy link
Member

djowel commented Mar 18, 2024

Yes, the idea is that after CMake do its tests/detections when configuring, it checks for the prebuilt bins option and if set it starts download binaries, else do nothing downloads and prepare Skia requirements/tools (default) and builds Skia when build starts.

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...

@djowel djowel self-assigned this Apr 1, 2024
@djowel djowel added the bug label Apr 1, 2024
@djowel
Copy link
Member

djowel commented Apr 1, 2024

Please use the master (cairo) branch for now. Skia needs a LOT of work to get right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants