[Mesa-dev] [Merge request #362]scons: Fix MSYS2 Mingw-w64 build (toolchain=mingw)
This patch is based on https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-mesa/link-ole32.patch but with tweaks to avoid MSVC build break when applied. There is a caveat to this patch though, it doesn't help swr driver. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson windows v5 (10/19/2018) review
--default_library=static indeed solves the zlib and expat dependency so I tweaked my build script to do just that, As for the LLVM linking problems I think I finally understand what's going on. llvm-wrap option always links LLVM dynamically and ignores or it is incompatible with -Dshared-llvm=false. llvm-wrap could be coerced into supporting CRT override in Meson <= 0.47.2 using c_args and cpp_args but Meson >= 0.48.0 doesn't override it anymore, maybe this was unsupported to begin with. It's too bad that Appveyor VS toolchain update in https://gitlab.freedesktop.org/dbaker/mesa/commit/6a39ee654abbb7c6de79ca138c5ac65108afe864 failed so bad leading a premature build failure otherwise the CRT mismatch error I see when LLVM is built with MT would have been replicated by Appveyor with a small difference, it would be a MD<->MTd mismatch instead of a MD<->MT. I think fixing Appveyor failure from here https://ci.appveyor.com/project/dcbaker/mesa/builds/19646797/job/9maasfn20gh4ktcb is as simple as diff --git a/appveyor.yml b/appveyor.yml index c807905..84d48a7 100644 --- a/appveyor.yml +++ b/appveyor.yml @@ -68,7 +68,7 @@ install: - if "%BUILD_SYSTEM%"=="meson" set Path=C:\Python37-x64\Scripts;%Path% - if "%BUILD_SYSTEM%"=="meson" meson --version - if "%BUILD_SYSTEM%"=="meson" cinst -y pkgconfiglite -- if "%BUILD_SYSTEM%"=="meson" call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 +- if "%BUILD_SYSTEM%"=="meson" call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 # Install flex/bison - set WINFLEXBISON_ARCHIVE=win_flex_bison-%WINFLEXBISON_VERSION%.zip - if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile "https://github.com/lexxmark/winflexbison/releases/download/v%WINFLEXBISON_VERSION%/%WINFLEXBISON_ARCHIVE%"; On Monday, October 29, 2018, 9:06:08 PM GMT+2, Dylan Baker wrote: Quoting Jose Fonseca (2018-10-25 04:02:42) > On 21/10/18 20:54, Liviu Prodea wrote: > > 1. When using Meson 0.48.x both -Dc_args -Dcpp_args and -Db_vscrt > > methods of selecting the CRT are ineffective on changing the CRT from MD > > to MT resulting in build failure if LLVM is built with MT CRT. This > > issue persists from last time I tested this WIP branch. However if MT > > built LLVM is indeed unsupported unlike Scons I am OK with it as long as > > it is documented. > > > 2. Assuming no 1 has been worked around (we have LLVM built with MD CRT > > available), LLVM JIT-ed drivers like llvmpipe and swr cannot be selected > > despite resulted opengl32.dll being around 20MB and swr DLLs being built > > as well only when expected. Tested with GPU Caps Viewer (a 32-bit only > > software), it reports the driver as softpipe OpenGL 3.1 with 248 > > extensions. Since it's 32-bit app I did not attempt to build swr for > > this test as it's unsupported for 32-bit apps. It appears this is a > > really persistent issue as I had it right from the first time I tested > > this branch. Maybe I need to change the recipe I use to build LLVM so > > that I use Meson instead of CMake. That would be really unpleasant if it > > turns out to be the root of this problem. I have this marked as optional > > and it is on least priority on my TODO list: > > > > https://github.com/pal1000/mesa-dist-win/issues/7 > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpal1000%2Fmesa-dist-win%2Fissues%2F7&data=02%7C01%7Cjfonseca%40vmware.com%7C201e146521934e79895f08d63790411a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636757490087355401&sdata=KOompJzgdq2B9tawfDqGxxlXOLNqm0EbGRD9%2F9T%2FtHU%3D&reserved=0> As an aside, I noticed that there was a bug in the llvm dependency handler on windows that was stripping the \\ out of paths, that's been fixed in master now. > > 3. More filename parity with Scons similar to > > > > https://gitlab.freedesktop.org/dbaker/mesa/commit/f31d0802da6a20b3878a789bb38c9733c4b0ff24#bda6b0f93966e610f473867639a87adfc5437011 > > > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdbaker%2Fmesa%2Fcommit%2Ff31d0802da6a20b3878a789bb38c9733c4b0ff24%23bda6b0f93966e610f473867639a87adfc5437011&data=02%7C01%7Cjfonseca%40vmware.com%7C201e146521934e79895f08d63790411a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636757490087355401&sdata=GbvqWeGNGKV1ylnh9X6ddXE2ExtxSSrX8i4nnpX9zyo%3D&reserved=0> > > > > - swrAVX-0.dll should be swrAVX.dll > > > > - swrAVX2-0.dll should be swrAVX2.dll > > > > - libOsmesa.dll should be osmesa.
[Mesa-dev] [Mesa-stable][PATCH] Scons: Put to rest zombie texture_float build option
I found a remnant of texture_float build option that wasn't removed in https://gitlab.freedesktop.org/mesa/mesa/commit/66673bef941af344314fe9c91cad8cd330b245eb This patch removes it. --- common.py | 3 --- 1 file changed, 3 deletions(-) diff --git a/common.py b/common.py index f4f2bb4..be3ccfc 100644 --- a/common.py +++ b/common.py @@ -105,9 +105,6 @@ def AddOptions(opts): opts.Add(BoolOption('debug', 'DEPRECATED: debug build', 'yes')) opts.Add(BoolOption('profile', 'DEPRECATED: profile build', 'no')) opts.Add(BoolOption('quiet', 'DEPRECATED: profile build', 'yes')) - opts.Add(BoolOption('texture_float', - 'enable floating-point textures and renderbuffers', - 'no')) opts.Add(BoolOption('swr', 'Build OpenSWR', 'no')) if host_platform == 'windows': opts.Add('MSVC_VERSION', 'Microsoft Visual C/C++ version') ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Meson windows v5 (10/19/2018) review
1. When using Meson 0.48.x both -Dc_args -Dcpp_args and -Db_vscrt methods of selecting the CRT are ineffective on changing the CRT from MD to MT resulting in build failure if LLVM is built with MT CRT. This issue persists from last time I tested this WIP branch. However if MT built LLVM is indeed unsupported unlike Scons I am OK with it as long as it is documented. 2. Assuming no 1 has been worked around (we have LLVM built with MD CRT available), LLVM JIT-ed drivers like llvmpipe and swr cannot be selected despite resulted opengl32.dll being around 20MB and swr DLLs being built as well only when expected. Tested with GPU Caps Viewer (a 32-bit only software), it reports the driver as softpipe OpenGL 3.1 with 248 extensions. Since it's 32-bit app I did not attempt to build swr for this test as it's unsupported for 32-bit apps. It appears this is a really persistent issue as I had it right from the first time I tested this branch. Maybe I need to change the recipe I use to build LLVM so that I use Meson instead of CMake. That would be really unpleasant if it turns out to be the root of this problem. I have this marked as optional and it is on least priority on my TODO list: https://github.com/pal1000/mesa-dist-win/issues/7 3. More filename parity with Scons similar to https://gitlab.freedesktop.org/dbaker/mesa/commit/f31d0802da6a20b3878a789bb38c9733c4b0ff24#bda6b0f93966e610f473867639a87adfc5437011 - swrAVX-0.dll should be swrAVX.dll - swrAVX2-0.dll should be swrAVX2.dll - libOsmesa.dll should be osmesa.dll 4. opengl32.dll built with Meson depends on shared library z.dll. I have absolutely no problem with this but Jose Fonseca may not like this considering one of his replies from the Scons gles option conversations. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Remove gles option.
On Friday, October 19, 2018, 6:04:28 PM GMT+3, Liviu Prodea wrote: I think I found autotools build equivalent for gles=y. It is --enable-shared-glapi. And the docs say it is needed to support applications that mix OpenGL and OpenGL ES: https://www.mesa3d.org/egl.html and Meson equivalent is shared-glapi: https://gitlab.freedesktop.org/mesa/mesa/blob/master/meson_options.txt Apparently Scons is the only build system that has gles=no default. The other 2 actively maintained build systems have both equivalent options default to true. - On Friday, October 19, 2018, 4:15:48 PM GMT+3, Brian Paul wrote: Reviewed-by: Brian Paul On 10/19/2018 06:33 AM, Jose Fonseca wrote: > It's broken, and WGL state tracker is always built with GLES support > noawadays. > --- > common.py | 2 -- > src/SConscript | 7 --- > src/gallium/state_trackers/osmesa/SConscript | 4 +--- > src/gallium/state_trackers/wgl/SConscript | 4 +--- > src/gallium/targets/libgl-gdi/SConscript | 6 -- > src/gallium/targets/libgl-xlib/SConscript | 6 -- > src/mapi/glapi/SConscript | 6 +- > src/mapi/shared-glapi/SConscript | 9 + > src/mesa/SConscript | 4 +--- > src/mesa/drivers/osmesa/SConscript | 4 +--- > 10 files changed, 6 insertions(+), 46 deletions(-) > > diff --git a/common.py b/common.py > index 113fc7f5c12..f4f2bb44c1c 100644 > --- a/common.py > +++ b/common.py > @@ -99,8 +99,6 @@ def AddOptions(opts): > 'enable static code analysis where available', 'no')) > opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no')) > opts.Add('toolchain', 'compiler toolchain', default_toolchain) > - opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support', > - 'no')) > opts.Add(BoolOption('llvm', 'use LLVM', default_llvm)) > opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp >(swrast)', > 'no')) > diff --git a/src/SConscript b/src/SConscript > index 95ea061c4bb..54350a9cdcc 100644 > --- a/src/SConscript > +++ b/src/SConscript > @@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']]) > if env['platform'] != 'windows': > SConscript('loader/SConscript') > > -# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are > not > -# used. libgl-xlib and libgl-gdi adapt themselves to use the targets defined > -# in mapi/glapi-shared/SConscript. mesa/SConscript also adapts itself to > -# enable OpenGL ES support. > SConscript('mapi/glapi/gen/SConscript') > SConscript('mapi/glapi/SConscript') > > @@ -61,8 +57,5 @@ if not env['embedded']: > if env['platform'] == 'haiku': > SConscript('egl/SConscript') > > - if env['gles']: > - SConscript('mapi/shared-glapi/SConscript') > - > SConscript('gallium/SConscript') > > diff --git a/src/gallium/state_trackers/osmesa/SConscript > b/src/gallium/state_trackers/osmesa/SConscript > index f5519f13762..be67d0fe739 100644 > --- a/src/gallium/state_trackers/osmesa/SConscript > +++ b/src/gallium/state_trackers/osmesa/SConscript > @@ -14,10 +14,8 @@ if env['platform'] == 'windows': > env.AppendUnique(CPPDEFINES = [ > 'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers > 'WIN32_LEAN_AND_MEAN', # >http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx > + '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared > __declspec(dllimport) > ]) > - if not env['gles']: > - # prevent _glapi_* from being declared __declspec(dllimport) > - env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS']) > > st_osmesa = env.ConvenienceLibrary( > target ='st_osmesa', > diff --git a/src/gallium/state_trackers/wgl/SConscript > b/src/gallium/state_trackers/wgl/SConscript > index a7fbb07a89a..bbf5ebd9764 100644 > --- a/src/gallium/state_trackers/wgl/SConscript > +++ b/src/gallium/state_trackers/wgl/SConscript > @@ -14,10 +14,8 @@ env.AppendUnique(CPPDEFINES = [ > '_GDI32_', # prevent wgl* being declared __declspec(dllimport) > &
Re: [Mesa-dev] [PATCH] scons: Remove gles option.
I think I found autotools build equivalent for gles=y. It is --enable-shared-glapi. And the docs say it is needed to support applications that mix OpenGL and OpenGL ES: https://www.mesa3d.org/egl.html - On Friday, October 19, 2018, 4:15:48 PM GMT+3, Brian Paul wrote: Reviewed-by: Brian Paul On 10/19/2018 06:33 AM, Jose Fonseca wrote: > It's broken, and WGL state tracker is always built with GLES support > noawadays. > --- > common.py | 2 -- > src/SConscript | 7 --- > src/gallium/state_trackers/osmesa/SConscript | 4 +--- > src/gallium/state_trackers/wgl/SConscript | 4 +--- > src/gallium/targets/libgl-gdi/SConscript | 6 -- > src/gallium/targets/libgl-xlib/SConscript | 6 -- > src/mapi/glapi/SConscript | 6 +- > src/mapi/shared-glapi/SConscript | 9 + > src/mesa/SConscript | 4 +--- > src/mesa/drivers/osmesa/SConscript | 4 +--- > 10 files changed, 6 insertions(+), 46 deletions(-) > > diff --git a/common.py b/common.py > index 113fc7f5c12..f4f2bb44c1c 100644 > --- a/common.py > +++ b/common.py > @@ -99,8 +99,6 @@ def AddOptions(opts): > 'enable static code analysis where available', 'no')) > opts.Add(BoolOption('asan', 'enable Address Sanitizer', 'no')) > opts.Add('toolchain', 'compiler toolchain', default_toolchain) > - opts.Add(BoolOption('gles', 'EXPERIMENTAL: enable OpenGL ES support', > - 'no')) > opts.Add(BoolOption('llvm', 'use LLVM', default_llvm)) > opts.Add(BoolOption('openmp', 'EXPERIMENTAL: compile with openmp >(swrast)', > 'no')) > diff --git a/src/SConscript b/src/SConscript > index 95ea061c4bb..54350a9cdcc 100644 > --- a/src/SConscript > +++ b/src/SConscript > @@ -42,10 +42,6 @@ env.Append(CPPPATH = ["#" + env['build_dir']]) > if env['platform'] != 'windows': > SConscript('loader/SConscript') > > -# When env['gles'] is set, the targets defined in mapi/glapi/SConscript are > not > -# used. libgl-xlib and libgl-gdi adapt themselves to use the targets defined > -# in mapi/glapi-shared/SConscript. mesa/SConscript also adapts itself to > -# enable OpenGL ES support. > SConscript('mapi/glapi/gen/SConscript') > SConscript('mapi/glapi/SConscript') > > @@ -61,8 +57,5 @@ if not env['embedded']: > if env['platform'] == 'haiku': > SConscript('egl/SConscript') > > - if env['gles']: > - SConscript('mapi/shared-glapi/SConscript') > - > SConscript('gallium/SConscript') > > diff --git a/src/gallium/state_trackers/osmesa/SConscript > b/src/gallium/state_trackers/osmesa/SConscript > index f5519f13762..be67d0fe739 100644 > --- a/src/gallium/state_trackers/osmesa/SConscript > +++ b/src/gallium/state_trackers/osmesa/SConscript > @@ -14,10 +14,8 @@ if env['platform'] == 'windows': > env.AppendUnique(CPPDEFINES = [ > 'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers > 'WIN32_LEAN_AND_MEAN', # >http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx > + '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared > __declspec(dllimport) > ]) > - if not env['gles']: > - # prevent _glapi_* from being declared __declspec(dllimport) > - env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS']) > > st_osmesa = env.ConvenienceLibrary( > target ='st_osmesa', > diff --git a/src/gallium/state_trackers/wgl/SConscript > b/src/gallium/state_trackers/wgl/SConscript > index a7fbb07a89a..bbf5ebd9764 100644 > --- a/src/gallium/state_trackers/wgl/SConscript > +++ b/src/gallium/state_trackers/wgl/SConscript > @@ -14,10 +14,8 @@ env.AppendUnique(CPPDEFINES = [ > '_GDI32_', # prevent wgl* being declared __declspec(dllimport) > 'BUILD_GL32', # declare gl* as __declspec(dllexport) in Mesa headers > 'WIN32_LEAN_AND_MEAN', # >http://msdn2.microsoft.com/en-us/library/6dwk3a1z.aspx > + '_GLAPI_NO_EXPORTS', # prevent _glapi_* from being declared > __declspec(dllimport) > ]) > -if not env['gles']: > - # prevent _glapi_* from being declared __declspec(dllimport) > - env.Append(CPPDEFINES = ['_GLAPI_NO_EXPORTS']) > > wgl = env.ConvenienceLibrary( > target ='wgl', > diff --git a/src/gallium/targets/libgl-gdi/SConscript > b/src/gallium/targets/libgl-gdi/SConscript > index 132cb73358d..94feca24ef3 100644 > --- a/src/gallium/targets/libgl-gdi/SConscript > +++ b/src/gallium/targets/libgl-gdi/SConscript > @@ -48,12 +48,6 @@ else: > > env['no_import_lib'] = 1 > > -# when GLES is enabled, gl* and _glapi_* belong to bridge_glapi and > -# shared_glapi respectively > -if env['gles']: > - env.Prepend(LIBPATH = [shared_glapi.dir]) > - glapi = [bridge_glapi, 'libglapi'] > - > opengl32 = env.Shar
Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure
I agree on the fact it is suspicious that libglapi,dll was asked for considering glapi is built as a static library part of opengl32.dll by default. If I understood correctly what gles variable does, it turns glapi into a shared library and that's all there is to it and probably as a side effect GLESv1 and GLESv2 are forced to become shared libraries too. I don't know what this guy did in Blender3D to trigger that, it is mostly suspicious. I asked him what he did to trigger it here https://github.com/pal1000/mesa-dist-win/issues/8#issuecomment-394626971 but he actually never answered to it. The conversation sidetracked and the trigger was never mentioned. I wasn't able to replicate the error he encountered but as soon as I built glapi as a shared library he said everything was "fine". I looked at Mesa code and I found these interactions between osmesa, gles build variable and glapi in Scons build: https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/osmesa/SConscript#L32 https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/state_trackers/osmesa/SConscript#L18 --- On Friday, October 19, 2018, 12:33:21 AM GMT+3, Jose Fonseca wrote: I still can't make much sense of that github issue thread. Applications on Windows use opengl32.dll for acceleration, not libEGL/libGLESv1/libGLESv2 as these are not provided by the OS. The only place you see these DLLs are things like GLES -> D3D11/GL translators like Angle. So the "missing glapi.dll" is a red herring IMO: the solution is not to somehow the build the glapi.dll but rather build mesa so it's never needed. Which is what scons does by default. What Meson does or not by default I don't know. It might provide all those DLLs, but that doesn't change the fact that windows applications will target opengl32.dll for accelleration. Jose On 18/10/18 15:46, Liviu Prodea wrote: > Well, all this started in that Github issue thread. That guy @elkhalafy > was using llvmpipe to get Blender 2.80 to work on his system with > unsupported (too old) iGPU. I don't know what he did but it resulted in > Blender failing with missing libglapi.dll. So I researched about how to > build it and it led me to this build variable gles of type boolean. When > set to true it builds glapi as a shared library named libglapi.dll. It > is also a requirement to build libGLESv1_CM.dll and libGLESv2.dll which > only get build when selecting all build targets or probably I wasn't > able to find the right target(s). > > A Meson build approximation is -Dgles1=true -Dgles2=true which builds > all 3 DLLs and it is default unlike in Scons case, > > On Thursday, October 18, 2018, 3:08:11 PM GMT+3, Jose Fonseca > wrote: > > > I don't know what gles=y entails anymore, but if it's broken we should > simply remove it. > > That said, our WGL GLES contexts, via WGL_EXT_create_context_es2_profile > extension, even without gles=y option. > > So what exactly are you looking for here? > > Jose > > On 18/10/18 13:02, Liviu Prodea wrote: > > scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa > > > > Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and > > object build\windows-x86\mesa\drivers\osmesa\osmesa.exp > > osmesa.obj : error LNK2001: unresolved external symbol > > __imp___glapi_check_multithread > > osmesa.obj : error LNK2001: unresolved external symbol > > __imp___glapi_get_proc_address > > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_set_context > > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_set_dispatch > > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_set_nop_handler > > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_new_nop_table > > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_Context > > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_get_dispatch_table_size > > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_get_context > > mesa.lib(remap.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_add_dispatch > > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_get_dispatch > > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol > > __imp___glapi_Dispatch > > build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120: > > 12 unresolve
Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure
Well, all this started in that Github issue thread. That guy @elkhalafy was using llvmpipe to get Blender 2.80 to work on his system with unsupported (too old) iGPU. I don't know what he did but it resulted in Blender failing with missing libglapi.dll. So I researched about how to build it and it led me to this build variable gles of type boolean. When set to true it builds glapi as a shared library named libglapi.dll. It is also a requirement to build libGLESv1_CM.dll and libGLESv2.dll which only get build when selecting all build targets or probably I wasn't able to find the right target(s). A Meson build approximation is -Dgles1=true -Dgles2=true which builds all 3 DLLs and it is default unlike in Scons case, On Thursday, October 18, 2018, 3:08:11 PM GMT+3, Jose Fonseca wrote: I don't know what gles=y entails anymore, but if it's broken we should simply remove it. That said, our WGL GLES contexts, via WGL_EXT_create_context_es2_profile extension, even without gles=y option. So what exactly are you looking for here? Jose On 18/10/18 13:02, Liviu Prodea wrote: > scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa > > Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and > object build\windows-x86\mesa\drivers\osmesa\osmesa.exp > osmesa.obj : error LNK2001: unresolved external symbol > __imp___glapi_check_multithread > osmesa.obj : error LNK2001: unresolved external symbol > __imp___glapi_get_proc_address > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > __imp___glapi_set_context > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > __imp___glapi_set_dispatch > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > __imp___glapi_set_nop_handler > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > __imp___glapi_new_nop_table > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > __imp___glapi_Context > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > __imp___glapi_get_dispatch_table_size > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > __imp___glapi_get_context > mesa.lib(remap.obj) : error LNK2001: unresolved external symbol > __imp___glapi_add_dispatch > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol > __imp___glapi_get_dispatch > mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol > __imp___glapi_Dispatch > build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120: > 12 unresolved externals > scons: *** [build\windows-x86\mesa\drivers\osmesa\osmesa.dll] Error 1120 > st_osmesa.lib(osmesa.obj) : error LNK2001: unresolved external symbol > __imp___glapi_get_proc_address > mesa.lib(st_manager.obj) : error LNK2001: unresolved external symbol > __imp___glapi_check_multithread > mesa.lib(vbo_exec_api.obj) : error LNK2001: unresolved external symbol > __imp___glapi_set_dispatch > mesa.lib(glthread.obj) : error LNK2001: unresolved external symbol > __imp___glapi_set_context > mesa.lib(context.obj) : error LNK2001: unresolved external symbol > __imp___glapi_get_dispatch_table_size > mesa.lib(remap.obj) : error LNK2001: unresolved external symbol > __imp___glapi_add_dispatch > build\windows-x86\gallium\targets\osmesa\osmesa.dll : fatal error > LNK1120: 6 unresolved externals > scons: *** [build\windows-x86\gallium\targets\osmesa\osmesa.dll] Error 1120 > scons: building terminated because of errors. > > This is a long standing issue. First reported here: > > https://lists.freedesktop.org/archives/mesa-users/2012-May/000431.html > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fmesa-users%2F2012-May%2F000431.html&data=02%7C01%7Cjfonseca%40vmware.com%7C6abda784079c42d71b3408d634f19a8a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636754609623099529&sdata=%2BVbAVSllQsctFyx%2FaDxlLT3r4bxUNU1Ee%2BC%2FpV6A65A%3D&reserved=0> > > Encountered again in 2016: > > https://lists.freedesktop.org/archives/mesa-users/2016-March/001142.html > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fmesa-users%2F2016-March%2F001142.html&data=02%7C01%7Cjfonseca%40vmware.com%7C6abda784079c42d71b3408d634f19a8a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636754609623099529&sdata=F0LF4N3y9Z4WkpESF816hPBeFgisVhYmKqSOI57hZDo%3D&reserved=0> > > and finally by myself in early 2018: > > https://bugs.freedesktop.org/show_bug.cgi?id=106843 > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D106843&data=02%7C01%7Cjfonseca%40vmware.com%7C6abda784079c42d71b3408d634f19a8a%7Cb391
[Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure
scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and object build\windows-x86\mesa\drivers\osmesa\osmesa.exp osmesa.obj : error LNK2001: unresolved external symbol __imp___glapi_check_multithread osmesa.obj : error LNK2001: unresolved external symbol __imp___glapi_get_proc_address mesa.lib(context.obj) : error LNK2001: unresolved external symbol __imp___glapi_set_context mesa.lib(context.obj) : error LNK2001: unresolved external symbol __imp___glapi_set_dispatch mesa.lib(context.obj) : error LNK2001: unresolved external symbol __imp___glapi_set_nop_handler mesa.lib(context.obj) : error LNK2001: unresolved external symbol __imp___glapi_new_nop_table mesa.lib(context.obj) : error LNK2001: unresolved external symbol __imp___glapi_Context mesa.lib(context.obj) : error LNK2001: unresolved external symbol __imp___glapi_get_dispatch_table_size mesa.lib(context.obj) : error LNK2001: unresolved external symbol __imp___glapi_get_context mesa.lib(remap.obj) : error LNK2001: unresolved external symbol __imp___glapi_add_dispatch mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol __imp___glapi_get_dispatch mesa.lib(api_loopback.obj) : error LNK2001: unresolved external symbol __imp___glapi_Dispatch build\windows-x86\mesa\drivers\osmesa\osmesa.dll : fatal error LNK1120: 12 unresolved externals scons: *** [build\windows-x86\mesa\drivers\osmesa\osmesa.dll] Error 1120 st_osmesa.lib(osmesa.obj) : error LNK2001: unresolved external symbol __imp___glapi_get_proc_address mesa.lib(st_manager.obj) : error LNK2001: unresolved external symbol __imp___glapi_check_multithread mesa.lib(vbo_exec_api.obj) : error LNK2001: unresolved external symbol __imp___glapi_set_dispatch mesa.lib(glthread.obj) : error LNK2001: unresolved external symbol __imp___glapi_set_context mesa.lib(context.obj) : error LNK2001: unresolved external symbol __imp___glapi_get_dispatch_table_size mesa.lib(remap.obj) : error LNK2001: unresolved external symbol __imp___glapi_add_dispatch build\windows-x86\gallium\targets\osmesa\osmesa.dll : fatal error LNK1120: 6 unresolved externals scons: *** [build\windows-x86\gallium\targets\osmesa\osmesa.dll] Error 1120 scons: building terminated because of errors. This is a long standing issue. First reported here: https://lists.freedesktop.org/archives/mesa-users/2012-May/000431.html Encountered again in 2016: https://lists.freedesktop.org/archives/mesa-users/2016-March/001142.html and finally by myself in early 2018: https://bugs.freedesktop.org/show_bug.cgi?id=106843 Eric Engestrom suggested me to try the work in progress Meson build for Windows. Unfortunately it has other issues which prevents it from being ready for prime time as I reported here: https://gitlab.freedesktop.org/dbaker/mesa/issues/2 I stumbled upon this issue when dealing with this feature request: https://github.com/pal1000/mesa-dist-win/issues/8 I was able to get that feature done but with a terribly ugly hack which should not even be mentioned. This issue affects the linking between osmesa and shared_glapi so the build command that triggers it can be as short as: scons gles=y or scons gles=y osmesa to get to the linking failure as quickly as possible stripping targets that build successfully. I tried to make a proper fix but it is beyond my skill level, despite having the gut feeling the fix could be something surprisingly simple. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] Scons: swr: fix LLVM >= 7 build
I looked at bugs 108308 and 108310 and tested the attached patch https://bugs.freedesktop.org/attachment.cgi?id=141969 It seams to be a lot better than patchwork series 50108: - it doesn't have build system specific code; - no extra libraries so that Meson limitation regarding dependency modules addition based on dependency version is no longer hit; - no LLVM modules requirements changes. Which means no build break with Scons or Meson and linking break between osmesa and swr. Needs testing with LLVM 6.0.1. On Sunday, October 7, 2018, 6:35:26 AM GMT+3, Hota, Alok wrote: #yiv8833351369 #yiv8833351369 -- _filtered #yiv8833351369 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8833351369 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv8833351369 {panose-1:0 0 0 0 0 0 0 0 0 0;}#yiv8833351369 #yiv8833351369 p.yiv8833351369MsoNormal, #yiv8833351369 li.yiv8833351369MsoNormal, #yiv8833351369 div.yiv8833351369MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New serif;}#yiv8833351369 a:link, #yiv8833351369 span.yiv8833351369MsoHyperlink {color:blue;text-decoration:underline;}#yiv8833351369 a:visited, #yiv8833351369 span.yiv8833351369MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8833351369 span.yiv8833351369EmailStyle17 {font-family:sans-serif;color:#1F497D;}#yiv8833351369 .yiv8833351369MsoChpDefault {font-size:10.0pt;} _filtered #yiv8833351369 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv8833351369 div.yiv8833351369WordSection1 {}#yiv8833351369 Thanks for the patch! And thanks for describing the linking error; we will look further into it. This patch should be a good starting point for resolving it. -Alok From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org]On Behalf Of Liviu Prodea Sent: Saturday, October 6, 2018 3:09 PM To: mesa-dev@lists.freedesktop.org Cc: mesa-sta...@lists.freedesktop.org Subject: [Mesa-dev] [Mesa-stable] [PATCH] Scons: swr: fix LLVM >= 7 build Well I am more used with the merge / pull request model of sending patches so I am going to link it instead of inlining: https://raw.githubusercontent.com/pal1000/mesa-dist-win/master/patches/upstream/scons-swr-llvm7.patch This patch depends onseries 50108 to be effective but it can be safely merged either before or after it. Unfortunately this patch doesn't help osmesa linking with swr when using llvm >= 7 which is also an issue unaddressed by series 50108. If you try to build both swr and osmesa together when using LLVM 7.0 with Scons you get this after applying this patch otherwise would be way more unresolved symbols. This patch cuts 41 unresolved symbols resulting in successful build when not building osmesa. Generating code Finished generating code Finished generating code Finished generating code Archiving build\windows-x86_64\gallium\drivers\swr\swr.lib ... Linking build\windows-x86_64\gallium\targets\osmesa\osmesa.dll ... Linking build\windows-x86_64\gallium\targets\libgl-gdi\opengl32.dll ... Creating library build\windows-x86_64\gallium\targets\osmesa\osmesa.lib and object build\windows-x86_64\gallium\targets\osmesa\osmesa.exp Creating library build\windows-x86_64\gallium\targets\libgl-gdi\opengl32.lib and object build\windows-x86_64\gallium\targets\libgl-gdi\opengl32.exp swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createPGOInstrumentationUseLegacyPass(class llvm::StringRef)" (?createPGOInstrumentationUseLegacyPass@llvm@@YAPEAVModulePass@1@VStringRef@1@@Z) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createPGOInstrumentationGenLegacyPass(void)" (?createPGOInstrumentationGenLegacyPass@llvm@@YAPEAVModulePass@1@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::FunctionPass * __cdecl llvm::createPGOMemOPSizeOptLegacyPass(void)" (?createPGOMemOPSizeOptLegacyPass@llvm@@YAPEAVFunctionPass@1@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createPGOIndirectCallPromotionLegacyPass(bool,bool)" (?createPGOIndirectCallPromotionLegacyPass@llvm@@YAPEAVModulePass@1@_N0@Z) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createInstrProfilingLegacyPass(struct llvm::InstrProfOptions const &)" (?createInstrProfilingLegacyPass@llvm@@YAPEAVModulePass@1@AEBUInstrProfOptions@1@@Z) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "public: static struct llvm::GCOVOptions __cdecl llvm::GCOVOptions::getDefault(void)" (?getDefault@GCOVOptions@llvm@@SA?AU12@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::FunctionPass * __cde
[Mesa-dev] [Mesa-stable] [PATCH] Scons: swr: fix LLVM >= 7 build
Well I am more used with the merge / pull request model of sending patches so I am going to link it instead of inlining: https://raw.githubusercontent.com/pal1000/mesa-dist-win/master/patches/upstream/scons-swr-llvm7.patch This patch depends on series 50108 to be effective but it can be safely merged either before or after it. Unfortunately this patch doesn't help osmesa linking with swr when using llvm >= 7 which is also an issue unaddressed by series 50108. If you try to build both swr and osmesa together when using LLVM 7.0 with Scons you get this after applying this patch otherwise would be way more unresolved symbols. This patch cuts 41 unresolved symbols resulting in successful build when not building osmesa. Generating code Finished generating code Finished generating code Finished generating code Archiving build\windows-x86_64\gallium\drivers\swr\swr.lib ... Linking build\windows-x86_64\gallium\targets\osmesa\osmesa.dll ... Linking build\windows-x86_64\gallium\targets\libgl-gdi\opengl32.dll ... Creating library build\windows-x86_64\gallium\targets\osmesa\osmesa.lib and object build\windows-x86_64\gallium\targets\osmesa\osmesa.exp Creating library build\windows-x86_64\gallium\targets\libgl-gdi\opengl32.lib and object build\windows-x86_64\gallium\targets\libgl-gdi\opengl32.exp swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createPGOInstrumentationUseLegacyPass(class llvm::StringRef)" (?createPGOInstrumentationUseLegacyPass@llvm@@YAPEAVModulePass@1@VStringRef@1@@Z) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createPGOInstrumentationGenLegacyPass(void)" (?createPGOInstrumentationGenLegacyPass@llvm@@YAPEAVModulePass@1@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::FunctionPass * __cdecl llvm::createPGOMemOPSizeOptLegacyPass(void)" (?createPGOMemOPSizeOptLegacyPass@llvm@@YAPEAVFunctionPass@1@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createPGOIndirectCallPromotionLegacyPass(bool,bool)" (?createPGOIndirectCallPromotionLegacyPass@llvm@@YAPEAVModulePass@1@_N0@Z) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createInstrProfilingLegacyPass(struct llvm::InstrProfOptions const &)" (?createInstrProfilingLegacyPass@llvm@@YAPEAVModulePass@1@AEBUInstrProfOptions@1@@Z) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "public: static struct llvm::GCOVOptions __cdecl llvm::GCOVOptions::getDefault(void)" (?getDefault@GCOVOptions@llvm@@SA?AU12@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::FunctionPass * __cdecl llvm::createBoundsCheckingLegacyPass(void)" (?createBoundsCheckingLegacyPass@llvm@@YAPEAVFunctionPass@1@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createGCOVProfilerPass(struct llvm::GCOVOptions const &)" (?createGCOVProfilerPass@llvm@@YAPEAVModulePass@1@AEBUGCOVOptions@1@@Z) build\windows-x86_64\gallium\targets\libgl-gdi\opengl32.dll : fatal error LNK1120: 8 unresolved externals scons: *** [build\windows-x86_64\gallium\targets\libgl-gdi\opengl32.dll] Error 1120 swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createPGOInstrumentationUseLegacyPass(class llvm::StringRef)" (?createPGOInstrumentationUseLegacyPass@llvm@@YAPEAVModulePass@1@VStringRef@1@@Z) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createPGOInstrumentationGenLegacyPass(void)" (?createPGOInstrumentationGenLegacyPass@llvm@@YAPEAVModulePass@1@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::FunctionPass * __cdecl llvm::createPGOMemOPSizeOptLegacyPass(void)" (?createPGOMemOPSizeOptLegacyPass@llvm@@YAPEAVFunctionPass@1@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createPGOIndirectCallPromotionLegacyPass(bool,bool)" (?createPGOIndirectCallPromotionLegacyPass@llvm@@YAPEAVModulePass@1@_N0@Z) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::ModulePass * __cdecl llvm::createInstrProfilingLegacyPass(struct llvm::InstrProfOptions const &)" (?createInstrProfilingLegacyPass@llvm@@YAPEAVModulePass@1@AEBUInstrProfOptions@1@@Z) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "public: static struct llvm::GCOVOptions __cdecl llvm::GCOVOptions::getDefault(void)" (?getDefault@GCOVOptions@llvm@@SA?AU12@XZ) swr.lib(JitManager.obj) : error LNK2001: unresolved external symbol "class llvm::FunctionPass * __cdecl llvm::createBoundsCheckingLegacyPass(void)" (?createBoundsCheckingLegacyPass@llvm@@YAPEAVFunctionPass@1@XZ) swr.li
Re: [Mesa-dev] Meson-windows v4 (9/21/2018 rebase): LLVM linking problems
Automatic wrap with llvm-config does get the version right so it has to be something else. I usually build LLVM myself like this: cd llvm-7.0.0.src & md buildsys-x86 & cd buildsys-x86 & cmake -G "Ninja" -Thost=x64 -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_CRT_RELEASE=MT -DLLVM_ENABLE_RTTI=1 -DLLVM_ENABLE_TERMINFO=OFF -DCMAKE_INSTALL_PREFIX=../x86 .. Followed by ninja install LLVM 6.0.1 was also affected I also downloaded and tried LLVM 5.0.1 MTd x86 build that Appveyor uses and built Mesa with Meson 0.47.2, used the llvm-wrap included in Mesa codebase and passed the exact same c_args and cpp_args as Appveyor. Unfortunately I was greeted by an assertion failure as soon as I began testing it so I don't know if it has llvmpipe active or not. Mesa3D build config - Meson 0.48.0 C:\Software\DEVELO~1\projects\mesa\Py3\Scripts\meson.exe x86 --backend=vs2017 --buildtype=plain -Db_vscrt=mt -Dllvm-wrap=llvm Omission of -Dllvm=true doesn't seam to make any difference as long as I have -Dllvm-wrap in, as I tried both ways. -Db_vscrt appears to be non functional as it still builds with the defaults /MD /O2.Changing buildtype from plain to release makes no difference as well. It still does a /MD /O2 build. On Wednesday, October 3, 2018, 12:26:33 AM GMT+3, Dylan Baker wrote: Quoting Liviu Prodea (2018-10-02 14:05:09) > > > > > > > On Tuesday, October 2, 2018, 8:08:39 PM GMT+3, Dylan Baker > wrote: > > > Quoting Liviu Prodea (2018-10-02 08:08:41) > > Made a comprehensive test of this patch series and I still stumbled upon > > some > > big problems: > > > > 1. Automatic LLVM linking via llvm-config if used by adding LLVM bin folder > to > > PATH results in build failure with 'llvm-c/Core.h' not found in src/gallium/ > > auxiliary/gallivm/lp_bld.h. Appveyor CI from > > https://ci.appveyor.com/project/ > > dcbaker/mesa didn't encounter this as it is using llvm-wrap option. > > It's possible that llvm-config wrapping on windows is broken atm, it is on > macos, I have pull request open, > https://github.com/mesonbuild/meson/pull/4283. > I'll see if that fixes windows as well, or if we need some more work there. > > > > 2. Even if build succeeds with LLVM linked via llvm-wrap and everything > looking > > good at first glance, llvmpipe and swr if it was built cannot be selected. > > GALLIUM_DRIVER variable has no effect. You only get softpipe despite > > opengl32.dll file looking big enough and swrAVX-0.dll and swrAVX2-0,dll > > being > > generated when expected. Even when having LLVM built dynamically to avoid > > /MD > > to /MT override warnings and building Mesa3D with default c_args and > > cpp_args > > this issue is still in effect. > > > > 3. Meson 0.48.0 doesn't pass the /MT or /MTd c_args and cpp_args for some > > unexplained reasons which leads to build failure if LLVM is not built with / > MD. > > > Meson 0.48 has added a new option to allow you to pick which crt you want: > > https://mesonbuild.com/Release-notes-for-0-48-0.html# > toggles-for-build-type-optimization-and-vcrt-type > > The list of options are here: > > https://mesonbuild.com/Builtin-options.html#base-options > > I'll test and see if I can add b_vscrt=from_builtype to the default options > without requiring a bumpt ot 0.48.0 for the whole project. > > Dylan > > --- > > -Db_vscrt=mt doesn't help. I use LLVM built with /MT. I still get a bunch of > > error LNK2038: mismatch detected for 'RuntimeLibrary': value > 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' What is your -Dbuildtype set to? > > As for why I don't get llvmpipe and swr to work when Mesa3D and LLVM CRT > linking match when using manual llvm-wrap option I think the explanation is > highlighted by Appveyor: > https://ci.appveyor.com/project/dcbaker/mesa/build/job/k02oo9qfyuxaxpgi?fullLog=true#L221 > Looking at line 224, LLVN version is reported as undefined. This can't be > good and I am seeing this as well. Automatic wrap with llvm-config doesn't > have this problem. Unfortunately it fails to find the headers as already > reported. In that appveyor the fact that version is undefined is harmless, it's because the `project()` definition in the wrap doesn't define a version, the `declare_dependency()` does that. If you're seeing that with llvm-config then that's bad, and may be related to the pull request I mentioned above. Are you building LLVM yourself, or getting it from somewhere? Dylan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Meson-windows v4 (9/21/2018 rebase): LLVM linking problems
On Tuesday, October 2, 2018, 8:08:39 PM GMT+3, Dylan Baker wrote: Quoting Liviu Prodea (2018-10-02 08:08:41) > Made a comprehensive test of this patch series and I still stumbled upon some > big problems: > > 1. Automatic LLVM linking via llvm-config if used by adding LLVM bin folder to > PATH results in build failure with 'llvm-c/Core.h' not found in src/gallium/ > auxiliary/gallivm/lp_bld.h. Appveyor CI from https://ci.appveyor.com/project/ > dcbaker/mesa didn't encounter this as it is using llvm-wrap option. It's possible that llvm-config wrapping on windows is broken atm, it is on macos, I have pull request open, https://github.com/mesonbuild/meson/pull/4283. I'll see if that fixes windows as well, or if we need some more work there. > 2. Even if build succeeds with LLVM linked via llvm-wrap and everything > looking > good at first glance, llvmpipe and swr if it was built cannot be selected. > GALLIUM_DRIVER variable has no effect. You only get softpipe despite > opengl32.dll file looking big enough and swrAVX-0.dll and swrAVX2-0,dll being > generated when expected. Even when having LLVM built dynamically to avoid /MD > to /MT override warnings and building Mesa3D with default c_args and cpp_args > this issue is still in effect. > > 3. Meson 0.48.0 doesn't pass the /MT or /MTd c_args and cpp_args for some > unexplained reasons which leads to build failure if LLVM is not built with > /MD. Meson 0.48 has added a new option to allow you to pick which crt you want: https://mesonbuild.com/Release-notes-for-0-48-0.html#toggles-for-build-type-optimization-and-vcrt-type The list of options are here: https://mesonbuild.com/Builtin-options.html#base-options I'll test and see if I can add b_vscrt=from_builtype to the default options without requiring a bumpt ot 0.48.0 for the whole project. Dylan --- -Db_vscrt=mt doesn't help. I use LLVM built with /MT. I still get a bunch oferror LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' As for why I don't get llvmpipe and swr to work when Mesa3D and LLVM CRT linking match when using manual llvm-wrap option I think the explanation is highlighted by Appveyor: https://ci.appveyor.com/project/dcbaker/mesa/build/job/k02oo9qfyuxaxpgi?fullLog=true#L221 Looking at line 224, LLVN version is reported as undefined. This can't be good and I am seeing this as well. Automatic wrap with llvm-config doesn't have this problem. Unfortunately it fails to find the headers as already reported. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Meson-windows v4 (9/21/2018 rebase): LLVM linking problems
Made a comprehensive test of this patch series and I still stumbled upon some big problems: 1. Automatic LLVM linking via llvm-config if used by adding LLVM bin folder to PATH results in build failure with 'llvm-c/Core.h' not found in src/gallium/auxiliary/gallivm/lp_bld.h. Appveyor CI from https://ci.appveyor.com/project/dcbaker/mesa didn't encounter this as it is using llvm-wrap option. 2. Even if build succeeds with LLVM linked via llvm-wrap and everything looking good at first glance, llvmpipe and swr if it was built cannot be selected. GALLIUM_DRIVER variable has no effect. You only get softpipe despite opengl32.dll file looking big enough and swrAVX-0.dll and swrAVX2-0,dll being generated when expected. Even when having LLVM built dynamically to avoid /MD to /MT override warnings and building Mesa3D with default c_args and cpp_args this issue is still in effect. 3. Meson 0.48.0 doesn't pass the /MT or /MTd c_args and cpp_args for some unexplained reasons which leads to build failure if LLVM is not built with /MD. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Meson-windows v4: Potential path too long during zlib subproject build when using MsBuild backend
See https://gitlab.freedesktop.org/dbaker/mesa/issues/1 for details. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 47/49] appveyor: use msbuild instead of ninja
While this works for a CI like Appveyor it doesn't work on a bit more complex build environment where paths can be longer. Unfortunately MsBuild doesn't handle well the situation when paths exceed MAX_PATH. Here is an example: - Mesa source code is in C:\Software\DEVELO~1\projects\mesa\mesa - build system is generated under source directory in build\windows-x86_64. When the build gets to zlib, build fails with paths too long error notably due to the overly long folder PATH: C:\Software\Development\projects\mesa\mesa\build\windows-x86_64\subprojects\zlib-1.2.11\Windows resource for file 'subprojects__zlib-1.2.11__win32_zlib1.rc'@cus\Windows .F68FD0C4.tlog. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 00/49] meson for windows
Review for Meson windows support v2 1. osmesa Scons build doesn't use lib prefix on windows platform. I don't know much of cygwin though.Sent a merge request to ensure parity - https://gitlab.freedesktop.org/dbaker/mesa/merge_requests/2 2. Problem linking LLVM. a. The LLVM wrap example in the docs doesn't specify from what llvm-config command that libraries array comes from. With Scons this is documented in the code itself https://gitlab.freedesktop.org/mesa/mesa/blob/master/scons/llvm.py#L106 b. I wrote a llvm wrap generator based on that documentation making the assumption the needed libraries are the same as with Scons. Unfortunately I get static - dynamic link mismatches for all LLVM libraries. Maybe I am doing something wrong or I need to build LLVM differently (hopefully mot) or it's a bug. llvm wrap meson.build project('llvm', ['cpp']) cpp = meson.get_compiler('cpp') _deps = [] _search = join_paths(meson.current_source_dir(), '../../../llvm/x64/lib') foreach d : ['LLVMIRReader', 'LLVMAsmParser', 'LLVMX86Disassembler', 'LLVMX86AsmParser', 'LLVMX86CodeGen', 'LLVMGlobalISel', 'LLVMSelectionDAG', 'LLVMAsmPrinter', 'LLVMDebugInfoCodeView', 'LLVMDebugInfoMSF', 'LLVMCodeGen', 'LLVMScalarOpts', 'LLVMInstCombine', 'LLVMTransformUtils', 'LLVMBitWriter', 'LLVMX86Desc', 'LLVMMCDisassembler', 'LLVMX86Info', 'LLVMX86AsmPrinter', 'LLVMX86Utils', 'LLVMMCJIT', 'LLVMExecutionEngine', 'LLVMTarget', 'LLVMAnalysis', 'LLVMProfileData', 'LLVMRuntimeDyld', 'LLVMObject', 'LLVMMCParser', 'LLVMBitReader', 'LLVMMC', 'LLVMCore', 'LLVMBinaryFormat', 'LLVMSupport', 'LLVMDemangle'] _deps += cpp.find_library(d, dirs : _search) endforeach ext_llvm = declare_dependency( include_directories : include_directories(join_paths(meson.current_source_dir(), '../../../llvm/x64/include')), dependencies : _deps, version : '6.0.1', ) irbuilder_h = files(join_paths(meson.current_source_dir(), '../../../llvm/x64/include/llvm/IR/IRBuilder.h')) LLVM build config: cmake -G "Ninja" -Thost=x64 -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_CRT_RELEASE=MT -DLLVM_ENABLE_RTTI=1 -DLLVM_ENABLE_TERMINFO=OFF -DCMAKE_INSTALL_PREFIX=../x64 Mesa3D build config command: C:\Software\DEVELO~1\projects\mesa\Py3\python.exe C:\Software\DEVELO~1\projects\mesa\Py3\Scripts\meson.py . .\build\windows-x86_64 --backend=ninja --buildtype=release -Dllvm-wrap=llvm -Dosmesa=gallium ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 48/48] tests/vma: fix build with MSVC
For the series https://patchwork.freedesktop.org/series/44596/ Updating Meson from 0.46.1 to 0.47.0 sorted the build system generating failure posted about earlier and eventually got a successful build. Note that I am using Python 3.7. Though I remember getting very similar errors with Python 3.6.5. There is an alternative patch for patch 45 in the series somewhere on this mailing list:https://lists.freedesktop.org/archives/mesa-dev/2018-July/199683.html As an extra it bumps the requirement of Meson to 0.46.0 but now I wonder if it's enough. Also I noticed that after build was done some dlls have names slightly different than Scons build's counterparts. I think they should be consistent: - OSMesa-8.dll instead osmesa.dll (osmesa gallium, didn't try building osmesa classic);- glapi-0.dll instead of libglapi.dll;- GLESv1_CM-1.dll instead of libGLESv1_CM.dll;- GLESv2-2.dll instead of libGLESv2.dll;- also I think expat-1.dll can be just expat.dll. On the bright side bug 106843 only affects Scons. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 48/48] tests/vma: fix build with MSVC
I tried the Meson Windows branch posted by Dylan Baker now available on Freedesktop Gitlab with default configuration but unfortunately it didn't work for me. Build script @set mesa=C:\Software\Development\projects\mesa @SET PATH=C:\Software\Development\Git\cmd\;%mesa%\Python\;%mesa%\Py3\;%mesa%\Py3\Scripts\;%mesa%\flexbison\;%mesa%\ninja\;%mesa%\pkgconfig\;%PATH% @call "%ProgramFiles% (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64 @cd %mesa%\mesa @set buildcmd=%mesa%\Py3\python.exe %mesa%\Py3\Scripts\meson.py . .\build\windows-x86_64 @RD /S /Q %mesa%\mesa\build\windows-x86_64 @%buildcmd% @cmd Result ** ** ** Visual Studio 2017 Developer Command Prompt v15.7.4 ** Copyright (c) 2017 Microsoft Corporation ** [vcvarsall.bat] Environment initialized for: 'x64' The Meson build system Version: 0.46.1 Source dir: C:\Software\Development\projects\mesa\mesa Build dir: C:\Software\Development\projects\mesa\mesa\build\windows-x86_64-sys Build type: native build Program python found: YES (C:\Software\Development\projects\mesa\Python\python.EXE) Project name: mesa Native C compiler: cl (msvc 19.14.26431) Native C++ compiler: cl (msvc 19.14.26431) Build machine cpu family: x86_64 Build machine cpu: x86_64 Program pkg-config found: YES (C:\Software\Development\projects\mesa\pkgconfig\pkg-config.EXE) Program python2 found: NO Program python found: YES (C:\Software\Development\projects\mesa\Python\python.EXE) Checking for function "bswap32": NO Checking for function "bswap64": NO Checking for function "clz": NO Checking for function "clzll": NO Checking for function "ctz": NO Checking for function "expect": NO Checking for function "ffs": NO Checking for function "ffsll": NO Checking for function "popcount": NO Checking for function "popcountll": NO Checking for function "unreachable": NO Checking if "__attribute__((const))" compiles: NO Checking if "__attribute__((flatten))" compiles: NO Checking if "__attribute__((malloc))" compiles: NO Checking if "__attribute__((pure))" compiles: NO Checking if "__attribute__((unused))" compiles: NO Checking if "__attribute__((warn_unused_result))" compiles: NO Checking if "__attribute__((weak))" compiles: NO Checking if "__attribute__((format(...)))" compiles: NO Checking if "__attribute__((packed))" compiles: NO Checking if "__attribute__((returns_nonnull))" compiles: NO Checking if "__attribute__((visibility(...)))" compiles: NO Checking if "__attribute__((alias(...)))" compiles: NO Checking if "__attribute__((__noreturn__))" compiles: NO Compiler for C supports arguments /wd4018: YES Traceback (most recent call last): File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\compilers\compilers.py", line 799, in compile raise StopIteration StopIteration The above exception was the direct cause of the following exception: Traceback (most recent call last): File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\mesonmain.py", line 364, in run app.generate() File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\mesonmain.py", line 135, in generate self._generate(env) File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\mesonmain.py", line 186, in _generate intr.run() File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreter.py", line 3261, in run super().run() File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreterbase.py", line 215, in run self.evaluate_codeblock(self.ast, start=1) File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreterbase.py", line 239, in evaluate_codeblock raise e File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreterbase.py", line 231, in evaluate_codeblock self.evaluate_statement(cur) File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreterbase.py", line 254, in evaluate_statement return self.evaluate_if(cur) File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreterbase.py", line 307, in evaluate_if self.evaluate_codeblock(i.block) File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreterbase.py", line 239, in evaluate_codeblock raise e File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreterbase.py", line 231, in evaluate_codeblock self.evaluate_statement(cur) File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreterbase.py", line 274, in evaluate_statement return self.evaluate_foreach(cur) File "C:\Software\Development\projects\mesa\Py3\lib\site-packages\mesonbuild\interpreterbase.py",
[Mesa-dev] Building Mesa3D with Meson and MSVC
Short story As maintainer of this project - https://github.com/pal1000/mesa-dist-win where I build Mesa3D drivers with MSVC aided by a script I got a request to build swr AVX512 target. After a bit of research I discovered it's not implemented in Scons build and opened this ticket to track its implementation: https://bugs.freedesktop.org/show_bug.cgi?id=104166 I got no response, but I don't mind because the implementation of the Meson build has swr AVX512. So I worked and refactored my build script to the point where I could attempt building Mesa3D with Meson and MSVC. The result was not good as it can be seen here: --- Using Python Python 3.6.5 from C:\Software\DEVELO~1\projects\mesa\py3\python.exe. WARNING: Python 3.x support is experimental. Install/update python packages (y/n): Begin mesa build. Proceed (y/n):y Do you want to build off-screen rendering drivers (y/n): Build Mesa without LLVM (y=yes/n=quit). Only softpipe and osmesa will be available:y Do you want to clean build (y/n):y ** ** Visual Studio 2017 Developer Command Prompt v15.6.7 ** Copyright (c) 2017 Microsoft Corporation ** [vcvarsall.bat] Environment initialized for: 'x64_x86' Build command: C:\Software\DEVELO~1\projects\mesa\py3\python.exe C:\Software\DEVELO~1\projects\mesa\py3\Scripts\meson.py . .\build\windows-x86 --backend=vs2017 The Meson build system Version: 0.46.0 Source dir: C:\Software\DEVELO~1\projects\mesa\mesa Build dir: C:\Software\DEVELO~1\projects\mesa\mesa\build\windows-x86 Build type: native build Program python found: YES (C:\Software\DEVELO~1\projects\mesa\py3\python.EXE) Project name: mesa Native C compiler: cl (msvc 19.13.26132) Native C++ compiler: cl (msvc 19.13.26132) Build machine cpu family: x86 Build machine cpu: x86 Program pkg-config found: NO meson.build:402:0: ERROR: Program(s) ['pkg-config'] not found or not executable A full log can be found at C:\Software\DEVELO~1\projects\mesa\mesa\build\windows-x86\meson-logs\meson-log.txt Microsoft Windows [Version 10.0.16299.402] (c) 2017 Microsoft Corporation. All rights reserved. C:\Software\DEVELO~1\projects\mesa\mesa> --- It appears it doesn't pick the platform correctly. Maybe I am doing a mistake or implementation it's incomplete. Also noticed -Dplatforms=windows option has been removed recently for some reason. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Scons: LLVM 5.0 support
Signed-off-by: Prodea Alexandru-LiviuBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102318 1 new required library - LLVMBinaryFormat --- diff --git a/scons/llvm.py b/scons/llvm.py index 928fc97..eefb131 100644 --- a/scons/llvm.py +++ b/scons/llvm.py @@ -104,7 +104,27 @@ def generate(env): ]) env.Prepend(LIBPATH = [os.path.join(llvm_dir, 'lib')]) # LIBS should match the output of `llvm-config --libs engine mcjit bitwriter x86asmprinter irreader` - if llvm_version >= distutils.version.LooseVersion('4.0'): + if llvm_version >= distutils.version.LooseVersion('5.0'): + env.Prepend(LIBS = [ + 'LLVMX86Disassembler', 'LLVMX86AsmParser', + 'LLVMX86CodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter', + 'LLVMDebugInfoCodeView', 'LLVMCodeGen', + 'LLVMScalarOpts', 'LLVMInstCombine', + 'LLVMTransformUtils', + 'LLVMBitWriter', 'LLVMX86Desc', + 'LLVMMCDisassembler', 'LLVMX86Info', + 'LLVMX86AsmPrinter', 'LLVMX86Utils', + 'LLVMMCJIT', 'LLVMExecutionEngine', 'LLVMTarget', + 'LLVMAnalysis', 'LLVMProfileData', + 'LLVMRuntimeDyld', 'LLVMObject', 'LLVMMCParser', + 'LLVMBitReader', 'LLVMMC', 'LLVMCore', + 'LLVMSupport', + 'LLVMIRReader', 'LLVMAsmParser', + 'LLVMDemangle', 'LLVMGlobalISel', 'LLVMDebugInfoMSF', + 'LLVMBinaryFormat', + ]) + + elif llvm_version >= distutils.version.LooseVersion('4.0'): env.Prepend(LIBS = [ 'LLVMX86Disassembler', 'LLVMX86AsmParser', 'LLVMX86CodeGen', 'LLVMSelectionDAG', 'LLVMAsmPrinter', ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev