WebGL sample compilation

Hi

Im trying to build. WebGL sample.

I managed to build FreeType and OCCT libraries using emsdk, but I cant build sample itself.

While configuring this sample in Cmake-gui I have error message. (both windows ans linux)

CMake Error at CMakeLists.txt:33 (find_package):
Could not find a package configuration file provided by "freetype" with any
of the following names:

freetypeConfig.cmake
freetype-config.cmake

Add the installation prefix of "freetype" to CMAKE_PREFIX_PATH or set
"freetype_DIR" to a directory containing one of the above files. If
"freetype" provides a separate development package or SDK, be sure it has
been installed.

 

Setting freetype_DIR to freetype installation path does not work. Adding installation path to CMAKE_PREFIX_PATH has no effect. Simply I don't have freetypeConfig.cmake freetype-config.cmake files there

Any sugestions?

Regards

Adam

Kirill Gavrilov's picture

If you've built FreeType without using CMake, then you have to extend CMake scripts for WebGL sample with FreeType search paths (similar to "adm/cmake/freetype.cmake" used for building OCCT itself).
Alterantively, you can re-build FreeType using CMake - in this case FreeType installation folder will have "lib/cmake/freetype/freetype-config.cmake" configuration file, so that freetype_DIR in WebGL sample should point to this "lib/cmake/freetype" folder.

Adam Wnek's picture

Thank you for reply,

Actually I have edited CMakeLists.txt in webgl sample to fit my local paths where emscirpten complied libraries have been installed. I just finished and it works. :)  Now I have some basic understanding how it works, and I can try prepare my own small WebAssembly application

Regards

Adam

Andy Du's picture

Hi Kirill,
My case is "If you've built FreeType without using CMake, then you have to extend CMake scripts for WebGL sample with FreeType search paths (similar to "adm/cmake/freetype.cmake" used for building OCCT itself).",
I tried to add the free path into CmakeLists.txt of WebGL sample, but not success.
The line I added is, I use the absolute path:
set(freetype "C:/OpenCASCADE-7.5.0-vc14-64/opencascade-7.5.0/adm/cmake/freetype.cmake")
Do you have any suggestions?

Thanks,
Andy

Stefan Lang's picture

Hello

I am trying to build the WebGL sample too, but running into the exact same problem as described in the OP. Your advice doesn't help me, as I could not locate (or create?) any file called freetype-config.cmake anywhere: the OCCT source doesn't provide it, neither does the freetype source downloaded from the FreeType site. I read somewhere it should be created by CMake, but it does not. Then I read somewhere else that it should be provided by the library authors, but it isn't.

Setting freetype_DIR doesn't help either, cmake still wants the config.cmake file!

Apparently I cannot proceed without this file, and then I may run into the same issue with OCCT itself which also doesn't provide a configure.cmake file! Where am I supposed to get these files?

Note: I am trying to build on Windows, which in itself is a challenge because many of the instructions (and the make files) assume a Linux environment. cmake-gui got me a long way, but only because I was already somewhat familiar with it, not due to the instructions provided.

I would very much appreciate any help on building the webGL sample on Windows, and maybe someone at OCCT should really look into the instructions provided with the sample with regard to building on Windows.

P.S.: it just occurred to me that emscripten's cmake (emcmake) might be the issue here, as it insists on these files, whereas cmake-gui does not. I will issue a similar inquiry at their site.

Kirill Gavrilov's picture

I could not locate (or create?) any file called freetype-config.cmake anywhere

This file is expected to be generated by CMake while building and installing FreeType library. As FreeType project has several ways for building library and CMake is only one of them - freetype-config.cmake is not necessarily would appear depending on how you have decided to build it. Another problem is that these config files might be broken or cannot be properly imported.

Setting freetype_DIR doesn't help either, cmake still wants the config.cmake file!

You don't need to have config.cmake for using FreeType - it should be enough specifying 3RDPARTY_FREETYPE_INCLUDE_DIR_freetype2 / 3RDPARTY_FREETYPE_INCLUDE_DIR_ft2build / 3RDPARTY_FREETYPE_LIBRARY_DIR to real paths.

set "aFreeType=c:\freetype-2.10.4-wasm32"
...
 -D 3RDPARTY_FREETYPE_DIR:PATH="%aFreeType%" ^
 -D 3RDPARTY_FREETYPE_INCLUDE_DIR_freetype2:FILEPATH="%aFreeType%/include" ^
 -D 3RDPARTY_FREETYPE_INCLUDE_DIR_ft2build:FILEPATH="%aFreeType%/include" ^

If you are CMake guru - fill free to propose patches to FreeType / CMake / OCCT project (whatever is broken) to make automated FreeType searching better.

cmake-gui got me a long way

CMake GUI is nice to see which building options are configurable in specific project, but it is terribly misleading when cross-compiling.

Stefan Lang's picture

Thank you for the advice

Unfortunately neither approach worked for me: after failing on Windows I tried building OCCT and then the sample on an Ubuntu subsystem, and then within a Docker image. I could specify the Freetype paths for building OCCT on Ubuntu (wsl or Docker). As a matter of fact it was sufficient to set 3RDPARTY_DIR, although for some reason I still needed to specify the freetype lib dir.

However, for the webGL sample neither 3RDPARTY_DIR nor any of the vars you suggested had any effect!

And neither on Windows nor on Ubuntu does 'install' create any .cmake file!

The only other option I can think of right now is editing the CMakeLists.txt file, but this really shouldn't be neccessary!

P.S.: Just to be clear: I did manage to build FreeType 2.5.5 (took me some time to locate the right version) and OCCT too, with the help of these vars, but I'm still stuck with the webGL sample. I did try the newest version of FreeType in case that version creates the .cmake file, but it doesn't.

Kirill Gavrilov's picture

However, for the webGL sample neither 3RDPARTY_DIR nor any of the vars you suggested had any effect!

Sorry for misguidance - I thought that you have problem building OCCT, while your current issue is related to WebGL sample. Just to clarify - these are two projects with independent build rules (CMake scripts).

OCCT has extra tricks to find FreeType library - so there are variables like 3RDPARTY_FREETYPE_DIR and could be configured even when it was built without CMake. At the same time, WebGL sample relies on plain CMake capabilities here and just calls

find_package(freetype REQUIRED NO_DEFAULT_PATH)

Standard find_package() for CMake is pretty straightforward and wouldn't work if FreeType wasn't built with properly generated CMake configuration files. And only freetype_DIR variable matters here. It is possible adding custom rules for searching FreeType to WebGL sample (similar to what OCCT does), but it wasn't done for simplicity of the sample - in an assumption that CMake is that great that it shouldn't be a real problem to users (sarcasm billboard).

By the way, I've shared freetype-2.10.4-wasm32.7z that I'm actually using for building - in case if it might help anybody.

Stefan Lang's picture

Thank you for sharing that link. I have checked out that pseudo script and found it does pretty much the things I tried. However, they are apparently unix based.

I tried to make it work on Windows based on the (pseudo) command:
git clone --depth 1 --branch VER-2-10-4 https://gitlab.freedesktop.org/freetype/freetype.git "${BUILD_DIR}/freetype2.git"
, but the freetype project files created for VisualStudio contains unix code that I cannot build. Even if I can find out how to make it work with Ninja, I don't think that would fix the unix code issue, as the referenced unix headers simply don't exist! I find that a bit odd because the Readme.git says that freetype doesn't contain pre-built configuration scripts for UNIXish platforms - so how does the above command create it??

Kirill Gavrilov's picture

I don't think you can use Visual Studio for building WebAssembly (in a straight-forward way). I've heard that modern Visual Studio provides some tools for cross-compiling for Android platform, but have no idea how it is integrated.

Stefan Lang's picture

If true, you have to supply that information into the ReadMe.md. Visual Studio has supported cross compilation for decades, so that is the first tool any WIndows dev will try. Expecting them to go looking for a different build tool is unrealistic, to say the least.

Besides, why should emcmake cmake create a Visual Studio solution if it can't be used? It is created even without using cmake-gui.

Kirill Gavrilov's picture

Visual Studio has supported cross compilation for decades

I might be wrong - just sharing my understanding.

so that is the first tool any WIndows dev will try.

The world is wider than Visual Studio - even on Windows platform. I didn't have an expensive VS license in my pocket when I've started development more than decade ago, and I've used other tools for building applications for Windows platform at that time.

Besides, why should emcmake cmake create a Visual Studio solution if it can't be used?

I don't know - you may ask these questions to Emscripten or CMake developers.

Stefan Lang's picture

Looks like I was mistaken - the VS solution was created because I picked VS as a generator. But I'm not at all sure this solution will build to wasm. Given the problems I experienced I guess it does not. Once I figured out how to use Ninja as a generator my problems were solved.

Stefan Lang's picture

I managed to build freetype using cmake-gui and Visual-Studio, as I couldn't get cmake to generate windows code! Now I'm trying to build OCCT with the settings you listed in your pseudo build script, but there are two major problems with this:

1. cmake still requires FREETYPE_INCLUDE_DIRS in the generate step, or it will stop with an error, although the configuration was happy with the 3RDPARTY path definitions. Adding this symbol at the configuration step fixes this issue.

2. cmake also requires 3RDPARTY_EGL_INCLUDE_DIR and 3RDPARTY_GLES2_INCLUDE_DIR, even though the build is configured to not use EGL or GLES2! This error persists in the generate step, and it will be harder to fix, because I'm not sure where to get or locate these libraries! The bigger question is, why does cmake insist on finding these paths at all!?

P.S.: I created header mockups egl.h and gl2.h to trick cmake into thinking it found the include dirs, and that way I managed to generate the project and solution files. However, this solution tries to build TKOpenGLES even though I specified it shouldn't be built! Also, the project TKService is trying to include ft2build.h, but cannot find it. What am i missing?

P.P.S.: for some reason cmake-gui insisted on selecting a header instead of a folder for the location of ft2build.h - fixing this solved the latter problem. Moreover, setting BUIL_Module_Visualization to OFF stopped cmake from including TKOpenGLES into the solution, solving the former issue. Is the module Visualization required for Web Assembly? If not, maybe add that info in the documentation. Otherwise, is there any info on what GL lib it is looking for?

P.P.P.S.: Trying to build webgl sample now, but I'm again back to it failing to locate freetype :-( While I do have the freetype-config.cmake file now, the path to that file is not accepted as valid, because find_package compares it to version "". Apparently find_packe didn't fill in the version number to compare to and therefore always fails no matter the input!

Full error message:

CMake Error at CMakeLists.txt:44 (find_package):
Could not find a configuration file for package "freetype" that is
compatible with requested version "".

The following configuration files were considered but not accepted:

D:/OpenCascade/3rdparty/freetype2/lib/cmake/freetype/freetype-config.cmake, version: 2.11.1 (64bit)

Why does find_package not fill in a proper version number? What can i do to provide it or make it find the right one??

Addendum: adding "2" or "2.4" to the find_package command in CMakeLists.txt doesn't help, so it's not the empty version string: there is some other problem preventing find_package from accepting the path!

Addendum 2: since I didn't get any further with freetype, I disabled find_package freetype to see if there are any further issues. Unfortunately there are: I get the exact same error for OpenCASCADEConfig.cmake:

CMake Error at CMakeLists.txt:54 (find_package):
Could not find a configuration file for package "OpenCASCADE" that is
compatible with requested version "".

The following configuration files were considered but not accepted:

D:/OpenCascade/build/occt-make/OpenCASCADEConfig.cmake, version: 7.6.1 (64bit)

Addendum 3: I noticed in the log file that apparently the emscripten build target is set to x86, not x64! Moreover, all the info I could find on emscripten hints that there is no such thing as a 64 bit web assembly (yet). I huess I'll have to rebuild everything for x86 then...

Kirill Gavrilov's picture

P.S.: I created header mockups egl.h and gl2.h to trick cmake into thinking it found the include dirs, and that way I managed to generate the project and solution files.

OpenGL ES / EGL headers are integral part of Emscripten SDK. If CMake reports some errors for them - something is messed up.

As for USE_GLES2 - it is currently non-configurable variable on Emscripten target.

Kirill Gavrilov's picture

Addendum 3: I noticed in the log file that apparently the emscripten build target is set to x86, not x64

Emscripten target architecture is neither x86 nor x64 - it should produce WASM32 binaries that could be loaded by Browsers. 64-bit WASM64 is currently under development and cannot be used.

Stefan Lang's picture

Well, whether x86 or not, for the webgl sample cmake doesn't accept the freetype and OpenCascade -config.cmake files I generated. And the only info provided with the error message is that these files are for x64!

I now wonder whether the problem is that I'm using VS as generator. Unfortunately I didn't manage to make any other generator work! I've installed ninja, but no matter what I do, emcmake won't accept it as a generator! I've seen you are using ninja. How did you make emscripten recognize it?

Kirill Gavrilov's picture

I've seen you are using ninja.

No, I don't - I'm using "MinGW Makefiles" as described in the sample's Readme ("Activate also MinGW when building sample on Windows host") and by adm/scripts/wasm_build.bat / wasm_sample_build.bat scripts.

ninja is used by Docker scripts created by other developers (they are running in virtual Linux environment). Have no idea if ninja could be used on Windows or not.

Stefan Lang's picture

I finally made the build work with Ninja after finding crucial info here: https://badlydrawnrod.github.io/posts/2020/05/19/emcmake-with-emscripten/

The webgl sample works now.

To sum it up, the lessons learned here are:
1. don't use outdated versions of 3rd party libs; disregard OCTT documentation pointing at older versions!
2. follow the advice at https://badlydrawnrod.github.io/posts/2020/05/19/emcmake-with-emscripten/ to set up cmake for emscripten; this is the best source I've found relating to Windows
3. don't use Visual Studio as a generator for cmake: while it appears to be working, it creates a Visual Studio solution that does not build to web assembly, and therefore is unusable! Ninja does work if you install it as described at the link above
4. the exact paths used for 3rdparty libs need to be checked carefully. Apparently they can move between versions and therefore make scripts posted on any website may not match the paths you need for your installation. While this isn't a big problem, it isn't always clear what path is expected for what variable; I found cmake-gui to be a very useful tool just to figure out which paths work and which don't, even when I do everything else on the command line.
5. the correct command for starting a web server (at least on my Windows installation) is: python -m http.server 8080; I've seen many variations posted on the web though, so this may be just another thing that you need to find out for yourself.

Kirill Gavrilov's picture

I finally made the build work with Ninja

Now, it would be great writing some step-by-step article for other newcomers if you still have a courage :).

Stefan Lang's picture

I'm a bit under pressure right now, but I do intend to write a step by step guide for my colleages anyway. Expect to hear from me in a week or two.

Stefan Lang's picture

On a sidenote, while I'm trying to do something useful, how do you write the statistics into the view? I have checked all the code but couldn't find the part that does this! Alternately, is there some other way to display a message in a popup or similar on top of the view?

That question may be silly, but anything web-related is outside my expertise, and if there's some simple way to invoke a javascript message box from the cpp code I simply don't know about it. (and a quick search didn't reveal anything useful - but I might not be using good key words to search)

Kirill Gavrilov's picture

how do you write the statistics into the view?

Rendering statistics is displayed by

  myView->ChangeRenderingParams().ToShowStats = true;

line in WebGL sample. It will work only in case when OCCT was built with FreeType library enabled.

Stefan Lang's picture

If you are CMake guru

Far from it - it's been 30 years since I last looked into makefiles. I never had to for a very long time. I am using them now because I must, not by choice,

That said, it's quite possible I did not issue the build and install commands exactly like you think they should, and maybe that is the reason why I'm missing these .cmake files. The problem I have is that my ancient (and very outdated) knowledge of *ix and makefiles in combination with the rather superficial instructions on the emscrpten website are really hard to combine into a working build process! It doesn't help that few of the instructions I could find anywhere can be used literally, either because they are not actual commands, or because the commands posted assume settings or environments I do not have, and I lack the knowledge to find out what is missing.

Stefan Lang's picture

Sorry for posting a third reply, but I think I noticed the reason why there is no file freetype-config.cmake: the instructions for building FreeType provided by the Opencascade documentation (see https://dev.opencascade.org/doc/overview/html/build_upgrade_building_3rd... ) point to a repository at sourceforge which doesn't have a CMakelists.txt file, and requires make to build, not cmake. Without cmake, there can't be a *config.cmake file! It's impossible.

I've found a different repo here:

https://gitlab.freedesktop.org/freetype/freetype.git

This one does have CMakeLists.txt files all the way back to version 2.5.5 and it can be built with cmake. However, even that version does not create the desired file, only CPackConfig.cmake and CPackSourceConfig.cmake. These are clearly not the same.

I am still wondering where I'm supposed to get these files, or otherwise how I'm supposed to build the sample with emsdk so that it finds the appropriate path! None of the variable names suggested so far seem to have any effect.

P.S.:

I now realized that while version 2.5.5 from the abovementioned source contains a CMakeLists.txt file, it does not contain the neccessary code to create the *config.cmake files that I'm missing! Starting from version 2.7, these files are generated. Therefore it is necessary to switch to a newer version (and then you might as well use the sourceforge link which does provide CMakeLists.txt files at least for the newer versions.

This resolves my problem with regard to FreeType, and I hope I won't need as much type when the webGL sample goes looking for an opencascade-config.cmake file - because I haven't spotted any such file!

Also this raises the question why the binary distributions of OCCT do supply FreeType version 2.5.5!? That was the main reason why I even tried using this old version - I wanted to avoid compatibility issues!

In any case it could be really useful to others if the OpenCascade documentation made a point on the 3rdparty lib versions required to actually make a source level rebuild!

Kirill Gavrilov's picture

I've found a different repo here:

While references to sourceforge looks clumsy, I don't see much difference - just tried downloading freetype-2.11.1.tar.xz from there and archive contains CMakeLists.txt.
I guess "Mandatory products: FreeType 2.4.10 - 2.5.3" in documentation might look confusing - FreeType doesn't break API often, so there is no point building an outdated version of this library.

Paul BIGEON's picture

Hi

Another issue regarding the compilation that I've had, using :

OCCT 7.6.0 dev
Emscripten 1.39.7 ( MinGW 4.6.2-32bit )

Compiling seems ok, but when it comes to linking :

Anyone found a way to get through this one ?

Thanks,

Paul

Kirill Gavrilov's picture

Is there some reason for using an old Emscripten 1.x branch instead of Emscripten 2.x (opened since August '2020)?
And where MinGW 4.6.2-32bit comes from? I see only mingw-7.1.0-64bit in Emscripten SDK.

Don't recall "unknown suffix" error, so cannot help here...

Paul BIGEON's picture

Hi and thank you for your reply,

I'm using my already existing Emscripten environment based on the Qt for WebAssembly requirements.
This might be the issue now that you point that out ...

I'll give it a try with updated Emscripten and MinGW.

Regards,

Paul

Paul BIGEON's picture

Hi and thanks for your prompt reply,

I did use the Qt 5.15.2 for WebAssembly tutorial and the recommended version for Emscripten is 1.39.7 ...

I Installed and activated Emscripten 2.0.23 and mingw-7.1.0-64bit as you indicated, and now the process goes a bit further, yet it splashes this new error :

A bit of search on the github issues indicates that it could be linked to newest version of Emscripten not handling things the same as they used to in previous releases.

I'll have a go at different versions and see which one can fit then ...

Regards,

Paul

Kirill Gavrilov's picture

My guess is that you are trying now to build the Sample without clean rebuild of OCCT libraries...

I haven't updated Emscripten for a while, so my currently installed version is older - it is 2.0.11. But I hope that they haven't broken something with newer updates (apart from useless deprecation that can be seen in your log)...

Paul BIGEON's picture

It worked with 2.0.11, I did not rebuilt OCCT ...

Well the sample is built and linked correctly now.

Thanks for your help as always !

Regards

Paul

Vrainy Z's picture

Hi

I have another issue about the compilation.

Using:

  • OCCT 7.6.0
  • cmake version 3.22.1
  • emsdk 2.0.11

Command:

     emcmake cmake .. -DOpenCASCADE_DIR=E:\package\opencascade\opencascade-install\cmake -G "Visual Studio 16 2019" -A x64

Error:

CMakeOutput.log:

 The target system is: Emscripten - 1 - x86_64
The host system is: Windows - 10.0.19043 - AMD64

Edited files

webgl/CMakeLists.txt

# FreeType
set(freetype_DIR E:/package/thrid-part/freetype-2.5.5)
# find_package(freetype REQUIRED NO_DEFAULT_PATH)
# if(freetype_FOUND)
#   message (STATUS "Using FreeType from \"${freetype_DIR}\"" )
# else()
#   message(WARNING "Could not find FreeType, please set freetype_DIR variable." )
# endif()

# Open CASCADE Technology
find_package(OpenCASCADE REQUIRED)

 Emscripten.cmake

# Advertise Emscripten as a 32-bit platform (as opposed to
# CMAKE_SYSTEM_PROCESSOR=x86_64 for 64-bit platform), since some projects (e.g.
# OpenCV) use this to detect bitness.

# set(CMAKE_SYSTEM_PROCESSOR x86)
set(CMAKE_SYSTEM_PROCESSOR x86_64)

I found a similar error. link.

You are trying to build a x86 (32bit) program saying that you want to link it to a 64bit library. Then the mess.
Just check the script that you are using to trigger the build, there lies the problem :)

I edited "set(CMAKE_SYSTEM_PROCESSOR x86)" to "set(CMAKE_SYSTEM_PROCESSOR x86_64)" in Emscripten.cmake, but it didn't work.

Anyone found a way to get through this one ?

Thanks,

Vrainy

Kirill Gavrilov's picture

     emcmake cmake .. -DOpenCASCADE_DIR=E:\package\opencascade\opencascade-install\cmake -G "Visual Studio 16 2019" -A x64

I never heard about CMake supporting generation of Visual Studio project files crosscompiling using Emscripten SDK. Anyhow, "-A x64" looks broken in options, as WASM64 doesn't yet exist, browsers support only 32-bit WASM32. Don't know how this architecture should be called when specified to CMake though, since this is not x86.

Vrainy Z's picture

Thanks a lot. I compiled successfully using mingw-7.1.0-64bit in emsdk list.

By the way, i never used cmake before, it confused me for a long time.
But it got easier when i figured out how to use cmake-gui with emsdk.

Thanks again for your reply.

Regards,
Vrainy