[Mesa-dev] [Merge request #362]scons: Fix MSYS2 Mingw-w64 build (toolchain=mingw)

2019-03-07 Thread Liviu Prodea 

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

2018-10-31 Thread Liviu Prodea 
 --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=02%7C01%7Cjfonseca%40vmware.com%7C201e146521934e79895f08d63790411a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636757490087355401=KOompJzgdq2B9tawfDqGxxlXOLNqm0EbGRD9%2F9T%2FtHU%3D=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=02%7C01%7Cjfonseca%40vmware.com%7C201e146521934e79895f08d63790411a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636757490087355401=GbvqWeGNGKV1ylnh9X6ddXE2ExtxSSrX8i4nnpX9zyo%3D=0>
> > 
> > - 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

[Mesa-dev] [Mesa-stable][PATCH] Scons: Put to rest zombie texture_float build option

2018-10-23 Thread Liviu Prodea 
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

2018-10-21 Thread Liviu Prodea 
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.

2018-10-19 Thread Liviu Prodea 







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)
>      '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.Appe

Re: [Mesa-dev] [PATCH] scons: Remove gles option.

2018-10-19 Thread Liviu Prodea 



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 =

Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

2018-10-19 Thread Liviu Prodea 
 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 unresolved externals
>  > scons: *** [build\windows-x86\me

Re: [Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

2018-10-18 Thread Liviu Prodea 
 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=02%7C01%7Cjfonseca%40vmware.com%7C6abda784079c42d71b3408d634f19a8a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636754609623099529=%2BVbAVSllQsctFyx%2FaDxlLT3r4bxUNU1Ee%2BC%2FpV6A65A%3D=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=02%7C01%7Cjfonseca%40vmware.com%7C6abda784079c42d71b3408d634f19a8a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636754609623099529=F0LF4N3y9Z4WkpESF816hPBeFgisVhYmKqSOI57hZDo%3D=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=02%7C01%7Cjfonseca%40vmware.com%7C6abda784079c42d71b3408d634f19a8a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636754609623109534=%2BaoNGi49NqOqTduaS9GUh69nV8hxWI7

[Mesa-dev] Scons/GLES: shared_glapi and osmesa link failure

2018-10-18 Thread Liviu Prodea 
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

2018-10-11 Thread Liviu Prodea 
 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 * __cdecl llvm::c

[Mesa-dev] [Mesa-stable] [PATCH] Scons: swr: fix LLVM >= 7 build

2018-10-06 Thread Liviu Prodea 
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)

Re: [Mesa-dev] Meson-windows v4 (9/21/2018 rebase): LLVM linking problems

2018-10-03 Thread Liviu Prodea 
 
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

2018-10-02 Thread Liviu Prodea 
 





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

2018-10-02 Thread Liviu Prodea 
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

2018-08-26 Thread Liviu Prodea 
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

2018-08-24 Thread Liviu Prodea 
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

2018-07-19 Thread Liviu Prodea 
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

2018-07-10 Thread Liviu Prodea 
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

2018-07-10 Thread Liviu Prodea 
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

2018-04-28 Thread Liviu Prodea 
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

2017-09-20 Thread Liviu Prodea 
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