<html><head></head><body><div class="ydp948a0ff3yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;">
<div>--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</div><div><br></div><div><a href="https://gitlab.freedesktop.org/dbaker/mesa/commit/6a39ee654abbb7c6de79ca138c5ac65108afe864" rel="nofollow" target="_blank">https://gitlab.freedesktop.org/dbaker/mesa/commit/6a39ee654abbb7c6de79ca138c5ac65108afe864</a></div><div><br></div><div>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.</div><div><br></div><div>I think fixing Appveyor failure from here <br></div><div><br></div><div><a href="https://ci.appveyor.com/project/dcbaker/mesa/builds/19646797/job/9maasfn20gh4ktcb" rel="nofollow" target="_blank">https://ci.appveyor.com/project/dcbaker/mesa/builds/19646797/job/9maasfn20gh4ktcb</a></div><div><br></div><div>is as simple as</div><div><br></div><div><span>diff --git a/appveyor.yml b/appveyor.yml<br>index c807905..84d48a7 100644<br>--- a/appveyor.yml<br>+++ b/appveyor.yml<br>@@ -68,7 +68,7 @@ install:<br> - if "%BUILD_SYSTEM%"=="meson" set Path=C:\Python37-x64\Scripts;%Path%<br> - if "%BUILD_SYSTEM%"=="meson" meson --version<br> - if "%BUILD_SYSTEM%"=="meson" cinst -y pkgconfiglite<br>-- if "%BUILD_SYSTEM%"=="meson" call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86<br>+- if "%BUILD_SYSTEM%"=="meson" call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86<br> # Install flex/bison<br> - set WINFLEXBISON_ARCHIVE=win_flex_bison-%WINFLEXBISON_VERSION%.zip<br> - if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile "https://github.com/lexxmark/winflexbison/releases/download/v%WINFLEXBISON_VERSION%/%WINFLEXBISON_ARCHIVE%"</span><br></div><div><br></div><div><br></div>
</div><div id="yahoo_quoted_1528048953" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Monday, October 29, 2018, 9:06:08 PM GMT+2, Dylan Baker <dylan@pnwbakers.com> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Quoting Jose Fonseca (2018-10-25 04:02:42)<br clear="none">> On 21/10/18 20:54, Liviu Prodea wrote:<br clear="none">> > 1. When using Meson 0.48.x both -Dc_args -Dcpp_args and -Db_vscrt <br clear="none">> > methods of selecting the CRT are ineffective on changing the CRT from MD <br clear="none">> > to MT resulting in build failure if LLVM is built with MT CRT. This <br clear="none">> > issue persists from last time I tested this WIP branch. However if MT <br clear="none">> > built LLVM is indeed unsupported unlike Scons I am OK with it as long as <br clear="none">> > it is documented.<br clear="none">> <br clear="none">> > 2. Assuming no 1 has been worked around (we have LLVM built with MD CRT <br clear="none">> > available), LLVM JIT-ed drivers like llvmpipe and swr cannot be selected <br clear="none">> > despite resulted opengl32.dll being around 20MB and swr DLLs being built <br clear="none">> > as well only when expected. Tested with GPU Caps Viewer (a 32-bit only <br clear="none">> > software), it reports the driver as softpipe OpenGL 3.1 with 248 <br clear="none">> > extensions. Since it's 32-bit app I did not attempt to build swr for <br clear="none">> > this test as it's unsupported for 32-bit apps. It appears this is a <br clear="none">> > really persistent issue as I had it right from the first time I tested <br clear="none">> > this branch. Maybe I need to change the recipe I use to build LLVM so <br clear="none">> > that I use Meson instead of CMake. That would be really unpleasant if it <br clear="none">> > turns out to be the root of this problem. I have this marked as optional <br clear="none">> > and it is on least priority on my TODO list:<br clear="none">> > <br clear="none">> > <a shape="rect" href="https://github.com/pal1000/mesa-dist-win/issues/7 " target="_blank">https://github.com/pal1000/mesa-dist-win/issues/7 </a><br clear="none">> > <<a shape="rect" href="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" target="_blank">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</a>><br clear="none"><br clear="none">As an aside, I noticed that there was a bug in the llvm dependency handler on<br clear="none">windows that was stripping the \\ out of paths, that's been fixed in master now.<br clear="none"><br clear="none">> > 3. More filename parity with Scons similar to<br clear="none">> > <br clear="none">> > <a shape="rect" href="https://gitlab.freedesktop.org/dbaker/mesa/commit/f31d0802da6a20b3878a789bb38c9733c4b0ff24#bda6b0f93966e610f473867639a87adfc5437011 " target="_blank">https://gitlab.freedesktop.org/dbaker/mesa/commit/f31d0802da6a20b3878a789bb38c9733c4b0ff24#bda6b0f93966e610f473867639a87adfc5437011 </a><br clear="none">> > <<a shape="rect" href="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" target="_blank">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</a>><br clear="none">> > <br clear="none">> > - swrAVX-0.dll should be swrAVX.dll<br clear="none">> > <br clear="none">> > - swrAVX2-0.dll should be swrAVX2.dll<br clear="none">> > <br clear="none">> > - libOsmesa.dll should be osmesa.dll<br clear="none">> > <br clear="none">> > 4. opengl32.dll built with Meson depends on shared library z.dll. I have <br clear="none">> > absolutely no problem with this but Jose Fonseca may not like this <br clear="none">> > considering one of his replies from the Scons gles option conversations.<br clear="none">> <br clear="none">> Yep, we really don't want opengl32.dll (or any Mesa based OpenGL ICD) to <br clear="none">> depend on any DLL whatsoever besides Windows standard DLLs (this <br clear="none">> excludes even MSVC runtime, hence the need of /MT /MTd.) This is <br clear="none">> because these drivers will be loaded onto arbitrary process are normally <br clear="none">> installed into C:\Windows\system32, hence any dependencies will need to <br clear="none">> be installed there, so depending on a z.dll could clash with z.dll <br clear="none">> shipped by applications<br clear="none"><br clear="none">To fix the z.dll (and expat.dll), set --default-library=static, this will make<br clear="none">any `library` calls into `static_library` instead of `shared_library`. Mesa<br clear="none">itself doesn't use `library`, we always set `static_library` and<br clear="none">`shared_library` explicitly.<br clear="none"><br clear="none">Dylan<div class="yqt3889019985" id="yqtfd88947"><br clear="none"><br clear="none">> <br clear="none">> Regarding MT vs MTd, I've often considered just always use /MT and side <br clear="none">> step the runtime mismatch issue completely, because I honestly don't <br clear="none">> remember the debug C runtime ever helping debugging anything. In fact, <br clear="none">> we often use cross compiled MinGW binaries for day-to-day development <br clear="none">> anyway.<br clear="none">> <br clear="none">> <br clear="none">> Jose</div></div></div>
</div>
</div></body></html>