[Mingw-w64-public] [PATCH] crt: update micore.mri
* Generated by this command from Windows 10 SDK 18362: ar t '/c/Program Files (x86)/Windows Kits/10/Lib/10.0.18362.0/um/x64/mincore.lib' | sort -u | tee mincore_18362.mri And some sed-ing & diff-ing. From 7e809497f5493660f326f935f0b3ec74584a6bd9 Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Thu, 12 Dec 2019 07:00:00 +0530 Subject: [PATCH] crt: update micore.mri Signed-off-by: Biswapriyo Nath --- mingw-w64-crt/lib-common/mincore.mri | 17 + 1 file changed, 17 insertions(+) diff --git a/mingw-w64-crt/lib-common/mincore.mri b/mingw-w64-crt/lib-common/mincore.mri index 0168632a..a7546ca4 100644 --- a/mingw-w64-crt/lib-common/mincore.mri +++ b/mingw-w64-crt/lib-common/mincore.mri @@ -5,8 +5,13 @@ ADDLIB libapi-ms-win-core-com-l1-1-1.a ADDLIB libapi-ms-win-core-com-midlproxystub-l1-1-0.a ADDLIB libapi-ms-win-core-comm-l1-1-0.a ; FIXME libapi-ms-win-core-comm-l1-1-1.a +; FIXME libapi-ms-win-core-comm-l1-1-2.a ADDLIB libapi-ms-win-core-console-l1-1-0.a +; FIXME libapi-ms-win-core-console-l1-2-0.a +; FIXME libapi-ms-win-core-console-l1-2-1.a ; FIXME libapi-ms-win-core-console-l2-1-0.a +; FIXME libapi-ms-win-core-console-l2-2-0.a +; FIXME libapi-ms-win-core-console-l3-2-0.a ADDLIB libapi-ms-win-core-datetime-l1-1-0.a ADDLIB libapi-ms-win-core-datetime-l1-1-1.a ADDLIB libapi-ms-win-core-datetime-l1-1-2.a @@ -26,6 +31,7 @@ ADDLIB libapi-ms-win-core-file-ansi-l2-1-0.a ; FIXME libapi-ms-win-core-file-l1-2-0.a ADDLIB libapi-ms-win-core-file-l1-2-1.a ADDLIB libapi-ms-win-core-file-l1-2-2.a +; FIXME libapi-ms-win-core-file-l1-2-3.a ADDLIB libapi-ms-win-core-file-l2-1-0.a ADDLIB libapi-ms-win-core-file-l2-1-1.a ; FIXME libapi-ms-win-core-file-l2-1-2.a @@ -46,6 +52,7 @@ ADDLIB libapi-ms-win-core-libraryloader-l2-1-0.a ; FIXME libapi-ms-win-core-localization-l1-2-0.a ADDLIB libapi-ms-win-core-localization-l1-2-1.a ADDLIB libapi-ms-win-core-localization-l1-2-2.a +; FIXME libapi-ms-win-core-localization-l1-2-3.a ADDLIB libapi-ms-win-core-localization-l2-1-0.a ; FIXME libapi-ms-win-core-memory-l1-1-0.a ; FIXME libapi-ms-win-core-memory-l1-1-1.a @@ -53,6 +60,8 @@ ADDLIB libapi-ms-win-core-memory-l1-1-2.a ADDLIB libapi-ms-win-core-memory-l1-1-3.a ; FIXME libapi-ms-win-core-memory-l1-1-4.a ; FIXME libapi-ms-win-core-memory-l1-1-5.a +; FIXME libapi-ms-win-core-memory-l1-1-6.a +; FIXME libapi-ms-win-core-memory-l1-1-7.a ADDLIB libapi-ms-win-core-namedpipe-ansi-l1-1-0.a ADDLIB libapi-ms-win-core-namedpipe-ansi-l1-1-1.a ADDLIB libapi-ms-win-core-namedpipe-l1-1-0.a @@ -94,10 +103,13 @@ ADDLIB libapi-ms-win-core-synch-l1-2-1.a ADDLIB libapi-ms-win-core-sysinfo-l1-2-1.a ; FIXME libapi-ms-win-core-sysinfo-l1-2-2.a ADDLIB libapi-ms-win-core-sysinfo-l1-2-3.a +; FIXME libapi-ms-win-core-sysinfo-l1-2-4.a +; FIXME libapi-ms-win-core-sysinfo-l1-2-5.a ; FIXME libapi-ms-win-core-systemtopology-l1-1-0.a ; FIXME libapi-ms-win-core-systemtopology-l1-1-1.a ADDLIB libapi-ms-win-core-threadpool-l1-2-0.a ADDLIB libapi-ms-win-core-timezone-l1-1-0.a +; FIXME libapi-ms-win-core-timezone-l1-1-1.a ADDLIB libapi-ms-win-core-util-l1-1-0.a ; FIXME libapi-ms-win-core-util-l1-1-1.a ; FIXME libapi-ms-win-core-version-l1-1-0.a @@ -113,7 +125,9 @@ ADDLIB libapi-ms-win-core-winrt-string-l1-1-0.a ; FIXME libapi-ms-win-core-xstate-l1-1-0.a ; FIXME libapi-ms-win-core-xstate-l1-1-1.a ; FIXME libapi-ms-win-core-xstate-l1-1-2.a +; FIXME libapi-ms-win-core-xstate-l1-1-3.a ADDLIB libapi-ms-win-core-xstate-l2-1-0.a +; FIXME libapi-ms-win-core-xstate-l2-1-1.a ; FIXME libapi-ms-win-devices-config-l1-1-1.a ; FIXME libapi-ms-win-devices-config-l1-1-2.a ; FIXME libapi-ms-win-devices-swdevice-l1-1-0.a @@ -125,6 +139,7 @@ ADDLIB libapi-ms-win-eventing-controller-l1-1-0.a ADDLIB libapi-ms-win-eventing-provider-l1-1-0.a ; FIXME libapi-ms-win-power-base-l1-1-0.a ; FIXME libapi-ms-win-power-setting-l1-1-0.a +; FIXME libapi-ms-win-power-setting-l1-1-1.a ; FIXME libapi-ms-win-security-appcontainer-l1-1-0.a ; FIXME libapi-ms-win-security-base-l1-1-0.a ; FIXME libapi-ms-win-security-base-l1-2-0.a @@ -137,6 +152,8 @@ ADDLIB libapi-ms-win-eventing-provider-l1-1-0.a ; FIXME libapi-ms-win-service-core-l1-1-0.a ; FIXME libapi-ms-win-service-core-l1-1-1.a ; FIXME libapi-ms-win-service-core-l1-1-2.a +; FIXME libapi-ms-win-service-core-l1-1-3.a +; FIXME libapi-ms-win-service-core-l1-1-4.a ; FIXME libapi-ms-win-service-management-l1-1-0.a ; FIXME libapi-ms-win-service-management-l2-1-0.a ; FIXME libapi-ms-win-service-winsvc-l1-1-0.a -- 2.24.0 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
Hello David here is what i am doing with my package installer : https://github.com/vtorri/ewpi/blob/master/packages/libxml2/install.sh version i compile : https://github.com/vtorri/ewpi/blob/master/packages/libxml2/libxml2.ewpi hth Vincent Torri On Wed, Dec 11, 2019 at 10:50 PM David Mathog wrote: > > Trying to build libxml2 in MSYS2 mingw32. About a year ago using the > same commands 2.9.7 built without problems. Now neither 2.9.10 nor > 2.9.7 will build, both failing in the "python" part of the build. > After downloading and unpacking libxml2 2.9.10 (2.9.7 acts the same) > did: > > #in an MSYS2 mingw32 window > ./configure > make > > which failed. > > The python section wanted to include "crypt.h". Installed that with: >pacman -S libcrypt > but it still did not find it, because the file is in /usr/include rather > than /mingw32/include. It is looking for python includes in > /usr/include/python3.7m but changing that to python2.7 did not help. > > With "make V=1" found the compile line which was looking for "crypt.h" > and added to it "-I/usr/include". That got it past the crypt.h problem > but then it wanted "sys/select.h", which is I think an even bigger > problem. > > I didn't see an option for 2.9.10 like "--disable-libcrypt" or anything > like that. > > Anybody else run into this yet? > > This was after updating all of mingw32 with "pacman -Syu" (twice) > yesterday. So I think all of the Msys2/mingw32 pieces should be > current. > Everything was updated about a year ago too, before the last build. So > some combination of mingw32 and libxml2 changes in the last year seem to > have broken things. > > Thanks, > > David Mathog > mat...@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
crypt.h should be provided by gnulib since it does not normally exist on windows, sounds like something breaks the build chain. can you post the configure output ? might provide some clue as to what is going on. Den 12-12-2019 kl. 01:17 skrev David Mathog: On 2019-12-11 15:43, ralph engels wrote: that sounds like a bug you need to report to the msys2 mingw-packages developers, libgcrypt should also provide libgcrypt-20.dll and libgcrypt.dll.a not just the header. I didn't phrase that right. It does provide those other files, just NOT "crypt.h", which is what the build is looking for. Regards, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
On 2019-12-11 15:43, ralph engels wrote: that sounds like a bug you need to report to the msys2 mingw-packages developers, libgcrypt should also provide libgcrypt-20.dll and libgcrypt.dll.a not just the header. I didn't phrase that right. It does provide those other files, just NOT "crypt.h", which is what the build is looking for. Regards, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
that sounds like a bug you need to report to the msys2 mingw-packages developers, libgcrypt should also provide libgcrypt-20.dll and libgcrypt.dll.a not just the header. Den 12-12-2019 kl. 00:39 skrev David Mathog: On 2019-12-11 14:46, Ruben Van Boxem wrote: Op wo 11 dec. 2019 23:31 schreef David Mathog : or some switch used with "./configure". You'll need to pass "--host=i686-w64-mingw32". If you don't, it tries to identify the MSYS2 environment, which in the best case returns something Unix-like, which is not what you want. It seems to have been guessing this correctly, even without --host. If there are any dependencies you need, be sure to install e.g. mingw-w64-i686-libcrypt, which will put the 32-bit windows variant where the compiler looks for it (prefixed to /mingw32). Aas far as I can tell there is no such package. There is mingw-w64-i686-libgcrypt and libcrypt. The latter installs into /usr and is for inside MSYS2, the former goes into /mingw32 but it supplies only gcrypt.h. Regards, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
On 2019-12-11 14:46, Ruben Van Boxem wrote: Op wo 11 dec. 2019 23:31 schreef David Mathog : or some switch used with "./configure". You'll need to pass "--host=i686-w64-mingw32". If you don't, it tries to identify the MSYS2 environment, which in the best case returns something Unix-like, which is not what you want. It seems to have been guessing this correctly, even without --host. If there are any dependencies you need, be sure to install e.g. mingw-w64-i686-libcrypt, which will put the 32-bit windows variant where the compiler looks for it (prefixed to /mingw32). Aas far as I can tell there is no such package. There is mingw-w64-i686-libgcrypt and libcrypt. The latter installs into /usr and is for inside MSYS2, the former goes into /mingw32 but it supplies only gcrypt.h. Regards, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
Op wo 11 dec. 2019 23:31 schreef David Mathog : > > or some switch > used with "./configure". > You'll need to pass "--host=i686-w64-mingw32". If you don't, it tries to identify the MSYS2 environment, which in the best case returns something Unix-like, which is not what you want. If there are any dependencies you need, be sure to install e.g. mingw-w64-i686-libcrypt, which will put the 32-bit windows variant where the compiler looks for it (prefixed to /mingw32). Ruben > In any case, searched for that package and found out who built it and > will write there to find out where I am going wrong. > > Thanks, > > David Mathog > mat...@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
On 2019-12-11 14:14, David Grayson wrote: Have you considered simply installing libxml2 by running this command? pacman -S mingw-w64-i686-libxml2 Yes, but I want to understand why it does not build for me. Also, make sure you are running MSYS2 via mingw32.exe, and that you have installed the proper GCC toolchain: pacman -S mingw-w64-i686-toolchain Did that. It is mingw32.exe and all the tools are there. It seems like to build the distribution some patch may be required, or some switch used with "./configure". In any case, searched for that package and found out who built it and will write there to find out where I am going wrong. Thanks, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
Have you considered simply installing libxml2 by running this command? pacman -S mingw-w64-i686-libxml2 Also, make sure you are running MSYS2 via mingw32.exe, and that you have installed the proper GCC toolchain: pacman -S mingw-w64-i686-toolchain --David On Wed, Dec 11, 2019 at 1:51 PM David Mathog wrote: > > Trying to build libxml2 in MSYS2 mingw32. About a year ago using the > same commands 2.9.7 built without problems. Now neither 2.9.10 nor > 2.9.7 will build, both failing in the "python" part of the build. > After downloading and unpacking libxml2 2.9.10 (2.9.7 acts the same) > did: > > #in an MSYS2 mingw32 window > ./configure > make > > which failed. > > The python section wanted to include "crypt.h". Installed that with: >pacman -S libcrypt > but it still did not find it, because the file is in /usr/include rather > than /mingw32/include. It is looking for python includes in > /usr/include/python3.7m but changing that to python2.7 did not help. > > With "make V=1" found the compile line which was looking for "crypt.h" > and added to it "-I/usr/include". That got it past the crypt.h problem > but then it wanted "sys/select.h", which is I think an even bigger > problem. > > I didn't see an option for 2.9.10 like "--disable-libcrypt" or anything > like that. > > Anybody else run into this yet? > > This was after updating all of mingw32 with "pacman -Syu" (twice) > yesterday. So I think all of the Msys2/mingw32 pieces should be > current. > Everything was updated about a year ago too, before the last build. So > some combination of mingw32 and libxml2 changes in the last year seem to > have broken things. > > Thanks, > > David Mathog > mat...@caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] libxml2 2.9.7 built a year ago, not now
Trying to build libxml2 in MSYS2 mingw32. About a year ago using the same commands 2.9.7 built without problems. Now neither 2.9.10 nor 2.9.7 will build, both failing in the "python" part of the build. After downloading and unpacking libxml2 2.9.10 (2.9.7 acts the same) did: #in an MSYS2 mingw32 window ./configure make which failed. The python section wanted to include "crypt.h". Installed that with: pacman -S libcrypt but it still did not find it, because the file is in /usr/include rather than /mingw32/include. It is looking for python includes in /usr/include/python3.7m but changing that to python2.7 did not help. With "make V=1" found the compile line which was looking for "crypt.h" and added to it "-I/usr/include". That got it past the crypt.h problem but then it wanted "sys/select.h", which is I think an even bigger problem. I didn't see an option for 2.9.10 like "--disable-libcrypt" or anything like that. Anybody else run into this yet? This was after updating all of mingw32 with "pacman -Syu" (twice) yesterday. So I think all of the Msys2/mingw32 pieces should be current. Everything was updated about a year ago too, before the last build. So some combination of mingw32 and libxml2 changes in the last year seem to have broken things. Thanks, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt/d3d11: update d3d11 library
在 2019/12/11 22:33, Biswapriyo Nath 写道: > Fixed. > > > Thanks. Pushed this one. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt/d3d11: update d3d11 library
Fixed. From a5d0294267524c2886055ecb43b989116c7e651f Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Wed, 11 Dec 2019 07:00:00 +0530 Subject: [PATCH] crt/d3d11: update d3d11 library Signed-off-by: Biswapriyo Nath --- mingw-w64-crt/lib-common/d3d11.def | 4 mingw-w64-crt/lib32/d3d11.def | 5 + mingw-w64-crt/lib64/Makefile.am| 2 +- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/mingw-w64-crt/lib-common/d3d11.def b/mingw-w64-crt/lib-common/d3d11.def index fd661e4a..fb0cddbe 100644 --- a/mingw-w64-crt/lib-common/d3d11.def +++ b/mingw-w64-crt/lib-common/d3d11.def @@ -5,6 +5,7 @@ ; LIBRARY "d3d11.dll" EXPORTS +D3D11CreateDeviceForD3D12 D3DKMTCloseAdapter D3DKMTDestroyAllocation D3DKMTDestroyContext @@ -18,12 +19,15 @@ D3DKMTWaitForSynchronizationObject EnableFeatureLevelUpgrade OpenAdapter10 OpenAdapter10_2 +CreateDirect3D11DeviceFromDXGIDevice +CreateDirect3D11SurfaceFromDXGISurface D3D11CoreCreateDevice D3D11CoreCreateLayeredDevice D3D11CoreGetLayeredDeviceSize D3D11CoreRegisterLayers D3D11CreateDevice D3D11CreateDeviceAndSwapChain +D3D11On12CreateDevice D3DKMTCreateAllocation D3DKMTCreateContext D3DKMTCreateDevice diff --git a/mingw-w64-crt/lib32/d3d11.def b/mingw-w64-crt/lib32/d3d11.def index 80708bc7..7bc60078 100644 --- a/mingw-w64-crt/lib32/d3d11.def +++ b/mingw-w64-crt/lib32/d3d11.def @@ -5,11 +5,13 @@ ; LIBRARY "d3d11.dll" EXPORTS +D3D11CreateDeviceForD3D12@36 D3DKMTCloseAdapter@4 D3DKMTDestroyAllocation@4 D3DKMTDestroyContext@4 D3DKMTDestroyDevice@4 D3DKMTDestroySynchronizationObject@4 +D3DKMTPresent@4 D3DKMTQueryAdapterInfo@4 D3DKMTSetDisplayPrivateDriverFormat@4 D3DKMTSignalSynchronizationObject@4 @@ -18,12 +20,15 @@ D3DKMTWaitForSynchronizationObject@4 EnableFeatureLevelUpgrade OpenAdapter10@4 OpenAdapter10_2@4 +CreateDirect3D11DeviceFromDXGIDevice@8 +CreateDirect3D11SurfaceFromDXGISurface@8 D3D11CoreCreateDevice@40 D3D11CoreCreateLayeredDevice@20 D3D11CoreGetLayeredDeviceSize@8 D3D11CoreRegisterLayers@8 D3D11CreateDevice@40 D3D11CreateDeviceAndSwapChain@48 +D3D11On12CreateDevice@40 D3DKMTCreateAllocation@4 D3DKMTCreateContext@4 D3DKMTCreateDevice@4 diff --git a/mingw-w64-crt/lib64/Makefile.am b/mingw-w64-crt/lib64/Makefile.am index 3ac278a5..7addb85e 100644 --- a/mingw-w64-crt/lib64/Makefile.am +++ b/mingw-w64-crt/lib64/Makefile.am @@ -88,6 +88,7 @@ lib64_DATA += %reldir%/libcsrsrv.a lib64_DATA += %reldir%/libd3d8thk.a lib64_DATA += %reldir%/libd3d9.a lib64_DATA += %reldir%/libd3d10.a +lib64_DATA += %reldir%/libd3d11.a lib64_DATA += %reldir%/libd3d12.a lib64_DATA += %reldir%/libd3dxof.a lib64_DATA += %reldir%/libdavclnt.a @@ -791,7 +792,6 @@ lib64_DATA += %reldir%/libxinput9_1_0.a lib64_DATA += %reldir%/libxaudio2_8.a lib64_DATA += %reldir%/libd3dcompiler_46.a lib64_DATA += %reldir%/libd3dcsx_46.a -lib64_DATA += %reldir%/libd3d11.a lib64_DATA += %reldir%/libd3dcompiler_47.a lib64_DATA += %reldir%/libwinhttp.a lib64_DATA += %reldir%/libruntimeobject.a -- 2.24.0 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt/d3d11: update d3d11 library
在 2019/12/11 15:25, Biswapriyo Nath 写道: > ... > > `libd3d11.a` already exists on line 794 in 'lib64/Makefile.am'. If you meant to move this line up then it should probably be removed there. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Incorrect GUID definitions in mfidl.h
On 12/11/19 1:43 PM, Liu Hao wrote: 在 2019/12/11 20:04, Jacek Caban 写道: The attached patch should fix it, please review. It shouldn't be needed for include/mfidl.h through... LGTM. Now here is another error: ``` /mingw64/bin/widl -DBOOL=WINBOOL -I./include -I./direct-x/include -Icrt -I./crt -h -o include/windows.storage.streams.h include/windows.storage.streams.idl include/windows.storage.streams.idl:35: error: type 'IBuffer' not found make: *** [Makefile:1281: include/windows.storage.streams.h] Error 1 ``` That one is more tricky. It's because those winrt IDLs were committed without finished widl support. Right now we have useless and invalid IDL files that we can't use to generate anything (and even if we had widl complete, they would still be invalid). I've done some work on that. Partial winrt support is in widl now and I have more WIP patches waiting for some time to finish. But it's still quite a lot of work... Jacek ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCHv2] crt: Split out the __cxa_atexit and __cxa_thread_atexit entry points to separate files
On Wed, 11 Dec 2019, JonY via Mingw-w64-public wrote: On 12/11/19 7:08 AM, Martin Storsjö wrote: This avoids potential conflicts with e.g. libstdc++ (which provides __cxa_thread_atexit), if something pulls in e.g. __dso_handle or __cxa_atexit (which libstdc++ doesn't provide). Patch OK. Thanks, pushed! // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCHv2] crt: Split out the __cxa_atexit and __cxa_thread_atexit entry points to separate files
On 12/11/19 7:08 AM, Martin Storsjö wrote: > This avoids potential conflicts with e.g. libstdc++ (which provides > __cxa_thread_atexit), if something pulls in e.g. __dso_handle or > __cxa_atexit (which libstdc++ doesn't provide). > Patch OK. signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Incorrect GUID definitions in mfidl.h
在 2019/12/11 20:04, Jacek Caban 写道: > > The attached patch should fix it, please review. It shouldn't be needed > for include/mfidl.h through... > > LGTM. Now here is another error: ``` /mingw64/bin/widl -DBOOL=WINBOOL -I./include -I./direct-x/include -Icrt -I./crt -h -o include/windows.storage.streams.h include/windows.storage.streams.idl include/windows.storage.streams.idl:35: error: type 'IBuffer' not found make: *** [Makefile:1281: include/windows.storage.streams.h] Error 1 ``` -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Incorrect GUID definitions in mfidl.h
On 12/11/19 12:44 PM, Liu Hao wrote:
在 2019/12/10 19:17, Jacek Caban 写道:
On 12/10/19 12:10 PM, Liu Hao wrote:
You could just use make include/mfidl.h if you use configure with
--with-widl. This uses -DBOOL=WINBOOL when generating headers. IDL files
should use BOOL, not WINBOOL, and leave it for widl to generate correct
headers.
Thanks for the information. `-DBOOL=WINBOOL` makes WIDL compile the IDL
without any modification.
However `make include/mfidl.h` seemed to be stuck with some syntax
errors likes this:
```
crt/ctype.h:108: error: syntax error, unexpected aIDENTIFIER, expecting
tTYPEDEF
make[2]: *** [Makefile:1281: include/docobjectservice.h] Error 1
```
The attached patch should fix it, please review. It shouldn't be needed
for include/mfidl.h through...
Jacek
commit 37c5be50b3549ed9695f45b509560b4338b813c2
Author: Jacek Caban
Date: Wed Dec 11 12:58:56 2019 +0100
mshtml.idl: Correctly import dxgitype.idl.
diff --git a/mingw-w64-headers/include/mshtml.idl b/mingw-w64-headers/include/mshtml.idl
index 3394f05d..1090fcba 100644
--- a/mingw-w64-headers/include/mshtml.idl
+++ b/mingw-w64-headers/include/mshtml.idl
@@ -83,7 +83,7 @@ interface IIE80DispatchEx : IDispatchEx {
library MSHTML {
importlib ("stdole2.tlb");
import "ocidl.idl";
- import "dxgitype.h";
+ import "dxgitype.idl";
interface IDOMEvent;
interface IElementBehavior;
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Incorrect GUID definitions in mfidl.h
在 2019/12/10 19:17, Jacek Caban 写道: > On 12/10/19 12:10 PM, Liu Hao wrote: > > You could just use make include/mfidl.h if you use configure with > --with-widl. This uses -DBOOL=WINBOOL when generating headers. IDL files > should use BOOL, not WINBOOL, and leave it for widl to generate correct > headers. > > Thanks for the information. `-DBOOL=WINBOOL` makes WIDL compile the IDL without any modification. However `make include/mfidl.h` seemed to be stuck with some syntax errors likes this: ``` crt/ctype.h:108: error: syntax error, unexpected aIDENTIFIER, expecting tTYPEDEF make[2]: *** [Makefile:1281: include/docobjectservice.h] Error 1 ``` -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
