Hello Fréderic,

As you may know, building OSMesa on scons/MinGW is quite broken. The problem is in the 'swr' module.

I am working with George Kyriazis (from Intel) on validating his patch. In this activity, Emil Velikov from Mesa has stressed that it is strongly recommended to 'upstream' the other patches I use to successfully build OSMesa. As I am not the author, I'm not sure how I can help so I'm writing to let you know because, except George's patch, the patches I use come from this repo.

If you are interested, I've made a lot of enhancements to the osmesa-install.sh script to enable fully automated, flexible and detailed building on scons/MinGW. This weekend I completed an AppVeyor CI environment, using the osmesa-install script, to support George's patch build testing. You can see details at the corresponding Git Repo.

Cheers,

Hi,

I am building OS Mesa to use it in VTK.

VTK build complain about position independent code not enabled (see below). How should I enable this on OS Mesa?

[ 13%] Linking C shared library ../../../lib/libvtkglew-9.1.so
/usr/bin/ld: /home/martin/Dev/jzy3d/external/osmesa/lib/libOSMesa32.a(libmesaswr_la-rdtsc_buckets.o): relocation R_X86_64_TPOFF32 against hidden symbol `tlsThreadId' can not be used when making a shared object
/usr/bin/ld: /home/martin/Dev/jzy3d/external/osmesa/lib/libOSMesa32.a(osmesa.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompilé avec -fPIC
/usr/bin/ld : échec de l'édition de liens finale : bad value
collect2: error: ld returned 1 exit status
make[2]: *** [ThirdParty/glew/vtkglew/CMakeFiles/glew.dir/build.make:98 : lib/libvtkglew-9.1.so.9.1.0] Erreur 1
make[1]: *** [CMakeFiles/Makefile2:7738 : ThirdParty/glew/vtkglew/CMakeFiles/glew.dir/all] Erreur 2
make: *** [Makefile:136 : all] Erreur 2

thanks

Would it make sense to add these directives to the script so one can suppress the numerous warnings when building with clang ?

MACOSX_DEPLOYMENT_TARGET=10.<X> -mmacosx-version-min=10.<X> -isysroot /Developer/SDKs/MacOSX10.<X>.sdk

Just to add a little background...

If I'm building with Qt (QtCreator), Qt clang spec will automatically set my macosx-version-min to SDK 10.8. So if I build my osmesa libs on my current version of OSX (SDK 10.12) using osmesa-install as is and then use the libs in my application build, I'll generate numerous warnings that the SDK for the compiled version of of the libs is 10.12 which is different from the Qt compiled application at SDK 10.8.
Cheers,

@rodlie says in #9 that we should maybe upgrade the Mesa version used by https://github.com/devernay/osmesa-install

But:

• Mesa dropped autoconf support with 19.0, supporting only meson and SCons builds. SCons support was also dropped in 21.1. Mangled OSMesa support was only accessible from autoconf and SCons, but it is just a matter of adding -DUSE_MGL_NAMESPACE to CPPFLAGS, so it should still be possible to easily get mangled OSMesa using meson.
• Source support for GL symbol mangling support was dropped with 19.2.2 (commit, relnotes). Re-adding it means we would have to maintain that large patch.
• The legacy swrast driver was dropped in Mesa 21.0.0.

Options are:

• Upgrade to 18.3.6 (DONE) and check if there are still thread-safety issues. I remember those issues were hard to spot, but maybe a Natron project with heavy multithreading and multiple shadertoy plugins doing software rendering would be a good test.
• Reapply the mangling patch to a more recent Mesa, which may require some work if functions were re-added to gl.h glext.h or glx.h since 18.3.6.

In the mean time:

• I upgraded OSMesa to 18.3.6, it still needs more testing in Natron.

Honestly, I think I'm fine with keeping 17.1.10, which is the safest option, since @rodlie already did the work of upgrading the scons buildsystem for that version (#9).

If 18.3.6 works too, we can upgrade to that version.

Please comment on that issue to give your thoughts.

Thanks for this tool!

I suggest to change documentation to inform the user that it is better to let this installer download and build LLVM with export LLVM_BUILD=1. It took me a while before understanding it can do it on its own.

On Ubuntu 20, I can only sudo apt-get install llvm-7, or llvm-8, llvm-9, llvm-10. LLVM website does not provide info on how to install earlier versions of LLVM. The LLVM shell installer does not support earlier versions as well.

I tried working with llvm-9 as it is mentionned in console output but it provides the same result than the other : build fail as follow.

/usr/lib/llvm-9/include/llvm/ADT/ArrayRef.h:101:37: warning: initializing ‘llvm::ArrayRef<llvm::Value*>::Data’ from ‘std::initializer_list<llvm::Value*>::begin’ does not extend the lifetime of the underlying array [-Winit-list-lifetime]
  CXX      rasterizer/common/libmesaswr_la-os.lo
  CXX      rasterizer/common/libmesaswr_la-rdtsc_buckets.lo
  CXX      rasterizer/common/libmesaswr_la-swr_assert.lo
make[5]: *** [Makefile:2888 : libmesaswr_la-swr_shader.lo] Erreur 1
make[5]: *** Attente des tâches non terminées....
make[5] : on quitte le répertoire « /home/martin/Dev/jzy3d/external/osmesa-install/mesa-18.3.6/src/gallium/drivers/swr »
make[4]: *** [Makefile:1892 : all] Erreur 2
make[4] : on quitte le répertoire « /home/martin/Dev/jzy3d/external/osmesa-install/mesa-18.3.6/src/gallium/drivers/swr »
make[3]: *** [Makefile:635 : all-recursive] Erreur 1
make[3] : on quitte le répertoire « /home/martin/Dev/jzy3d/external/osmesa-install/mesa-18.3.6/src/gallium »
make[2]: *** [Makefile:896 : all-recursive] Erreur 1
make[2] : on quitte le répertoire « /home/martin/Dev/jzy3d/external/osmesa-install/mesa-18.3.6/src »
make[1]: *** [Makefile:681 : all] Erreur 2
make[1] : on quitte le répertoire « /home/martin/Dev/jzy3d/external/osmesa-install/mesa-18.3.6/src »
make: *** [Makefile:693 : all-recursive] Erreur 1

Hi! Thanks a lot for your install script! It's even tuned for MacOS, which is very helpful for me.

I'm wondering... can you render Vulkan into osmesa? And what about OpenCL? If affirmative, is it possible to build osmesa with OpenGL, Vulkan and OpenCL, at the same time? Will Vulkan and OpenCL function names be mangled too?

Thanks!!