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
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):
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
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
- bui
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
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
htt
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 add
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, Oc
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 m
lf 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
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
en 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-g
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
> w
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, 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
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 indee
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 1
-%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:
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\;%me
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.
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 d
21 matches
Mail list logo
