--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 <dy...@pnwbakers.com> 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.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. > > Yep, we really don't want opengl32.dll (or any Mesa based OpenGL ICD) to > depend on any DLL whatsoever besides Windows standard DLLs (this > excludes even MSVC runtime, hence the need of /MT /MTd.) This is > because these drivers will be loaded onto arbitrary process are normally > installed into C:\Windows\system32, hence any dependencies will need to > be installed there, so depending on a z.dll could clash with z.dll > shipped by applications To fix the z.dll (and expat.dll), set --default-library=static, this will make any `library` calls into `static_library` instead of `shared_library`. Mesa itself doesn't use `library`, we always set `static_library` and `shared_library` explicitly. Dylan > > Regarding MT vs MTd, I've often considered just always use /MT and side > step the runtime mismatch issue completely, because I honestly don't > remember the debug C runtime ever helping debugging anything. In fact, > we often use cross compiled MinGW binaries for day-to-day development > anyway. > > > Jose
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
