Re: [Mingw-w64-public] Mingw-w64 add support for loongarch .

[Stephen Kitt]

On Mon, 2 Oct 2023 12:16:45 +0530, Biswapriyo Nath 
wrote:
> The files in mingw-w64-tools/widl directory are imported from wine
> project. mingw-w64-tools/widl/wine-import.sh script can help to find
> which files are imported. So, the patch should be sent to wine
> project, here https://gitlab.winehq.org/wine/wine

I’ve been meaning to take care of that, I’ve just opened
https://gitlab.winehq.org/wine/wine/-/merge_requests/3997 (this includes the
loongarch patch with appropriate authorship).

Regards,

Stephen


pgpotolpIqR2M.pgp
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 1/2] tools: Remove the unused tool genlib

[Stephen Kitt]

On Fri, 1 Sep 2023 12:20:37 +0800, LIU Hao  wrote:
> 在 2023/8/31 18:20, Martin Storsjö 写道:
> > This tool was meant as a standalone replacement for dlltool,
> > for generating import libraries, but it never got feature parity
> > (in particular, it lacked support for generating symbol aliases,
> > which are cruicial for the core mingw-w64-crt import libraries).  
> 
> AFAICT Debian has it, although with a weird prefix (`mingw-genlib`). I
> agree that dlltool should be preferred, and I don't mind removing genlib.

Yes, but please don’t keep it on our account, nothing I’m aware of uses the
Debian genlib. (The name was modified because genlib was perceived as too
generic.)

Regards,

Stephen


pgpORxmtU56ii.pgp
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] Determining mingw runtime version

[Stephen Kitt]

Le 07/03/2022 13:34, sisyphus a écrit :
On Mon, Mar 7, 2022 at 6:27 PM Gisle Vanem  
wrote:

> A command that displays only the value of __MINGW64_VERSION_MAJOR would
> probably suffice.

Some .bat-file with:

setlocal
set %find=%WinDir%\system32\find.exe
if %MINGW32%. == . set MINGW32=f:\MinGW32\TDM-gcc

type "%MINGW32%\x86_64-w64-mingw32\include\_mingw_mac.h" | ^
   %find% "__MINGW64_VERSION_MAJOR" | %find% "#define")

--



Thank you, Gisle - that sounds like a good place to start.

Unfortunately that approach gives me output of (eg):
#define __MINGW64_VERSION_MAJOR 8

whereas I'm hoping to obtain just the value of __MINGW64_VERSION_MAJOR 
,

and nothing else. (I want to retrieve that value inside a Makefile that
will be run in a cmd.exe shell.)

According to
https://superuser.com/questions/1488014/batch-file-extract-number-from-string-using-regex
there is some regex capability with batch files.
Not sure if there's a solution for me in that, but I'll investigate 
that

possibility.


You can ask GCC itself:

$ x86_64-w64-mingw32-gcc -E -include windows.h - 
<<<"__MINGW64_VERSION_MAJOR" | tail -n 1

9

Regards,

Stephen


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] getc skips "0D" in binary file

[Stephen Kitt]

Le 30/11/2021 11:11, David Webb a écrit :
[...]
Looking at stdio.h,  it looks as if mingw uses a getc routine instead 
of the
normal macro.  Is this correct - is it for example using a Microsoft 
getc
routine which drops '0D' from '0D''0A'?   More importantly, is there a 
way to

prevent the '0D' characters being dropped?


Are you specifying binary mode when opening the file? "b" with 
fopen()...


See 
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-170 
for details.


Regards,

Stephen


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] naming convention of mingw-w64 and compile Windows binary on MacOS

[Stephen Kitt]

On Mon, 11 Jan 2021 22:07:42 +0800, Liu Hao  wrote:
[...]
> There is no special meaning about `w64` itself. `mingw32` on the other hand
> specifies the ABI, so all `i686-*-mingw32` targets are considered
> ABI-compatible.

Are they really though? It seems to me that the triplet has ended up somewhat
overloaded — especially with regards to features such as the threading model
or the exception handling. (Thinking with my Debian hat on, where we still
need a comprehensive architecture definition if we ever want multiarch to
work with MinGW-w64...)

While we’re at it, how could we reflect the target CRT (MSVCRT, UCRT, or one
of the version-specific RTs)?

Regards,

Stephen


pgpI5fXYvCi2z.pgp
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] MinGW cross compile with enable-sjlj-exceptions - linux

[Stephen Kitt]

Debian stable does, for i686.

Le 27/11/2020 15:04, gmail Vladimir Koković a écrit :

You are absolutely right but no one has with enable-sjlj-exceptions!


On 27.11.20. 14:18, Biswapriyo Nath wrote:
how to bring the MinGW cross compile on Linux into a normal linux 
build

Most popular GNU/Linux distributions already provide mingw-w64 cross
compiler and toolchain in their packages.


___
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 mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw-w64-gcc 10.2.0 with sjlj fails to link: undefined reference to `_Unwind_SjLj_Register'

[Stephen Kitt]

Le 18/09/2020 09:01, Ave Milia via Mingw-w64-public a écrit :
Try removing`--with-dwarf3`. I am not sure whether it will cause any 
err=

ors, but when bootstrapping GCC on Windows with
non-DWARF exception models (that is SJLJ and SEH), it is never 
specified.=


The build failed with seemingly same errors.

I have also tried to just copy Debian options to the best of my
ability, as they have a million configuration instructions. That
failed, earlier in the build and with a different error. Whatever.


Just in case it's any use, here are the flags used in the Debian builds, 
ignoring the host/build/target flags, path-related flags, and the thread 
model:


--disable-option-checking --disable-silent-rules 
--disable-maintainer-mode --enable-shared --enable-static 
--disable-multilib --with-system-zlib --without-included-gettext 
--enable-libstdcxx-time=yes --with-tune=generic 
--with-headers=/usr/i686-w64-mingw32/include 
--enable-version-specific-runtime-libs --enable-fully-dynamic-string 
--enable-libgomp --enable-languages=c,c\+\+,fortran,objc,obj-c\+\+,ada 
--enable-lto --enable-libatomic --enable-libstdcxx-filesystem-ts=yes 
--enable-dependency-tracking


See 
https://buildd.debian.org/status/fetch.php?pkg=gcc-mingw-w64=amd64=23=1590864998=0 
for an example build on amd64, listing all the commands used.


Regards,

Stephen


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Fix a few spelling errors

[Stephen Kitt]

These were flagged by Debian's Lintian QA tool.

Signed-off-by: Stephen Kitt 
---
 mingw-w64-libraries/libmangle/src/m_ms.c | 2 +-
 mingw-w64-tools/gendef/src/gendef.c  | 2 +-
 mingw-w64-tools/genpeimg/src/img_pe.c| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/mingw-w64-libraries/libmangle/src/m_ms.c 
b/mingw-w64-libraries/libmangle/src/m_ms.c
index e733bb8c..2e62acc7 100644
--- a/mingw-w64-libraries/libmangle/src/m_ms.c
+++ b/mingw-w64-libraries/libmangle/src/m_ms.c
@@ -685,7 +685,7 @@ get_operator_name (sMSCtx *c, int fIsTemplate, int 
*pfReadTemplateArguments)
   return m_oper (c, m_rtti (c, "complete_object_locator"));
   }
 DEC_CHAR (c);
-fprintf (stderr, " *** Unkown RTTI %c\n", ch);
+fprintf (stderr, " *** Unknown RTTI %c\n", ch);
 c->err = 2;
 return NULL;
   case 'S':
diff --git a/mingw-w64-tools/gendef/src/gendef.c 
b/mingw-w64-tools/gendef/src/gendef.c
index 4aa9a42e..9d7c4378 100644
--- a/mingw-w64-tools/gendef/src/gendef.c
+++ b/mingw-w64-tools/gendef/src/gendef.c
@@ -115,7 +115,7 @@ opt_chain (const char *opts, const char *next)
 {
   if (!next)
 {
- fprintf (stderr, "Error: %s expects path as next arguement.", opts);
+ fprintf (stderr, "Error: %s expects path as next argument.", opts);
  return 0;
 }
   gendef_addpath_def (next);
diff --git a/mingw-w64-tools/genpeimg/src/img_pe.c 
b/mingw-w64-tools/genpeimg/src/img_pe.c
index 98d63c42..3fd27bd0 100644
--- a/mingw-w64-tools/genpeimg/src/img_pe.c
+++ b/mingw-w64-tools/genpeimg/src/img_pe.c
@@ -225,7 +225,7 @@ peimg_show (pe_image *ppeimg, FILE *outfp)
   fprintf (outfp, "\n");
 }
   fprintf (outfp, "PE+ optional header information\n"
-"  Linker version %u.%u, Code size: 0x%x, Intialized Data size: 0x%x\n"
+"  Linker version %u.%u, Code size: 0x%x, Initialized Data size: 0x%x\n"
 "  Uninitialized Data size: 0x%x, Entry-point 0x%x\n",
   PEIMG_GET_UCHAR (ppeimg, ppeimg->optional_hdr_pos + 2),
   PEIMG_GET_UCHAR (ppeimg, ppeimg->optional_hdr_pos + 3),
@@ -282,7 +282,7 @@ peimg_show (pe_image *ppeimg, FILE *outfp)
 case 14: fprintf (outfp, "XBOX\n"); break;
 case 16: fprintf (outfp, "Windows Boot Application (16)\n"); break;
 default:
-  fprintf (outfp, "Unkown (%u)\n", PEIMG_GET_USHORT (ppeimg, 
ppeimg->optional_hdr_pos + 68));
+  fprintf (outfp, "Unknown (%u)\n", PEIMG_GET_USHORT (ppeimg, 
ppeimg->optional_hdr_pos + 68));
   break;
 }
   hdr_cha = PEIMG_GET_USHORT (ppeimg, ppeimg->optional_hdr_pos + 70);
-- 
2.20.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Detect -lm in genlib

[Stephen Kitt]

genlib's configure checks for -lmangle before -lm; as a result, the
-lm checks include -lmangle which fails because the required library
path isn't specified. To avoid this, we check for -lm before checking
for -lmangle.

Signed-off-by: Stephen Kitt 
---
 mingw-w64-tools/genlib/configure.ac | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/mingw-w64-tools/genlib/configure.ac 
b/mingw-w64-tools/genlib/configure.ac
index 18a5267c..1c334f50 100644
--- a/mingw-w64-tools/genlib/configure.ac
+++ b/mingw-w64-tools/genlib/configure.ac
@@ -15,6 +15,14 @@ AC_CANONICAL_HOST
 # Checks for programs.
 AC_PROG_CC
 
+# Checks for library functions.
+# Disabled due the fact that once the autoconf detects that malloc
+# is not available, it places in config.h the define of malloc as
+# rpl_malloc. By this linkage could fail on cross-compiles.
+#AC_FUNC_MALLOC
+AC_CHECK_FUNCS([memset strdup strrchr strlwr])
+AC_CHECK_LIB([m], [floor])
+
 # Checks for libraries.
 AC_MSG_CHECKING([whether to build genlib with libmangle])
 AC_ARG_WITH([mangle],
@@ -54,13 +62,5 @@ AC_TYPE_UINT32_T
 AC_TYPE_UINT64_T
 AC_TYPE_UINT8_T
 
-# Checks for library functions.
-# Disabled due the fact that once the autoconf detects that malloc
-# is not available, it places in config.h the define of malloc as
-# rpl_malloc. By this linkage could fail on cross-compiles.
-#AC_FUNC_MALLOC
-AC_CHECK_FUNCS([memset strdup strrchr strlwr])
-AC_CHECK_LIB([m], [floor])
-
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
-- 
2.20.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Drop the empty exception declaration from CheckError

[Stephen Kitt]

The function is defined as follows:

namespace _com_util {
  inline void CheckError(HRESULT hr) throw() {
if(FAILED(hr)) { _com_issue_error(hr); }
  }
}

but _com_issue_error is defined as:

inline void _com_issue_error(HRESULT hr) {
#if __EXCEPTIONS
throw _com_error(hr);
#else
/* This is designed to use exceptions. If exceptions are disabled, 
there is not much we can do here. */
__debugbreak();
#endif
}

so actually calling it with a failed HRESULT crashes the program. I
think the empty exception specification should simply be dropped.

See https://bugs.debian.org/816427

Reported-by: Sam Morris 
Signed-off-by: Stephen Kitt 
---
 mingw-w64-headers/include/comutil.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mingw-w64-headers/include/comutil.h 
b/mingw-w64-headers/include/comutil.h
index f6d7adcf..e090067c 100644
--- a/mingw-w64-headers/include/comutil.h
+++ b/mingw-w64-headers/include/comutil.h
@@ -44,7 +44,7 @@ class _bstr_t;
 class _variant_t;
 
 namespace _com_util {
-  inline void CheckError(HRESULT hr) throw() {
+  inline void CheckError(HRESULT hr) {
 if(FAILED(hr)) { _com_issue_error(hr); }
   }
 }
-- 
2.20.1



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News|New Builds]

[Stephen Kitt]

Hi niXman,

On Tue, 20 Sep 2016 21:32:02 +0300, niXman  wrote:
> Zouzou 2016-09-18 17:28:
> > One note: The source is missing from
> > .
> 
> The uploading of the builds and sources is performed by scripts. It 
> looks like something went wrong with the scripts... I'll check...

I tried to find the source but failed; any news on the scripts? I'm curious
to see how you enabled filesystem TS support (I'm getting build failures
because dir.cc expects DIR* but MinGW-w64 _wopendir returns WDIR*).

Regards,

Stephen

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] %ll not a bug, my syntax error. long time no use printf, no man pages

[Stephen Kitt]

On Tue, 26 Jul 2016 10:13:11 -0700, Jim Michaels 
wrote:
> make manual? isn't there some sort of make target for help or manual or 
> info?
> 
> html output maybe?

Not sure what you're looking for; look up printf() in MSDN perhaps...

> using g++,
> 
> #include 
> char buf[16777216];
> printf("bufsize %lld\r\n",sizeof(buf));
> printf("%lld %s\r\n", -12,"cd");
> 
> outputs
> 
> bufsize 21198893437943809
> 21009446708707316 ê■"
> 
> ALL wrong.

Because your code is all wrong: your format specifiers need to match the
sizes of the arguments. Use "%d" instead of "%lld".

Regards,

Stephen

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ignoring missing symbols doesn't seem to work

[Stephen Kitt]

Hi,

On Tue, 10 May 2016 11:57:33 -0400, Tamir Duberstein  wrote:
> I've been attempting to cross-compile CockroachDB to Windows using
> mingw-w64. The compilation strategy used for CockroachDB involves
> producing static archives with missing symbols (this is due to how
> golang's tooling compiles c/c++ code).
> 
> In our linux builds, we pass `-Wl,--unresolved-symbols=ignore-all` to
> the compiler to silence these unresolved symbols warnings in our
> intermediate static archives - however, it seems that mingw-w64's g++
> binary (`x86_64-w64-mingw32-g++-posix` is the one I've tested) doesn't
> respect this flag.
> 
> Does anyone know why this might be, or where to begin investigating?

Like all linker flags, this is handled by binutils rather than gcc. Currently
the PE linker in binutils doesn't support the --unresolved-symbols option.

Regards,

Stephen

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Does GCC 4.9.0 supports -Wl,--gc-sections?

[Stephen Kitt]

Hi,

On Thu, 17 Mar 2016 11:50:17 +1100, YIRAN LI  wrote:
> I'm compiling on MingW-W64 and had a problem in using -Wl,--gc-setions.
> 
[...]
> 
> The gcc version I'm using is: gcc version 4.9.0 (i686-win32-sjlj-rev1,
> Built by MinGW-W64 project)

--gc-sections is handled by ld, so support for it depends on the version of
binutils you have; what does

ld -v

produce? Support for --gc-sections on COFF and PE binaries requires binutils
2.26 (although there are still some issues to be worked out).

Regards,

Stephen

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Please keep the website's download section up-to-date

[Stephen Kitt]

Hi Adrien,

On Mon, 22 Jun 2015 23:29:17 +0200, Adrien Nader adr...@notk.org wrote:
 There have been concerns on various places on the Internet that the
 download page on the mingw-w64 website at
 http://mingw-w64.org/doku.php/download is not consistently kept
 up-to-date. The website is a simple and friendly wiki with open
 registration and if/when mingw-w64 moves away from sourceforge, it will
 be the place which will not be impacted during the transition.
 Considering this topic has gotten much hotter recently, it is really
 important to not completely rely on the sourceforge file release system
 for listing as some of you currently do.

I tried to register but I can't get the registration page to work... I clicked
on Login at the bootom of the page, then Register on the login page,
filled in my details, but clicking on Register always brings me back to the
same registration page.

Regards,

Stephen

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

[Stephen Kitt]

Hi Adrien,

On Mon, 30 Mar 2015 22:49:27 +0200, Adrien Nader adr...@notk.org wrote:
[...]
 
 Thanks for the list.
 
 Can you check the information is correct?
 I've not added a line for debian experimental since it's expiremental
 and changes quite often: it needs someone actively updating the page.

Excellent, thanks! Everything seems OK to me. You're right about the
experimental info...

 I'll ping you when the user registration stuff is fixed if you want.

... and that sounds like a great idea too.

 On a related note, I'll try to spend time next week-end to improve the
 layout of the tables a bit as they'd probably benefit from cell borders
 (I find them a bit difficult to read at times with their current style).

That would improve the readability of merged cells in particular!

Regards,

Stephen

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

[Stephen Kitt]

Hi,

On Tue, 24 Mar 2015 21:20:04 +0100, Adrien Nader adr...@notk.org wrote:
[...]
 There's an additional reason: I'm seeing cygwin similarly to
 fedora/opensuse/arch.
 If someone is already using these, the entries on the website will make
 him check his version requirements and look at his distro package
 manager. They probably won't make anyone start using these distros
 however. Some distros have recent versions, some don't (debian, ubuntu)
 and I believe this page can help the user by providing something simple
 to read.
[...]

Would it actually be possible to mention the Debian and Ubuntu toolchains on
the download page? Most people find MinGW-w64 via the MinGW-w64 web site
rather than via their distribution, and I regularly get emails from people
surprised to find out that the toolchain is packaged in Debian/Ubuntu: since
it's not mentioned on the MinGW-w64 website they figure that their only
solution is to download one of the Win-builds.

Anyway, we currently support:
* Debian 7 (Wheezy): builds for i686, x86_64; gcc 4.6.3, MinGW-w64 2.0.3, with
  C, C++, Fortran, Ada, Objective-C and Objective-C++ compilers; C11/C++11
  threading isn't supported; the package manager is Apt/Dpkg; installation is
  done within Debian (https://packages.debian.org/mingw-w64)
* Debian 8 (Jessie): as above, with gcc 4.9.1, MinGW-w64 3.2.0; C11/C++11
  threading is supported (a Win32 threading variant is also available)
* Debian has MinGW-w64 4.0.1 in the experimental repositories
* Ubuntu 12.04 (Precise Pangolin): as above, with gcc 4.6.3, MinGW-w64 2.0.1
  (https://launchpad.net/ubuntu/+source/mingw-w64)
* Ubuntu 14.04 (Trusty Tahr): as above, with gcc 4.8.2, MinGW-w64 3.1.0,
  C11/C++11 threading (using winpthreads)
* Ubuntu 14.10 (Utopic Unicorn): as above, with gcc 4.9.1, MinGW-w64 3.1.0,
  C11/C++11 threading (a Win32 threading variant is also available)
* Ubuntu 15.04 (Vivid Vervet): as above, with gcc 4.9.2, MinGW-w64 3.2.0

The only additional software currently available is gdb and nsis.

Thanks,

Stephen

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] v4.0.0 released

[Stephen Kitt]

Hi,

On Fri, 20 Mar 2015 22:04:38 +0200, Alon Bar-Lev alon.bar...@gmail.com
wrote:
 Every major update we (at gentoo) and maybe others have issue to upgrade. I
 reported[1] this in the past.
 
 Building the crt should use the headers within the crt and not within
 sysroot, this to enable building the new crt using an environment that has
 the old crt.
 
 Other libc implementation does exactly that, I tried to modify the build of
 the mingw runtime and it seem non trivial to achieve this in current state.
 
 Can you please consider implementing that?

The way I get around this is a variant of:

* build the CRT headers
* install them to ${source}/tmp (so they end up in
  ${source}/tmp/usr/${target}/include)
* configure the CRT libraries with -I${source}/tmp/usr/${target}/include

That way the CRT libraries are built with the provided headers, not the
installed ones.

Regards,

Stephen

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] v4.0-rc3 released

[Stephen Kitt]

Hi,

On Wed, 04 Mar 2015 21:51:51 +0800, JonY jo...@users.sourceforge.net wrote:
 Without further ado:
 http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v4.0-rc3.tar.bz2
 http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v4.0-rc3.tar.bz2.sig

The signature fails for me:

% gpg --verify mingw-w64-v4.0-rc3.tar.bz2.sig mingw-w64-v4.0-rc3.tar.bz2 
gpg: Signature made Wed 04 Mar 2015 14:32:07 CET
gpg:using DSA key 0x93BDB53CD4EBC740
gpg: BAD signature from JonY jo...@users.sourceforge.net [unknown]

Regards,

Stephen

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Unusable header fix-ups

[Stephen Kitt]

Hi,

IOhannes m zmoelnig reported (via https://bugs.debian.org/761191) that a few
headers are missing the leading / in their boilerplate, which renders them
unusable. The attached patch (against master) fixes this; it applies to
stable too.

Regards,

Stephen
diff --git a/mingw-w64-headers/include/adtgen.h b/mingw-w64-headers/include/adtgen.h
index b1878c1..d11f5c2 100644
--- a/mingw-w64-headers/include/adtgen.h
+++ b/mingw-w64-headers/include/adtgen.h
@@ -1,7 +1,7 @@
-**
-* This file is part of the mingw-w64 runtime package.
-* No warranty is given; refer to the file DISCLAIMER within this package.
-*/
+/**
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER within this package.
+ */
 
 #include winapifamily.h
 
diff --git a/mingw-w64-headers/include/authz.h b/mingw-w64-headers/include/authz.h
index 64c3057..d6dd14b 100644
--- a/mingw-w64-headers/include/authz.h
+++ b/mingw-w64-headers/include/authz.h
@@ -1,7 +1,7 @@
-**
-* This file is part of the mingw-w64 runtime package.
-* No warranty is given; refer to the file DISCLAIMER within this package.
-*/
+/**
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER within this package.
+ */
 
 #include winapifamily.h
 
diff --git a/mingw-w64-headers/include/aux_ulib.h b/mingw-w64-headers/include/aux_ulib.h
index 71a74c2..3fac7ae 100755
--- a/mingw-w64-headers/include/aux_ulib.h
+++ b/mingw-w64-headers/include/aux_ulib.h
@@ -1,7 +1,7 @@
-**
-* This file is part of the mingw-w64 runtime package.
-* No warranty is given; refer to the file DISCLAIMER within this package.
-*/
+/**
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER within this package.
+ */
 
 #ifndef _AUX_SHLD_LIB_H
 #define _AUX_SHLD_LIB_H
diff --git a/mingw-w64-headers/include/avifmt.h b/mingw-w64-headers/include/avifmt.h
index 88389a3..3b8f2c7 100644
--- a/mingw-w64-headers/include/avifmt.h
+++ b/mingw-w64-headers/include/avifmt.h
@@ -1,7 +1,7 @@
-**
-* This file is part of the mingw-w64 runtime package.
-* No warranty is given; refer to the file DISCLAIMER within this package.
-*/
+/**
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER within this package.
+ */
 
 #include winapifamily.h
 
diff --git a/mingw-w64-headers/include/aviriff.h b/mingw-w64-headers/include/aviriff.h
index cb334ad..30e7de3 100755
--- a/mingw-w64-headers/include/aviriff.h
+++ b/mingw-w64-headers/include/aviriff.h
@@ -1,7 +1,7 @@
-**
-* This file is part of the mingw-w64 runtime package.
-* No warranty is given; refer to the file DISCLAIMER within this package.
-*/
+/**
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER within this package.
+ */
 
 #include winapifamily.h
 


signature.asc
Description: PGP signature
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Bug#755448: fixed in mingw-w64 3.1.0-3

[Stephen Kitt]

Hi Rafaël,

On Sat, 26 Jul 2014 12:52:44 +0200, Rafaël Carré fun...@videolan.org wrote:
 On 07/21/14 23:21, Stephen Kitt wrote:
 * Merge upstream implementation of strtok_r, so it's available on
   Windows XP. Thanks to Gianluigi Tiesi for pointing out the problem,
   and to Jonathan Young for pointing out that he'd fixed it upstream.
   (Closes: #755448.)
 
 This change breaks VLC, as the strtok_r prototype is not available anymore.
 
 According to:
 http://anonscm.debian.org/gitweb/?p=collab-maint/mingw-w64.git;a=blobdiff;f=debian/patches/strtok_r.patch;h=95e4b5e974f19b5725ad3bd349ac74ec6b2d994d;hp=c4aa476dd10754657fe752ee1aeab9cfa4871a83;hb=8625b8bcfd8a66d92ddbb76391e25ddf9e077857;hpb=362f462455a593a5316c72fdf39dc6df342b3da5
 the prototype is only defined under the condition:
 #if defined (_SVID_SOURCE) || defined (_BSD_SOURCE) || (_POSIX_C_SOURCE
 = 1) || defined(_XOPEN_SOURCE) || defined (_POSIX_SOURCE)

This condition perfectly matches the glibc strtok_r documentation (see
http://man7.org/linux/man-pages/man3/strtok.3.html for example or your local
glibc documentation). But POSIX doesn't specify any conditions (see
http://pubs.opengroup.org/onlinepubs/009695399/functions/strtok.html for
details).

 However autoconf defines neither of these, but only _GNU_SOURCE
 
 glibc's features.h defines all the above features if _GNU_SOURCE is defined,
 but mingw-w64 does not.

I'm not sure it makes sense for mingw-w64 to support _GNU_SOURCE, because
_GNU_SOURCE requests GNU extensions, which aren't available in the Microsoft
runtime. (One could argue that this could be used to request GNU-compatible
extensions provided by mingw-w64 of course...)

 I suggest removing the ifdef altogether, as strtok_r will always be
 available.

Strictly speaking, VLC should define one of the relevant _SOURCE macros
(beyond _GNU_SOURCE) to conform to the glibc documentation (on glibc
platforms), and that would fix the problem as a side-effect on mingw-w64. But
I agree with you, removing the ifdef in mingw-w64 should be fine and would
also fix the problem...

Regards,

Stephen

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Cross compiling the compiler on Linux

[Stephen Kitt]

Hi Ruben,

On Fri, 21 Feb 2014 09:38:10 +0100, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 If you don't mind I've got some comments and/or questions on the content of
 your presentation. Some are just my opinion, feel free to ignore those ;-)

I don't mind at all, thanks for the feedback!

 Apart from the usual
 Debian-makes-everything-much-harder-but-maybe-that's-just-because-they-have-a-sh*tload-of-targets-to-support,
 some specifics:

:-)

I'm hoping the much harder stuff will pay off in the long run!

 - CMake toolchain file: Arch has a mingw-w64-cmake package, which includes
 toolchain files. This enables any CMake-based package to use a centralized
 toolchain package, which reduces maintenance of all these packages. Worth
 considering in my opinion ;-)

Indeed, something like that (and the mingw-make stuff in Fedora) would
probably be helpful, although I would like to make it so that the build
systems just work, and we can simply say take this Debian source package
and build it as-is for Windows (for upstreams which support Windows
targets).

 - mingw-w64-dev contains Pthreads - Why not split this off? It's not
 100% necessary, although c++11 threads and also libgomp rely on this. It
 would also make seperate updates possible, e.g. when a patch is available
 for winpthreads, only that small part needs a rebuild, not the whole
 crt/headers. Also, there are other additional MinGW-w64 libraries and tools
 that you may consider adding to the packages.

Are there plans for separate winpthreads releases? That would be the main
criterion for me. mingw-w64 is quick enough to build anyway (42 min on our
slowest buildd, 4 min on amd64, i386  co.) so re-releasing everything isn't
a problem.

Which libraries and tools are missing? mingw-w64-target-dev ships libmangle,
libpseh, lbpthread and libwinstorecompat, and mingw-w64-tools ships gendef,
genidl and widl. If there's anything else I'd be happy to add it!

 - mingw64 is a terrible name. Comparing it to mingw32 which is also
 terrible just confuses everyone not familiar with what it's supposed to
 mean. Why not just mingw? It's not like MinGW.org is still used by
 Debian, or if it's ever going to support 64-bit without considering merging
 with MinGW-w64 (these are all speculations, but hey, just look at the
 timeline of both projects and the momentum gained by MinGW-w64 over
 MinGW.org).

You're right, it is a terrible name. I'll have to take that up again with the
relevant parties when it becomes the next step (so after config.* is
done)...

  - slide 28.1: What do you mean by How do we define the contents of
 /usr/include? That directory should never be searched by the
 cross-compiler. Instead, it should search /usr/target/include, but on
 multilib that might become more difficult. Note that I introduced a
 non-multilib compiler for Arch, so that any libraries just install to
 prefix=/usr/target and all is well, everything is found automagically, no
 special configure options for every package required. That's also the main
 reason for choosing such an approach.

In Debian currently the MinGW-w64 cross-compilers are non-multilib,
traditional cross-compilers, so they use /usr/target/{include,lib} and
everything works fine.

What I'd like to benefit from is all the multiarch work being done in Debian
now. The rules in multiarch are basically that:
* all target-specific libraries go in /usr/lib/target
* all target-specific headers go in /usr/include/target
* all target-neutral headers go in /usr/include
This allows multiarch cross-compilers (targeting Debian architectures) to
just work in the same way as non-cross-compilers,
without /usr/target/{include,lib}.

That doesn't really seem very interesting in itself; it only becomes
appealing if you consider the task of building lots of software for Windows,
using *existing* Debian packaging, with as few changes as possible (so we
benefit from all the work done on Debian and Ubuntu directly, including
security support etc.).

Imagine adapting a multiarch Debian package so it's usable for MinGW-w64
cross-compiling (assuming the upstream code works in this situation). If I
just build it as-is, the build works, but the files end up
in /usr/include/{i686,x86_64}-w64-mingw32 (for headers which vary depending
on the architecture) *and* /usr/include (for headers which do not vary).
Subsequently, if we want the compiler to be able to use this, we need to have
it check both directories.

The side-effect of this is that we have to be 100% certain that everything
in /usr/include is really target-neutral, including when we extend the
possible targets to include Windows.

The alternative is to stick to the traditional cross-compiler paths, but that
means that every single development package built for MinGW-w64 will have to
have specific changes to put files in the right place.

  - slide 29: isn't autotools support already in upstream sources? I'm not
 sure about the config.guess and config.sub stuff though.

Everything 

Re: [Mingw-w64-public] Cross compiling the compiler on Linux

[Stephen Kitt]

Hi Ingo,

On Tue, 04 Feb 2014 21:40:28 +0100, Ingo Maindorfer i...@liquidcooling.de
wrote:
 how was the talk? Is there a way to get your talk online?

I'm not really the right person to ask, but the audience seemed interested
enough and I discovered a few more MinGW-w64 users. My slides are available
on http://www.sk2.org/talks/ ; it was filmed so there should be a video at
some point.

Regards,

Stephen

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Cross compiling the compiler on Linux

[Stephen Kitt]

Hi,

On Mon, 13 Jan 2014 18:21:12 +0100, Adrien Nader adr...@notk.org wrote:
 On Mon, Jan 13, 2014, Peter Kümmel wrote:
  What's mingw-w64's state-of-the-art way of cross compiling on Linux
  (Ubuntu)?
 
 As Ruben pointed out, you can use the binaries from your distribution.
 In the case of Ubuntu, you inherit the ones from Debian most probably.
 However that means it's going to lag quite a lot, especially if there is
 no corresponding maintainer on ubuntu's side.

The various Debian-based distributions have whatever was current at the time
they freeze (irrespective of when Debian freezes). So Ubuntu 13.10 has
mingw-w64 r5915 (it froze just before 3.0.0 was released), and 14.04 will have
whatever is current when it freezes (it has 3.1.0 currently). gcc-mingw-w64
lagged a bit because of the gnat-4.8 delay, so Ubuntu 13.10 has 4.6.3, but
14.04 will have at least 4.8.2 (and future versions won't have the gnat
problem).

I'm working on introducing a new partial architecture in Debian, which will
allow us to easily (for some value of easily) build lots of libraries and
binaries with security support and all the rest. I'll be talking about this
at the mini-DebConf in Paris this weekend.

Regards,

Stephen (the Debian Developer behind the curtain)

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Fw: Bug#730398: mingw-w64: FTBFS on hppa

[Stephen Kitt]

Hi,

I'm forwarding a patch sent to Debian to allow building widl on hppa.

Regards,

Stephen


Begin forwarded message:

Date: Sun, 24 Nov 2013 12:51:23 -0500
From: John David Anglin dave.ang...@bell.net
To: Debian Bug Tracking System sub...@bugs.debian.org
Subject: Bug#730398: mingw-w64: FTBFS on hppa


Package: mingw-w64
Version: 3.0.0-2
Severity: normal
Tags: patch

gcc-4.8 -DHAVE_CONFIG_H -I. -I../../mingw-w64-tools/widl -I./include
-I../../mingw-w64-tools/widl/include
-DDEFAULT_INCLUDE_DIR=\/usr/include/../i686-w64-mingw32/include\
-D_FORTIFY_SOURCE=2 -O3 -g -Wall -Wformat -Wpacked -Wmissing-declarations
-Wimplicit-function-declaration -Wmissing-prototypes -Wstrict-aliasing=2 -g
-O2 -Wformat -Werror=format-security -c -o src/widl-hash.o `test -f
'src/hash.c' || echo '../../mingw-w64-tools/widl/'`src/hash.c In file
included from ../../mingw-w64-tools/widl/include/winnt.h:24:0,
from ../../mingw-w64-tools/widl/include/windef.h:252,
from ../../mingw-w64-tools/widl/src/hash.c:24: 
../../mingw-w64-tools/widl/include/basetsd.h:325:3:
error: #error Unknown CPU architecture! # error Unknown CPU architecture! ^

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.12.0-rc7+ (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mingw-w64 depends on:
ii  g++-mingw-w64  4.6.4-4+b1+8
ii  gcc-mingw-w64  4.6.4-4+b1+8

mingw-w64 recommends no packages.

mingw-w64 suggests no packages.

-- no debconf information
--- ./mingw-w64-tools/widl/include/basetsd.h.save	2013-11-22 23:06:37.0 -0500
+++ ./mingw-w64-tools/widl/include/basetsd.h	2013-11-24 11:59:37.354363464 -0500
@@ -313,6 +313,10 @@
 # undef  WORDS_BIGENDIAN
 # undef  BITFIELDS_BIGENDIAN
 # undef  ALLOW_UNALIGNED_ACCESS
+#elif defined(__hppa__)
+# undef  WORDS_BIGENDIAN
+# undef  BITFIELDS_BIGENDIAN
+# undef  ALLOW_UNALIGNED_ACCESS
 #elif defined(__ia64__)
 # undef  WORDS_BIGENDIAN
 # undef  BITFIELDS_BIGENDIAN
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] compile C curses program under mingw-w64

[Stephen Kitt]

Hi Daniel,

On Sun, 06 Oct 2013 10:50:41 -0700, Daniel Goldman dgold...@ehdp.com wrote:
   I haven't tried them, but those packages should be usable with a
   mingw-w64 cross-compiler by unpacking them into your sysroot-prefix
   (e.g. /usr/x86_64-w64-mingw32/sys-root/mingw/).
 
 1) I don't find /usr/x86_64-w64-mingw32/sys-root/mingw/ directory. Am I
 supposed to substitute something for sys-root? Anything wrong with my
 setup if no sys-root directory?
 
 $ pwd
 /usr/x86_64-w64-mingw32
 $ find . -name sys-root -print
 $ ls
 include  lib  libsrc
 $ uname -a
 Linux lark 2.6.32-21-generic-pae #32-Ubuntu SMP Fri Apr 16 09:39:35 UTC
 2010 i686 i686 i686 GNU/Linux

If you're using the Ubuntu mingw-w64 packages, that's normal, they don't use
a sysroot.

 2) /usr/x86_64-w64-mingw32/include has 1,119 .h files. I take it I need
 to more or less manually install curses.h to the include directory (and add
 library file). Any reason curses.h is not routinely included as part of the
 distribution? It seems if 1,119 header files, maybe curses might make the
 grade?

I'm working on making mingw-w64 a partial architecture for Debian and Ubuntu,
so eventually you'll get loads of packages in the distributions using
multiarch. In the meantime I'm only shipping mingw-w64.

If you add headers to /usr/{i686,x86_64}-w64-mingw32/include and libraries
to /usr/{i686,x86_64}-w64-mingw32/lib, the compiler will pick them up. The
latest version of mingw-w64 also ships {i686,x86_64}-w64-mingw32-pkg-config
so you can also add .pc files to /usr/{i686,x86_64}-w64-mingw32/lib/pkgconfig
and have them picked by configure scripts too.

Regards,

Stephen

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH mingw-w64] Restore libvfw32.a in 32-bit builds

[Stephen Kitt]

Hi,

Revision 6256 dropped libvfw32.a, the following patch restores it (I fixed
mingw-w64-crt/lib32/Makefile.am and regenerated the Makefile.in).

The patch also applies to stable (v3.0.0).

Signed-off-by: Stephen Kitt sk...@debian.org

Index: mingw-w64-crt/Makefile.in
===
--- mingw-w64-crt/Makefile.in   (revision 6311)
+++ mingw-w64-crt/Makefile.in   (working copy)
@@ -4214,35 +4214,35 @@
 @LIB32_TRUE@   lib32/libusp10.a lib32/libuxtheme.a \
 @LIB32_TRUE@   lib32/libvdmdbg.a lib32/libversion.a \
 @LIB32_TRUE@   lib32/libvideoprt.a lib32/libvirtdisk.a \
-@LIB32_TRUE@   lib32/libvss_ps.a lib32/libvssapi.a \
-@LIB32_TRUE@   lib32/libvsstrace.a lib32/libwdsclient.a \
-@LIB32_TRUE@   lib32/libwdsclientapi.a lib32/libwdscore.a \
-@LIB32_TRUE@   lib32/libwdscsl.a lib32/libwdsimage.a \
-@LIB32_TRUE@   lib32/libwdstptc.a lib32/libwdsupgcompl.a \
-@LIB32_TRUE@   lib32/libwdsutil.a lib32/libwecapi.a \
-@LIB32_TRUE@   lib32/libwer.a lib32/libwevtapi.a \
-@LIB32_TRUE@   lib32/libwevtfwd.a lib32/libwin32k.a \
-@LIB32_TRUE@   lib32/libwin32spl.a lib32/libwindowscodecs.a \
-@LIB32_TRUE@   lib32/libwinhttp.a lib32/libwininet.a \
-@LIB32_TRUE@   lib32/libwinmm.a lib32/libwinscard.a \
-@LIB32_TRUE@   lib32/libwinspool.a lib32/libwinstrm.a \
-@LIB32_TRUE@   lib32/libwinusb.a lib32/libwkscli.a \
-@LIB32_TRUE@   lib32/libwlanapi.a lib32/libwlanui.a \
-@LIB32_TRUE@   lib32/libwlanutil.a lib32/libwldap32.a \
-@LIB32_TRUE@   lib32/libwow32.a lib32/libwsdapi.a \
-@LIB32_TRUE@   lib32/libwsnmp32.a lib32/libwsock32.a \
-@LIB32_TRUE@   lib32/libwst.a lib32/libwtsapi32.a \
-@LIB32_TRUE@   lib32/libx3daudio1_2.a lib32/libx3daudio1_3.a \
-@LIB32_TRUE@   lib32/libx3daudio1_4.a lib32/libx3daudio1_5.a \
-@LIB32_TRUE@   lib32/libx3daudio1_6.a lib32/libx3daudio1_7.a \
-@LIB32_TRUE@   lib32/libx3daudiod1_7.a lib32/libxapofx1_0.a \
-@LIB32_TRUE@   lib32/libxapofx1_1.a lib32/libxapofx1_2.a \
-@LIB32_TRUE@   lib32/libxapofx1_3.a lib32/libxapofx1_4.a \
-@LIB32_TRUE@   lib32/libxapofx1_5.a lib32/libxapofxd1_5.a \
-@LIB32_TRUE@   lib32/libxaudio2_8.a lib32/libxinput1_1.a \
-@LIB32_TRUE@   lib32/libxinput1_2.a lib32/libxinput1_3.a \
-@LIB32_TRUE@   lib32/libxinput1_4.a lib32/libxinput9_1_0.a \
-@LIB32_TRUE@   $(am__append_5)
+@LIB32_TRUE@   lib32/libvfw32.a lib32/libvss_ps.a \
+@LIB32_TRUE@   lib32/libvssapi.a lib32/libvsstrace.a \
+@LIB32_TRUE@   lib32/libwdsclient.a lib32/libwdsclientapi.a \
+@LIB32_TRUE@   lib32/libwdscore.a lib32/libwdscsl.a \
+@LIB32_TRUE@   lib32/libwdsimage.a lib32/libwdstptc.a \
+@LIB32_TRUE@   lib32/libwdsupgcompl.a lib32/libwdsutil.a \
+@LIB32_TRUE@   lib32/libwecapi.a lib32/libwer.a \
+@LIB32_TRUE@   lib32/libwevtapi.a lib32/libwevtfwd.a \
+@LIB32_TRUE@   lib32/libwin32k.a lib32/libwin32spl.a \
+@LIB32_TRUE@   lib32/libwindowscodecs.a lib32/libwinhttp.a \
+@LIB32_TRUE@   lib32/libwininet.a lib32/libwinmm.a \
+@LIB32_TRUE@   lib32/libwinscard.a lib32/libwinspool.a \
+@LIB32_TRUE@   lib32/libwinstrm.a lib32/libwinusb.a \
+@LIB32_TRUE@   lib32/libwkscli.a lib32/libwlanapi.a \
+@LIB32_TRUE@   lib32/libwlanui.a lib32/libwlanutil.a \
+@LIB32_TRUE@   lib32/libwldap32.a lib32/libwow32.a \
+@LIB32_TRUE@   lib32/libwsdapi.a lib32/libwsnmp32.a \
+@LIB32_TRUE@   lib32/libwsock32.a lib32/libwst.a \
+@LIB32_TRUE@   lib32/libwtsapi32.a lib32/libx3daudio1_2.a \
+@LIB32_TRUE@   lib32/libx3daudio1_3.a lib32/libx3daudio1_4.a \
+@LIB32_TRUE@   lib32/libx3daudio1_5.a lib32/libx3daudio1_6.a \
+@LIB32_TRUE@   lib32/libx3daudio1_7.a lib32/libx3daudiod1_7.a \
+@LIB32_TRUE@   lib32/libxapofx1_0.a lib32/libxapofx1_1.a \
+@LIB32_TRUE@   lib32/libxapofx1_2.a lib32/libxapofx1_3.a \
+@LIB32_TRUE@   lib32/libxapofx1_4.a lib32/libxapofx1_5.a \
+@LIB32_TRUE@   lib32/libxapofxd1_5.a lib32/libxaudio2_8.a \
+@LIB32_TRUE@   lib32/libxinput1_1.a lib32/libxinput1_2.a \
+@LIB32_TRUE@   lib32/libxinput1_3.a lib32/libxinput1_4.a \
+@LIB32_TRUE@   lib32/libxinput9_1_0.a $(am__append_5)
 @LIB32_TRUE@dx32_DATA = lib32/libxinput.a lib32/libxapofx.a \
 @LIB32_TRUE@   lib32/libx3daudio.a lib32/libd3dx9.a \
 @LIB32_TRUE@   lib32/libd3dx10.a lib32/libd3dx11.a \
Index: mingw-w64-crt/lib32/Makefile.am
===
--- mingw-w64-crt/lib32/Makefile.am (revision 6311)
+++ mingw-w64-crt/lib32/Makefile.am (working copy)
@@ -263,6 +263,7 @@
 lib32_DATA += %reldir%/libversion.a
 lib32_DATA += %reldir%/libvideoprt.a
 lib32_DATA += %reldir%/libvirtdisk.a
+lib32_DATA += %reldir%/libvfw32.a
 lib32_DATA += %reldir%/libvss_ps.a
 lib32_DATA += %reldir%/libvssapi.a
 lib32_DATA += %reldir%/libvsstrace.a

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http

[Mingw-w64-public] Patch allowing d2d1.h to be used (endif instead of endinf)

[Stephen Kitt]

Hi,

Current svn trunk has a couple of #endinf statements instead of #endif in
d2d1.h. The following patch fixes this:

Index: mingw-w64-headers/include/d2d1.h
===
--- mingw-w64-headers/include/d2d1.h(revision 4799)
+++ mingw-w64-headers/include/d2d1.h(working copy)
@@ -2329,7 +2329,7 @@
 */
 #ifdef __cplusplus
 extern C {
-#endinf
+#endif
 
 HRESULT WINAPI D2D1CreateFactory(
   D2D1_FACTORY_TYPE factoryType,
@@ -2360,6 +2360,6 @@
 );
 #ifdef __cplusplus
 }
-#endinf
+#endif
 
 #endif /* _D2D1_H */


Regards,

Stephen


signature.asc
Description: PGP signature
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] difference between your projects

[Stephen Kitt]

Hi William,

On Tue, 03 Jan 2012 18:53:08 +0100 (CET), r...@libertysurf.fr wrote:
 I would like to understand better what is the difference between your two
 projects, in term of cross-compilation capabilities (linux - windows).
 mingw-64 seems to be a much bigger project, but has not factual
 documentation on how to actually setup the cross-compiling environment. I
 am under debian, and would like to port applications to windows.

If you're using Debian you might like to check out the mingw-w64 packages
which are available in testing (wheezy) and unstable (sid):
http://packages.debian.org/mingw-w64
(The package in stable is rather old.)

Regards,

Stephen

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public