Hi George, You might be interested to know I have set up a CI env on AppVeyor for MinGW builds.
Here is the GitHub repo: https://github.com/trevorsandy/osmesa_mingw_av. Follow the badge in the README to the AppVeyor instance. You can demo your patches quite easily - see the README.md on how to extract source that can be used by my build script. Or change set the version to download and build its source bundle. Perhaps later on I'll add the ability to get build content (tag, branch, commit etc...) directly from Mesa's git repo. The execution script accommodates many options including debug builds. You can also deploy your artifacts ( Note: you must change the secure repos password before attempting to deploy to your cloned repository). Deployment can be helpful in case you want to locally trace your built artifacts. Cheers, On Fri, 29 Sep 2017 at 21:42 Trevor Sandy <trevor.sa...@gmail.com> wrote: > Hi George, > > Sorry but no I have not. There were some warnings during my build but not > the one you list here. > > You can see my log attached > > Cheers, > > Are you able to setup the MinGW environment as I described ? > > On Fri, 29 Sep 2017 at 19:49 Kyriazis, George <george.kyria...@intel.com> > wrote: > >> Trevor, >> >> I hope you can help me with one question that I have about mingw.. >> >> When I am trying to link the swrAVX and swrAVX2 libraries, I am getting >> the following errors: >> >> Warning: corrupt .drectve at end of def file >> Warning: corrupt .drectve at end of def file >> Warning: corrupt .drectve at end of def file >> Warning: corrupt .drectve at end of def file >> Warning: corrupt .drectve at end of def file >> Warning: corrupt .drectve at end of def file >> Warning: corrupt .drectve at end of def file >> >> For pages and pages. Have you come across this? >> >> Thank you! >> >> George >> >> >> On Sep 21, 2017, at 4:29 PM, Trevor Sandy <trevor.sa...@gmail.com> wrote: >> >> Hi George, >> >> No problem. Please proceed at your convenience. >> >> I compared the patch against the master branch and there are quite a bit >> of differences - particularly in rasterizer/common and core. >> >> Perhaps this weekend I'll setup a debug env to better see where/why the >> 'swr' segfault is triggered. >> >> Cheers, >> >> On Thu, 21 Sep 2017 at 18:36 Kyriazis, George <george.kyria...@intel.com> >> wrote: >> >>> Trevor, >>> >>> One problem that existed with minGW was that we had some really big >>> generated file that were causing trouble with minGW compilation. A big >>> part of the patch that I gave you was splitting those generated file apart, >>> to make it easier to the compiler. This was parallel work that, in the >>> meantime, has already made it to mesa master. That will explain the merge >>> issues. The 17.2 or mesa master patch to get minGW working will be much >>> smaller. >>> >>> I’ll have to go and clean it up, to remove the gen file changes that I >>> mentioned above, and give it to you for testing. Is it OK if that waits >>> until next week, since I have to finish up something else this week? >>> >>> Thank you! >>> >>> George >>> >>> >>> On Sep 20, 2017, at 3:11 PM, Trevor Sandy <trevor.sa...@gmail.com> >>> wrote: >>> >>> Hi George, >>> I've attached the patch you sent me. And here is the bug report >>> https://bugs.freedesktop.org/show_bug.cgi?id=101614 for additional >>> details. >>> >>> Indeed the problem seemed linked to the swr rasterizer module. Your >>> patch did address quite a bit of code there - just over 8K lines. >>> >>> On your alternative approach, would it not be necessary to successfully >>> apply the patch on the current master? If you recall, it was only possible >>> to apply your patch on the exact revision on which, I presume, you >>> developed it. I'm working on a diff between your patch applied to 17.1.3 >>> and the current master branch to see what has changed and when. I think >>> there will have to be some additional work to get your patch compatible >>> with the current master branch. >>> >>> Cheers, >>> >>> >>> On Wed, 20 Sep 2017 at 21:00 Kyriazis, George <george.kyria...@intel.com> >>> wrote: >>> >>>> Trevor, >>>> >>>> I had to refresh my memory a little bit. I think that the reason why I >>>> didn’t check the patches in was that I never managed to get the AVX/AVX2 >>>> libraries loaded by the mesa lib. For some reason, loading the symbols >>>> failed. Because I wasn’t able to test it, I didn’t check them in. >>>> >>>> Can you reming me of the patches that I gave you? The thought that we >>>> had before was maybe support MSYS2/MinGW. Since I’m having so much trouble >>>> with it, and linking takes so much time, maybe I can just add those changes >>>> in in an “unsupported” manner. >>>> >>>> Alternatively, you can send the changes out for review to mesa-dev, it >>>> will get reviewed (I can approve), and then I can check-in the change on >>>> your behalf. The reason for this is…. You have the capability of testing >>>> the change, while I don’t (I have problems with it). >>>> >>>> Thanks, >>>> >>>> George >>>> >>>> On Sep 20, 2017, at 12:58 PM, Trevor Sandy <trevor.sa...@gmail.com> >>>> wrote: >>>> >>>> Hi George, >>>> >>>> Hope you are keeping well? >>>> >>>> I've had some time to come back to my MSYS2/MinGW build and was able to >>>> solve my outstanding issue - using libGLU. The problem was simple, it is >>>> not possible to use libGLU.a on Windows. Windows uses libglu32.dll which is >>>> provided (in Windows/System32). >>>> >>>> So at this time, my build is successful and my demo test runs without >>>> issue with swr, llvmpipe and softpipe drivers. Passing swrast at runtime >>>> generates a segfault but this is not a surprise since my build >>>> configuration uses the swr Gallium driver. >>>> >>>> Anyway, I was hoping your patch was in the master branch but it seems >>>> not ? Building master or 17.2 reproduces the original bug. I did try to see >>>> if I could distill the patch and apply it to 17.2 but at 8000 lines, it's a >>>> bit too many changes to have confidence that I won't break something in the >>>> process. >>>> >>>> I've updated the bug ticket so you can see my latest update there. Many >>>> thanks! >>>> >>>> Cheers, >>>> >>>> On Tue, 11 Jul 2017 at 20:13 Kyriazis, George < >>>> george.kyria...@intel.com> wrote: >>>> >>>>> Ok, that makes sense (for the GALLIUM_DRIVER var). >>>>> >>>>> >>>>> George >>>>> >>>>> On Jul 11, 2017, at 1:09 PM, Trevor Sandy <trevor.sa...@gmail.com> >>>>> wrote: >>>>> >>>>> Ok, I'll post something to mesa-dev later on if I'm still blocked. I >>>>> just wanted to let you know how I was progressing. >>>>> >>>>> Indeed, the 'GAL_DRIVER...' code was left over from a test to compare >>>>> between 'export' or 'env.' The actual script code is *env >>>>> GALLIUM_DRIVER="swr" ./osdemo32 image.tga* used to run osdemo32. >>>>> >>>>> Cheers, >>>>> >>>>> On Tue, 11 Jul 2017 at 19:59 Kyriazis, George < >>>>> george.kyria...@intel.com> wrote: >>>>> >>>>>> Hmm, >>>>>> >>>>>> I am not sure why this would be. GLU is part of the mesa disto, and >>>>>> not something that we (at Intel) work on. I don’t even compile it. I >>>>>> would suggest you post something on mesa-dev to see what other people >>>>>> would >>>>>> have to say.. >>>>>> >>>>>> I don’t understand why you set GAL_DRIVER=swr though. The variable >>>>>> is GALLIUM_DRIVER (not GAL_DRIVER), and you would only need to set it >>>>>> before running a program, not while compiling. Or, is maybe GAL_DRIVER >>>>>> another define in your build environment that you use for something else? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> George >>>>>> >>>>>> On Jul 11, 2017, at 11:49 AM, Trevor Sandy <trevor.sa...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Hi George, >>>>>> >>>>>> I'm having some difficulty linking OSdemo32 [Mesa Demo]. Basically, >>>>>> some functions are not included in libGLU.a as the error returned is >>>>>> undefined reference... It's strange because these functions exist in the >>>>>> GLU source and I am building and using a static libGLU library. Here is >>>>>> what the last bit of linking trace looks like: >>>>>> >>>>>> * building Mesa demo... >>>>>> env GAL_DRIVER=swr g++ -DHAVE_FREEGLUT -DFREEGLUT_STATIC -O3 >>>>>> -I/opt/osmesa/include -I../../src/util -include >>>>>> /opt/osmesa/include/GL/gl.h >>>>>> -include /opt/osmesa/include/GL/glu.h -include >>>>>> /opt/osmesa/include/GL/freeglut.h -o osdemo32 osdemo32.c >>>>>> -L/opt/osmesa/lib >>>>>> -losmesa -lfreeglut -lGLU -lz >>>>>> -LC:\Users\Trevor\Projects\osmesa-install\build\install\llvm/lib >>>>>> -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen >>>>>> -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMAsmPrinter >>>>>> -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMCodeGen -lLLVMScalarOpts >>>>>> -lLLVMInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMX86Desc >>>>>> -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils >>>>>> -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMTarget -lLLVMAnalysis >>>>>> -lLLVMProfileData -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser >>>>>> -lLLVMBitReader -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMDemangle -lpsapi >>>>>> -lshell32 -lole32 -luuid >>>>>> C:\msys64\tmp\cc4gd4Lj.o:osdemo32.c:(.text.startup+0xe1): undefined >>>>>> reference to `__imp_gluNewQuadric' >>>>>> C:\msys64\tmp\cc4gd4Lj.o:osdemo32.c:(.text.startup+0x347): undefined >>>>>> reference to `__imp_gluCylinder' >>>>>> C:\msys64\tmp\cc4gd4Lj.o:osdemo32.c:(.text.startup+0x3a7): undefined >>>>>> reference to `__imp_gluSphere' >>>>>> C:\msys64\tmp\cc4gd4Lj.o:osdemo32.c:(.text.startup+0x3bf): undefined >>>>>> reference to `__imp_gluDeleteQuadric' >>>>>> collect2.exe: error: ld returned 1 exit status >>>>>> >>>>>> I had numerous 'redeclared without dllimport attribute: previous >>>>>> dllimport ignored [-Wattributes]' warnings while building libGLU but as I >>>>>> am using a static lib I imagine this should not be the issue. However, >>>>>> this >>>>>> situation could indeed cause functions declared without dllimport >>>>>> attributes to not export to the compiled [dynamic] library. >>>>>> >>>>>> Anyway, I'm working through it so, hopefully, I can have a go at >>>>>> testing the swr driver soon. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> On Mon, 10 Jul 2017 at 18:07 Kyriazis, George < >>>>>> george.kyria...@intel.com> wrote: >>>>>> >>>>>>> I see, >>>>>>> >>>>>>> I view the filed bug as a “does not compile or run”. Having it >>>>>>> compile is not useful if it doesn’t run. >>>>>>> >>>>>>> In my last post in the bug, I’ve asked for some details from Emil; >>>>>>> hopefully we can get more insight there. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> George >>>>>>> >>>>>>> On Jul 10, 2017, at 11:05 AM, Trevor Sandy <trevor.sa...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> I haven't reached the point of rendering yet. My build script has a >>>>>>> built-in demo which I will run once the libraries build. >>>>>>> >>>>>>> The specific issue (Scons build failure) captured in the BZ ticket >>>>>>> is resolved. >>>>>>> >>>>>>> I imagine if there are more issues, there will be more tickets. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> On Mon, 10 Jul 2017 at 17:52 Kyriazis, George < >>>>>>> george.kyria...@intel.com> wrote: >>>>>>> >>>>>>>> By resolved, do you mean that you can render using SWR now? Did >>>>>>>> you verify that the SWR driver is loaded by checking the renderer >>>>>>>> string? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> George >>>>>>>> >>>>>>>> On Jul 10, 2017, at 10:50 AM, Trevor Sandy <trevor.sa...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Ok - So for me, the issue is resolved. Many thanks for your help! >>>>>>>> I will not post your patch in my repo until you confirm it is >>>>>>>> released. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> On Mon, 10 Jul 2017 at 17:46 Kyriazis, George < >>>>>>>> george.kyria...@intel.com> wrote: >>>>>>>> >>>>>>>>> I checked with the patches that you have in your repo. >>>>>>>>> >>>>>>>>> Yes, I modified that line. I think my change is more appropriate >>>>>>>>> since compilers like clang also understand gcc flags. The “/arch:” >>>>>>>>> option >>>>>>>>> is really ‘cl’ specific. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> George >>>>>>>>> >>>>>>>>> On Jul 10, 2017, at 10:27 AM, Trevor Sandy <trevor.sa...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Very well, >>>>>>>>> >>>>>>>>> The last revision you sent was OK for the patches. There was only >>>>>>>>> 1 conflict. >>>>>>>>> >>>>>>>>> # add_pi.patch \ >>>>>>>>> # gallium-once-flag.patch \ >>>>>>>>> # gallium-osmesa-threadsafe.patch \ >>>>>>>>> # glapi-getproc-mangled.patch \ >>>>>>>>> # install-GL-headers.patch \ >>>>>>>>> # lp_scene-safe.patch \ >>>>>>>>> # mesa-glversion-override.patch \ >>>>>>>>> # osmesa-gallium-driver.patch \ >>>>>>>>> # redefinition-of-typedef-nirshader.patch \ >>>>>>>>> # scons25.patch \ >>>>>>>>> # scons-llvm-3-9-libs.patch \ >>>>>>>>> # swr-sched.patch \ >>>>>>>>> # scons-swr-cc-arch.patch \ (*conflict*) >>>>>>>>> # msys2_scons_fix.patch \ >>>>>>>>> # 0001-mingw-fixes.patch \ >>>>>>>>> >>>>>>>>> The build is running.... >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> On Mon, 10 Jul 2017 at 16:48 Kyriazis, George < >>>>>>>>> george.kyria...@intel.com> wrote: >>>>>>>>> >>>>>>>>>> The last update was from Emil, I believe. >>>>>>>>>> >>>>>>>>>> Some of the patches you put on top of 17.1.3 are already on >>>>>>>>>> master, right? I agree with him, he’s trying to minimize issues by >>>>>>>>>> keeping >>>>>>>>>> the number of releases bound, and not having various people applying >>>>>>>>>> patches that may not mix well together. >>>>>>>>>> >>>>>>>>>> I would suggest that you pick a release and go with it. Since >>>>>>>>>> 17.1.3 does not work well with you (because you have all these >>>>>>>>>> patches >>>>>>>>>> applied on top of it), I would suggest that you start with master, >>>>>>>>>> push >>>>>>>>>> back to master (as Emil suggests) the patches that you still need, >>>>>>>>>> and >>>>>>>>>> once, later, master branches to a release branch (17.2, or whatever >>>>>>>>>> works >>>>>>>>>> for you), go with that one; no additional patches needed. >>>>>>>>>> >>>>>>>>>> You’ve already worked with Frederic for the patches, as you said, >>>>>>>>>> so he should be able to guide you on how to submit the patches that >>>>>>>>>> are >>>>>>>>>> still needed for you. Without knowing the contents of the patches, >>>>>>>>>> I can’t >>>>>>>>>> know what they do just by subject. >>>>>>>>>> >>>>>>>>>> I will work on getting my patch working on top of master (sorry, >>>>>>>>>> I thought it would work), and send you a new one, if you’d like. As >>>>>>>>>> soon >>>>>>>>>> as we get it all working and it gets reviewed, I will also submit it >>>>>>>>>> into >>>>>>>>>> master, so you won’t need to apply it anymore. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> George >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jul 10, 2017, at 9:03 AM, Trevor Sandy <trevor.sa...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Thanks George - I just read your note on BZ. Are you saying I >>>>>>>>>> should apply the upstream patches in addition to >>>>>>>>>> '0001-mingw-fixes.patch' >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> These are the upstream patches I have (from Fréderic): >>>>>>>>>> # add_pi.patch \ >>>>>>>>>> # gallium-once-flag.patch \ >>>>>>>>>> # gallium-osmesa-threadsafe.patch \ >>>>>>>>>> # glapi-getproc-mangled.patch \ >>>>>>>>>> # install-GL-headers.patch \ >>>>>>>>>> # lp_scene-safe.patch \ >>>>>>>>>> # mesa-glversion-override.patch \ >>>>>>>>>> # osmesa-gallium-driver.patch \ >>>>>>>>>> # redefinition-of-typedef-nirshader.patch \ >>>>>>>>>> # scons25.patch \ >>>>>>>>>> # scons-llvm-3-9-libs.patch \ >>>>>>>>>> # swr-sched.patch \ >>>>>>>>>> # scons-swr-cc-arch.patch \ >>>>>>>>>> # msys2_scons_fix.patch \ >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> On Mon, 10 Jul 2017 at 15:51 Kyriazis, George < >>>>>>>>>> george.kyria...@intel.com> wrote: >>>>>>>>>> >>>>>>>>>>> Apologies, >>>>>>>>>>> >>>>>>>>>>> Can you please apply on top of >>>>>>>>>>> revision 89d4008ac85714bab8c49974377fd37970f6d66a of the master >>>>>>>>>>> branch >>>>>>>>>>> (“mesa: do not use format string…”) >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> george >>>>>>>>>>> >>>>>>>>>>> On Jul 8, 2017, at 12:05 AM, Trevor Sandy < >>>>>>>>>>> trevor.sa...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello George, >>>>>>>>>>> >>>>>>>>>>> Unfortunately, I'm not able to successfully apply the patch. As >>>>>>>>>>> instructed, I cloned mesa master >>>>>>>>>>> @commit f728435e1f872af3efcd6b9215e8d722d35090cc and setup my env >>>>>>>>>>> to build >>>>>>>>>>> the libs. >>>>>>>>>>> >>>>>>>>>>> My steps were: >>>>>>>>>>> - tar.gx the repo to mesa-17.1.X.tar.gz >>>>>>>>>>> - execute the build script >>>>>>>>>>> - apply only the patch you provided: 0001-mingw-fixes.patch >>>>>>>>>>> >>>>>>>>>>> The build fails at applying the patch. You can see the errors >>>>>>>>>>> thrown beginning at line 1705 in the attach output log. >>>>>>>>>>> >>>>>>>>>>> If you were successful to patch the master branch, please send >>>>>>>>>>> the commit point. I will try at that point. I have not tried to >>>>>>>>>>> patch >>>>>>>>>>> 17.1.4. Let me know if it is worth trying ? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> On Sat, 8 Jul 2017 at 01:58 Kyriazis, George < >>>>>>>>>>> george.kyria...@intel.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Trevor, >>>>>>>>>>>> >>>>>>>>>>>> I am attaching a patch for you to try. Please try it on top of >>>>>>>>>>>> mesa master. It should get rid of all the compile issues with swr. >>>>>>>>>>>> Linking, however, takes a very long time (in the order of hours). >>>>>>>>>>>> I >>>>>>>>>>>> believe this is the due to mingw. >>>>>>>>>>>> >>>>>>>>>>>> I’ve had problems on my setup loading the swr dlls, once >>>>>>>>>>>> starting up a test program, but since your setup is different, you >>>>>>>>>>>> may have >>>>>>>>>>>> better luck. Please let me know how it works for you. I also do >>>>>>>>>>>> acknowledge the fact that you are more knowledgable in mingw than >>>>>>>>>>>> I am, so >>>>>>>>>>>> any help is appreciated. The problem that I am seeing is that if >>>>>>>>>>>> I do a >>>>>>>>>>>> LoadLibraryA() and GetProcAddress() from the opengl32.dll, to load >>>>>>>>>>>> the swr >>>>>>>>>>>> library, calling the function I get from GetProcAddress() fails >>>>>>>>>>>> (does not >>>>>>>>>>>> even call the function, but crashes). This, of course, works with >>>>>>>>>>>> Microsoft compilers. >>>>>>>>>>>> >>>>>>>>>>>> To use the swr driver, set GALLIUM_DRIVER=swr. If you leave >>>>>>>>>>>> this variable unset, of set it to “llvmpipe”, mesa will use >>>>>>>>>>>> llvmpipe. >>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> George >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Jun 29, 2017, at 1:20 PM, Trevor (CIMdata) < >>>>>>>>>>>> trevor.sa...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Actually, I didn’t. I just read the body of your message. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> Trevor SANDY >>>>>>>>>>>> +33 682 100 571 >>>>>>>>>>>> >>>>>>>>>>>> *From: *Kyriazis, George <george.kyria...@intel.com> >>>>>>>>>>>> *Sent: *29 June 2017 20:18 >>>>>>>>>>>> *To: *Trevor Sandy <trevor.sa...@gmail.com> >>>>>>>>>>>> *Subject: *Re: Msgs >>>>>>>>>>>> >>>>>>>>>>>> Thanks Trevor, >>>>>>>>>>>> >>>>>>>>>>>> So, you hit this issue yourself, too. Let me install msys2 >>>>>>>>>>>> from scratch clean, and let you know how it goes. >>>>>>>>>>>> >>>>>>>>>>>> I’ll keep you posted! >>>>>>>>>>>> >>>>>>>>>>>> George >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Jun 29, 2017, at 1:16 PM, Trevor Sandy < >>>>>>>>>>>> trevor.sa...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> George - one more point. The reason for your message below is >>>>>>>>>>>> because you did not explicitly declare your platform. As such, >>>>>>>>>>>> scons is >>>>>>>>>>>> taking msys_nt-10.0 which does not exist in the scons >>>>>>>>>>>> configuration. As you >>>>>>>>>>>> can see from the options available, you must declare >>>>>>>>>>>> 'platform=windows'. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Here are the options I use: >>>>>>>>>>>> >>>>>>>>>>>> build=release >>>>>>>>>>>> platform=windows >>>>>>>>>>>> toolchain=mingw >>>>>>>>>>>> machine=x86_64 >>>>>>>>>>>> texture_float=yes >>>>>>>>>>>> llvm=1 >>>>>>>>>>>> swr=1 >>>>>>>>>>>> verbose=yes >>>>>>>>>>>> osmesa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> On Thu, 29 Jun 2017 at 18:52 Kyriazis, George < >>>>>>>>>>>> george.kyria...@intel.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Trevor, >>>>>>>>>>>> >>>>>>>>>>>> Decided to send you an email directly, since those issues are >>>>>>>>>>>> build related, and not really mesa-related… >>>>>>>>>>>> >>>>>>>>>>>> I installed msys2 and scons inside msys2 using “pacman -S >>>>>>>>>>>> scons”, but I am getting: >>>>>>>>>>>> >>>>>>>>>>>> $ scons swr=1 build=debug toolchain=mingw osmesa >>>>>>>>>>>> scons: Reading SConscript files ... >>>>>>>>>>>> >>>>>>>>>>>> scons: *** Invalid value for option platform: msys_nt-10.0. >>>>>>>>>>>> Valid values are: ('cygwin', 'darwin', 'freebsd', 'haiku', 'linux', >>>>>>>>>>>> 'sunos', 'windows') >>>>>>>>>>>> File "/c/Users/gkyriazi/src/mesa/SConstruct", line 40, in >>>>>>>>>>>> <module> >>>>>>>>>>>> >>>>>>>>>>>> Looks like it’s some logic inside scons that picks up the >>>>>>>>>>>> platform and compares it to a supported list; ie. not related to >>>>>>>>>>>> mesa. >>>>>>>>>>>> >>>>>>>>>>>> How did you get scons for msys2? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> George >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> <osmesa-install_3.log> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> <0001-mingw-fixes.patch> >>> >>> >>> >>
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
