[Mesa-dev] [OS]Mesa MinGW AppVeyor Repository

[Trevor Sandy]

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.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at intel.com> wrote:
>>>>
>>>>> Ok, that makes sense (for the GALLIUM_DRIVER var).
>>>>>
>>>>>
>>>>> George
>>>>>
>>>>> On Jul 11, 2017, at 1:09 PM, Trevor Sandy <trevor.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at 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.sandy at 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.kyriazis at intel.com>
>>>>>>>>>>>> *Sent: *29 June 2017 20:18
>>>>>>>>>>>> *To: *Trevor Sandy <trevor.sandy at 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.sandy at 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.kyriazis at 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>
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171002/035793ab/attachment-0001.html>