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
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
