[Mingw-w64-public] mingw-w64 port of mpg123

[JonY]

Hello,

I'm trying to port mpg123 over to win64, the patch in its current form 
is very intrusive, but it compiles with generic_nofpu mode without 
warnings and works fine. No plans to port the .S files yet, I don't know 
asm. I am using MSYS with a mingw-w64 cross-compiler to build the binaries.


I'm hoping that somebody can give me some leads on how to fix the patch 
and add it into the mpg123 svn trunk.


Some notes from porting:
1. mingw-w64 doesn't have libwsock, but has libws2_32, 32bit MinGW has both.

2. Microsoft decided int should be 32bits long on win64.

3. waveOutOpen uses DWORD_PTR instead of DWORD. 



4. DWORD_PTR is somewhat more portable than 
DWORD.


5. libmpg123.sym does not seem to be auto-generated, leading to 
undefined references errors when building the win64 dll, problem stems 
from @largefile_suf...@. Win64 uses 64bit offsets but doesn't have 
notions about POSIX largefile conventions.


6. A newer version of libtool is required for auto* regeneration. The 
current shipped version fails the file magic test for 64bit libws2_32.
diff -ru mpg123-1.6.4-1/configure.ac mpg123-1.6.4-2/configure.ac
--- mpg123-1.6.4-1/configure.ac 2009-01-10 22:47:06.0 +0800
+++ mpg123-1.6.4-2/configure.ac 2009-02-08 18:17:35.0 +0800
@@ -619,7 +619,7 @@
 cpu_type="generic_fpu"
   ;;
   *-*-mingw32)
-LIBS="-lwsock32 $LIBS"
+LIBS="-lws2_32 $LIBS"
 buffer=disabled
 cpu_type="x86"
   ;;
diff -ru mpg123-1.6.4-1/src/audio.h mpg123-1.6.4-2/src/audio.h
--- mpg123-1.6.4-1/src/audio.h  2009-01-10 22:45:40.0 +0800
+++ mpg123-1.6.4-2/src/audio.h  2009-02-08 17:02:43.0 +0800
@@ -38,7 +38,7 @@
 
 typedef struct audio_output_struct
 {
-   int fn; /* filenumber */
+   int64_t fn; /* filenumber */
void *userptr;  /* driver specific pointer */

/* Callbacks */
diff -ru mpg123-1.6.4-1/src/libmpg123/libmpg123.sym 
mpg123-1.6.4-2/src/libmpg123/libmpg123.sym
--- mpg123-1.6.4-1/src/libmpg123/libmpg123.sym  2009-01-10 22:52:32.0 
+0800
+++ mpg123-1.6.4-2/src/libmpg123/libmpg123.sym  2009-02-08 18:20:29.0 
+0800
@@ -59,17 +59,17 @@
 mpg123_replace_buffer
 mpg123_outblock
 mpg123_replace_reader
-mpg123_open_64
-mpg123_open_fd_64
-mpg123_decode_frame_64
-mpg123_tell_64
-mpg123_tellframe_64
-mpg123_tell_stream_64
-mpg123_seek_64
-mpg123_feedseek_64
-mpg123_seek_frame_64
-mpg123_timeframe_64
-mpg123_index_64
-mpg123_position_64
-mpg123_length_64
-mpg123_set_filesize_64
+mpg123_open
+mpg123_open_fd
+mpg123_decode_frame
+mpg123_tell
+mpg123_tellframe
+mpg123_tell_stream
+mpg123_seek
+mpg123_feedseek
+mpg123_seek_frame
+mpg123_timeframe
+mpg123_index
+mpg123_position
+mpg123_length
+mpg123_set_filesize
diff -ru mpg123-1.6.4-1/src/output/win32.c mpg123-1.6.4-2/src/output/win32.c
--- mpg123-1.6.4-1/src/output/win32.c   2009-01-10 22:45:40.0 +0800
+++ mpg123-1.6.4-2/src/output/win32.c   2009-02-08 17:07:10.0 +0800
@@ -68,7 +68,7 @@
out_fmt.cbSize = 0;
 
res = waveOutOpen((HWAVEOUT*)&ao->fn, dev_id, &out_fmt,
- (DWORD)state->play_done_event, 0, CALLBACK_EVENT);
+ (DWORD_PTR)state->play_done_event, 0, CALLBACK_EVENT);
 
switch(res)
{
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-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] basic question

[JonY]

On 7/2/2009 06:46, McWilliams, Steven wrote:
> I have a basic question about mingw-w64 that I need help with please.  In the 
> past I have used msys+mingw to compile postgres to run on 32 bit windows 
> platforms.  Now I would like to be able to compile postgres to run on 64 bit 
> windows platforms, for which I am trying to use msys+mingw-w64.
>
> I downloaded the mingw-w64_x86-64_mingw32_4.4.0-1.zip file and unzipped it 
> into c:\mingw_64 on my 64 bit windows platform.  How do I hook it up for use 
> with msys however?  Normally I edit the msys /etc/fstab file and add the 
> entry "/c/mingw /mingw" to do so, so my first assumption was to change the 
> entry to "/c/mingw_64 /mingw" in this case, or perhaps "c/mingw_64/mingw 
> /mingw", however neither approach ends up with a version of gcc.exe in the 
> msys path which works.
>
> Seems like I am missing something fundamental about how to use mingw-w64.
>
> Thanks in advance,
> Steve
>

Hi,

posting the error message will always help to diagnose your problem, so 
what was your error message?

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

Re: [Mingw-w64-public] basic question

[JonY]

On 7/2/2009 21:40, McWilliams, Steven wrote:
> If I have the msys /etc/fstab setting "/c/mingw_64 /mingw" and I try to 
> compile a little hello-world type C program via "gcc.exe hello.c" I get the 
> error "sh: gcc exe: command not found", which makes sense since 
> c:\mingw_64\bin does not have a gcc.exe file.
>
> If I have the msys /etc/fstab setting "/c/mingw_64/mingw /mingw" and I try to 
> compile via "gcc.exe hello.c" I get the error "gcc.exe: CreateProcess: No 
> such file or directory".
>
> The only way I can get the compilation to work is if I have the msys 
> /etc/fstab setting "/c/mingw_64 /mingw" and I try to compile via 
> "x86_64-w64-mingw32-gcc.exe hello.c", since x86_64-w64-mingw32-gcc.exe is 
> present in c:\mingw_64\bin.  That works ok for compiling a little hello-world 
> type C program, however it fails when I try to compile postgres.  If I try to 
> configure postgres for compilation using "CC=x86_64-w64-mingw32-gcc.exe 
> ./configure --without-zlib --prefix=/c/postgresql" it generates the following 
> error:
>
> ...
> checking types of arguments for accespt()... configure: error: could not 
> determine argument types
>

Hi,
You are using the correct "x86_64-w64-mingw32-gcc.exe" frontend.

The issue is accespt(), where is it supposed to come from? Its not on MSDN.

Please post the "config.log" file, the more details, the better.

Thanks.


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

[Mingw-w64-public] [PATCH] Add new test

[JonY]

Hi,

The first patch will add a new test to Makefile.am. The second will 
correct the t_tmain test. NightStrike, mind regenerating makefile.in?


Thanks.
From 01a13a8cc922200122294d3396872fab40f32745 Mon Sep 17 00:00:00 2001
From: jon_y 
Date: Fri, 14 Aug 2009 18:52:19 +0800
Subject: [PATCH 1/2] Add new t_intrinc test

---
 Makefile.am |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e1fb1cf..60fcbf3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -919,6 +919,7 @@ dist-hook:
 #  testcases/t_nullptrexception.c  testcases/tstmain.c   
testcases/tstwassert.c   testcases/t_trycatch.cpp
 check_PROGRAMS = \
   testcases/t_float  \
+  testcases/t_intrinc \
   testcases/t_setjmp \
   testcases/tstwassert_win \
   testcases/t_matherr \
@@ -939,5 +940,6 @@ testcases_tstmaincpp_SOURCES = testcases/tstmaincpp.cpp
 testcases_t_trycatch_SOURCES = testcases/t_trycatch.cpp
 testcases_t_municode_CFLAGS = -municode
 testcases_t_tmain_CFLAGS = -municode
+testcases_t_intrinc_CFLAGS = -std=c99
 
 TESTS = $(check_PROGRAMS)
-- 
1.6.3.1

From 72a7998970683459a4d0aed236160252e25038c2 Mon Sep 17 00:00:00 2001
From: jon_y 
Date: Fri, 14 Aug 2009 18:53:42 +0800
Subject: [PATCH 2/2] Fix t_tmain test

---
 Makefile.am |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 60fcbf3..7205b8e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -939,7 +939,7 @@ testcases_tstwinmain_LDADD = -lgdi32
 testcases_tstmaincpp_SOURCES = testcases/tstmaincpp.cpp
 testcases_t_trycatch_SOURCES = testcases/t_trycatch.cpp
 testcases_t_municode_CFLAGS = -municode
-testcases_t_tmain_CFLAGS = -municode
+testcases_t_tmain_CFLAGS = -municode -D_UNICODE
 testcases_t_intrinc_CFLAGS = -std=c99
 
 TESTS = $(check_PROGRAMS)
-- 
1.6.3.1

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Add warning flags to CRT build

[JonY]

Hi,

This patch will add warning flags.

There are currently 5 warning levels, which defaults to level 3. It gets 
noisier for higher levels. Level 0 is equivalent to no additional flags. 
Use "--with-warnings[=n]" to set the levels.


I really wanted -Werror by default, so you can stop to see *all* the 
warnings, but its too strict for buildbot.


The warning levels can still be fine tuned. If needed, there can also be 
more warning levels.


Comments?
Index: configure.ac
===
--- configure.ac(revision 1170)
+++ configure.ac(working copy)
@@ -112,6 +112,38 @@
 
 AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the 
mingw-w64 header set and the build/host option are set properly.])])
 
+#Warnings and errors, default level is 3
+AC_ARG_WITH([warnings],
+[AS_HELP_STRING([[--with-warnings[=0-5]]], [Set compile time 
warning levels (default is 3)])],
+[warning_level=$withval],
+[warning_level=3]
+)
+
+#Warning level validation
+AS_IF([test "$warning_level" == yes], [warning_level=3], [test 
"$warning_level" == no], [warning_level=0])
+AS_IF([test $warning_level -gt 5 || test $warning_level -lt 0], 
[warning_level=3])
+AC_MSG_CHECKING([for warning levels])
+AC_MSG_RESULT([Level $warning_level])
+
+#Add CPPFLAGS, CFLAGS, CXXFLAGS as appropriate. Level 4 and above is only for 
testing purpose.
+AS_CASE([$warning_level],
+[0],[],
+[1],[ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra"
+ ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration"],
+[2],[ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline" 
+ ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration"],
+[3],[ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=3" 
+ ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"],
+[4],[ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=2 -Werror -pedantic" 
+ ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"]
+[5],[ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=2 -Werror -Wfatal-errors -pedantic -pedantic-errors" 
+ ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"]
+)
+
+AC_SUBST(ADD_C_ONLY_WARNING_FLAGS)
+AC_SUBST(ADD_C_CXX_WARNING_FLAGS)
+AC_SUBST(ADD_CXX_ONLY_WARNING_FLAGS)
+
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
 
@@ -125,9 +157,12 @@
 AC_MSG_NOTICE([])
 AC_MSG_NOTICE([Configuration Options Summary:])
 AC_MSG_NOTICE([])
-AC_MSG_NOTICE([  WinCE runtime.: $enable_libce])
-AC_MSG_NOTICE([  Win32 runtime.: $enable_lib32])
-AC_MSG_NOTICE([  Win64 runtime.: $enable_lib64])
+AC_MSG_NOTICE([  WinCE runtime: $enable_libce])
+AC_MSG_NOTICE([  Win32 runtime: $enable_lib32])
+AC_MSG_NOTICE([  Win64 runtime: $enable_lib64])
+AC_MSG_NOTICE([  C Warning Flags..: $ADD_C_ONLY_WARNING_FLAGS])
+AC_MSG_NOTICE([  C++ Warning Flags: $ADD_CXX_ONLY_WARNING_FLAGS])
+AC_MSG_NOTICE([  Common Warning Flags.: $ADD_C_CXX_WARNING_FLAGS])
 AC_MSG_NOTICE([])
 
 
Index: Makefile.am
===
--- Makefile.am (revision 1170)
+++ Makefile.am (working copy)
@@ -22,7 +22,8 @@
 
 
 AM_CPPFLAGS=-D_CRTBLD $(sysincludes)
-AM_CFLAGS=-pipe $(vistasupport) -Wall -Wno-strict-aliasing -std=gnu99
+AM_CFLAGS=-pipe $(vistasupport) -Wall -Wno-strict-aliasing -std=gnu99 
@ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
+am_cxxfla...@add_cxx_only_warning_flags@ @ADD_CXX_ONLY_WARNING_FLAGS@
 AM_DLLTOOLFLAGS=-k --as=$(AS) --output-lib $@
 DTDEF=$(DLLTOOL) $(AM_DLLTOOLFLAGS) --def
 DTLIB=$(DTDEF) $(top_srcdir)/`echo $@ | $(SED) 's|/lib|/|;s|\.a|.def|'`
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
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] Add warning flags to CRT build

[JonY]

On 8/17/2009 16:30, Ozkan Sezer wrote:
> On Mon, Aug 17, 2009 at 10:49 AM, JonY<10wa...@gmail.com>  wrote:
>> Hi,
>>
>> This patch will add warning flags.
>>
>> There are currently 5 warning levels, which defaults to level 3. It gets
>> noisier for higher levels. Level 0 is equivalent to no additional flags. Use
>> "--with-warnings[=n]" to set the levels.
>>
>> I really wanted -Werror by default, so you can stop to see *all* the
>> warnings, but its too strict for buildbot.
>>
>> The warning levels can still be fine tuned. If needed, there can also be
>> more warning levels.
>>
>> Comments?
>
> This is a good one. I'd also suggest that you remove the
> default -Wno-strict-aliasing flag from Makefile.am. And also
> yocan increase the -Wstrict-aliasing level with increased
> level of warning to -Wstrict-aliasing=2, say at level four?
>

Hi,
yeah, I was about to remove the -Wno-strict-aliasing but forgot.

For the -Wstrict-aliasing level, 
<http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Warning-Options.html> says 
3 is the default, with 2 being less accurate but faster and 1 being 
prone to false positives. Level 4 already uses -Wstrict-aliasing=2.

There is also a C++ specific warning flag, though I haven't come across 
any important warnings. I added it for completeness.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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-users] Proposed change to gendef output format

[JonY]

On 8/17/2009 19:12, Erik Leunissen wrote:
> After having experimented with gendef, I'd like to suggest a few changes
> regarding the .def output:
>
> The format of the generated .def file differs from the .def files around
> the globe in two ways:
> - it has a program info header
> - it surrounds the name of the inspected binary with double quotes
>
> See also
> http://sourceware.org/binutils/docs-2.16/binutils/def-file-format.html
> for a format specification.
>
> I suggest making the .def output conform to this "standard" format so
> that its processing can be better automated.
>
> I have been looking at the source and it seems a very simple change
> which I can supply if desired.
>
>
> Please let me know if that fits into the development plans for gendef.
>
> Erik Leunissen.

Hi,
Adding mingw-w64-public to CC.

Anyway, program "gendef" header can be ignored, its placed in the 
comments section. The double quotes are needed to allow dlls with spaces 
in the name. I have to admit that the specs don't say anything about 
quotation marks.

You can use tracker at  
to file requests, or contact the developers directly via irc at 
#mingw-w64 on irc.oftc.net.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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] Add warning flags to CRT build

[JonY]

On 8/17/2009 22:37, NightStrike wrote:

1) Put the "AC_MSG_CHECKING" at the beginning, before you start the checking.


Ok, done.


2) Features like this should be an "enable" thing, not a "with" thing.
  "with" things are more for external tools.


Ok, done. I was wondering about that...


3) Keep the same formatting that's elsewhere in the file, or otherwise
change the whole file.  For instance, look at the formatting and
indentation of other HELP_STRING instances.


I hope the new indentation is better.


4) You mention CPPFLAGS in your comment, but it's not used for this
kind of stuff


I was using it, but forgot to change it. Sorry, outdated comment.


5) You deal with CXXFLAGS -- Where do we use C++?  We may definitely
do it.. I don't remember


The variable is mainly used to allow C++ specific warning flags, not all 
of the warning parameters can be shared. The C++ code is in the testcase 
directory.



6) This line in Makefile.am is probably wrong:
+am_cxxfla...@add_cxx_only_warning_flags@ @ADD_CXX_ONLY_WARNING_FLAGS@

One of those should probably be ADD_C_CXX...



Thanks for catching that.


7) This line should really be a part of the "action if given" /
"action if not given" section of the option string handler, to be
consistent with the rest of the file:

+AS_IF([test "$warning_level" == yes], [warning_level=3], [test
"$warning_level" == no], [warning_level=0])

For instance, instead of "+[warning_level=$withval],",
just operate on withval directly:

[AS_IF([test "$withval" == yes], [warning_level=3],[warning_level=$withval])],

Same for the action if not given, and withval = no.

Also, as before, follow the formatting of the rest of the file
regarding indentation.



Ok, the logic check is now included in the AC_ARG_ENABLE part.


On a more general note, I'm wondering if there isn't a better way to
compute all of this in Makefile.am.  Automake supports conditionals,
which makes the additive nature of successive levels much more simply
handled there.  The idea is that you should keep configure stuff in
configure, and make stuff in make.




With AM_CONDITIONALs, but the code below is the best I can come up with.

if WARNLEVEL0
C_Warn0=...
C_CXX_WARN0=...
endif
if WARNLEVEL1
C_Warn0=...
C_CXX_WARN0=...
endif
AM_CFLAGS=$(C_Warn0) $(C_Warn1) $(C_Warn2)...

If its ok, I'll use the above code in Makefile.am

Updated patch attached. Suggestions welcome, especially simplifying the 
AM_CFLAGS part. Testers are welcome too.
Index: configure.ac
===
--- configure.ac(revision 1174)
+++ configure.ac(working copy)
@@ -112,6 +112,44 @@
 
 AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the 
mingw-w64 header set and the build/host option are set properly.])])
 
+#Warnings and errors, default level is 3
+AC_MSG_CHECKING([for warning levels])
+AC_ARG_ENABLE([warnings],
+  [AS_HELP_STRING([[--enable-warnings[=0-5]]], 
+[Enable compile time warnings (default is 3)])],
+  [if   test "$enableval" = no;  then warning_level=0
+   elif test "$enableval" = yes; then warning_level=3
+   elif test $enableval -gt 5 || test $warning_level -lt 0; then 
warning_level=3
+   else warning_level=$enableval
+   fi
+  ],
+  [warning_level=3])
+AC_MSG_RESULT([Level $warning_level])
+
+#Add warning flags as appropriate. Level 4 and above are only for testing 
purpose.
+AS_CASE([$warning_level],
+  [0],[ADD_C_CXX_WARNING_FLAGS="-Wall"],
+  [1],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra"
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration"],
+  [2],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration"],
+  [3],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=3" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"],
+  [4],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=2 -Werror -pedantic" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"]
+  [5],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=2 -Werror -Wfatal-errors -pedantic -pedantic-errors" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"]
+   )
+
+AC_SUBST(ADD_C_ONLY_WARNING_FLAGS)
+AC_SUBST(ADD_C_CXX_WARNING_FLAGS)
+AC_SUBST(ADD_CXX_ONLY_WARNING_FLAGS)
+
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
 
@@ -125,9 +163,12 @@
 AC_MSG_NOTICE([])
 AC

Re: [Mingw-w64-public] [PATCH] Add warning flags to CRT build

[JonY]

On 8/18/2009 00:28, JonY wrote:

On 8/17/2009 22:37, NightStrike wrote:

1) Put the "AC_MSG_CHECKING" at the beginning, before you start the
checking.


Ok, done.


2) Features like this should be an "enable" thing, not a "with" thing.
"with" things are more for external tools.


Ok, done. I was wondering about that...


3) Keep the same formatting that's elsewhere in the file, or otherwise
change the whole file. For instance, look at the formatting and
indentation of other HELP_STRING instances.


I hope the new indentation is better.


4) You mention CPPFLAGS in your comment, but it's not used for this
kind of stuff


I was using it, but forgot to change it. Sorry, outdated comment.


5) You deal with CXXFLAGS -- Where do we use C++? We may definitely
do it.. I don't remember


The variable is mainly used to allow C++ specific warning flags, not all
of the warning parameters can be shared. The C++ code is in the testcase
directory.


6) This line in Makefile.am is probably wrong:
+am_cxxfla...@add_cxx_only_warning_flags@ @ADD_CXX_ONLY_WARNING_FLAGS@

One of those should probably be ADD_C_CXX...



Thanks for catching that.


7) This line should really be a part of the "action if given" /
"action if not given" section of the option string handler, to be
consistent with the rest of the file:

+AS_IF([test "$warning_level" == yes], [warning_level=3], [test
"$warning_level" == no], [warning_level=0])

For instance, instead of "+ [warning_level=$withval],",
just operate on withval directly:

[AS_IF([test "$withval" == yes],
[warning_level=3],[warning_level=$withval])],

Same for the action if not given, and withval = no.

Also, as before, follow the formatting of the rest of the file
regarding indentation.



Ok, the logic check is now included in the AC_ARG_ENABLE part.


On a more general note, I'm wondering if there isn't a better way to
compute all of this in Makefile.am. Automake supports conditionals,
which makes the additive nature of successive levels much more simply
handled there. The idea is that you should keep configure stuff in
configure, and make stuff in make.




With AM_CONDITIONALs, but the code below is the best I can come up with.

if WARNLEVEL0
C_Warn0=...
C_CXX_WARN0=...
endif
if WARNLEVEL1
C_Warn0=...
C_CXX_WARN0=...
endif
AM_CFLAGS=$(C_Warn0) $(C_Warn1) $(C_Warn2)...

If its ok, I'll use the above code in Makefile.am

Updated patch attached. Suggestions welcome, especially simplifying the
AM_CFLAGS part. Testers are welcome too.


Hi,
Attached updated patch, this time using case, much cleaner than if/else 
tests. The "[yes], [warning_level=3]," part is probably redundant.
Index: configure.ac
===
--- configure.ac(revision 1174)
+++ configure.ac(working copy)
@@ -112,6 +112,42 @@
 
 AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the 
mingw-w64 header set and the build/host option are set properly.])])
 
+#Warnings and errors, default level is 3
+AC_MSG_CHECKING([for warning levels])
+AC_ARG_ENABLE([warnings],
+  [AS_HELP_STRING([[--enable-warnings[=0-5]]], 
+[Enable compile time warnings @<:@default=3@:>@])],
+  [AS_CASE(["$enableval"],
+[no],  [warning_level=0],
+[[[0-5]]], warning_level="$enableval",
+[warning_level=3])],
+  [warning_level=3])
+AC_MSG_RESULT([Level $warning_level])
+
+#Add warning flags as appropriate. Level 4 and above are only for testing 
purpose.
+AS_CASE([$warning_level],
+  [0],[ADD_C_CXX_WARNING_FLAGS="-Wall"],
+  [1],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra"
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration"],
+  [2],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration"],
+  [3],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=3" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"],
+  [4],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=2 -Werror -pedantic" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"]
+  [5],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=2 -Werror -Wfatal-errors -pedantic -pedantic

Re: [Mingw-w64-public] [PATCH] Add warning flags to CRT build

[JonY]

On 8/18/2009 15:09, NightStrike wrote:

+  [AS_CASE(["$enableval"],

no quotes

+[[[0-5]]], warning_level="$enableval",
bracket the second argument


Approved with those two changes and your own testing, of course.



OK, new patch attached.
Index: configure.ac
===
--- configure.ac(revision 1174)
+++ configure.ac(working copy)
@@ -112,6 +112,43 @@
 
 AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the 
mingw-w64 header set and the build/host option are set properly.])])
 
+#Warnings and errors, default level is 3
+AC_MSG_CHECKING([for warning levels])
+AC_ARG_ENABLE([warnings],
+  [AS_HELP_STRING([[--enable-warnings[=0-5]]], 
+[Enable compile time warnings @<:@default=3@:>@])],
+  [AS_CASE([$enableval],
+[yes], [warning_level=3],
+[no],  [warning_level=0],
+[[[0-5]]], [warning_level="$enableval"],
+[warning_level=3])],
+  [warning_level=3])
+AC_MSG_RESULT([Level $warning_level])
+
+#Add warning flags as appropriate. Level 4 and above are only for testing 
purpose.
+AS_CASE([$warning_level],
+  [0],[ADD_C_CXX_WARNING_FLAGS="-Wall"],
+  [1],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra"
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration"],
+  [2],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration"],
+  [3],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=3" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"],
+  [4],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=2 -Werror -pedantic" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"]
+  [5],[
+ADD_C_CXX_WARNING_FLAGS="-Wall -Wextra -Wformat -Wstrict-aliasing 
-Wsystem-headers -Wshadow -Wmissing-declarations -Wpacked -Wredundant-decls 
-Winline -Wstrict-aliasing=2 -Werror -Wfatal-errors -pedantic -pedantic-errors" 
+ADD_C_ONLY_WARNING_FLAGS="-Wimplicit-function-declaration 
-Wmissing-noreturn -Wmissing-prototypes"]
+   )
+
+AC_SUBST(ADD_C_ONLY_WARNING_FLAGS)
+AC_SUBST(ADD_C_CXX_WARNING_FLAGS)
+AC_SUBST(ADD_CXX_ONLY_WARNING_FLAGS)
+
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
 
@@ -125,9 +162,12 @@
 AC_MSG_NOTICE([])
 AC_MSG_NOTICE([Configuration Options Summary:])
 AC_MSG_NOTICE([])
-AC_MSG_NOTICE([  WinCE runtime.: $enable_libce])
-AC_MSG_NOTICE([  Win32 runtime.: $enable_lib32])
-AC_MSG_NOTICE([  Win64 runtime.: $enable_lib64])
+AC_MSG_NOTICE([  WinCE runtime: $enable_libce])
+AC_MSG_NOTICE([  Win32 runtime: $enable_lib32])
+AC_MSG_NOTICE([  Win64 runtime: $enable_lib64])
+AC_MSG_NOTICE([  C Warning Flags..: $ADD_C_ONLY_WARNING_FLAGS])
+AC_MSG_NOTICE([  C++ Warning Flags: $ADD_CXX_ONLY_WARNING_FLAGS])
+AC_MSG_NOTICE([  Common Warning Flags.: $ADD_C_CXX_WARNING_FLAGS])
 AC_MSG_NOTICE([])
 
 
Index: Makefile.am
===
--- Makefile.am (revision 1174)
+++ Makefile.am (working copy)
@@ -20,9 +20,9 @@
   withsys=
 endif
 
-
 AM_CPPFLAGS=-D_CRTBLD $(sysincludes)
-AM_CFLAGS=-pipe $(vistasupport) -Wall -Wno-strict-aliasing -std=gnu99
+AM_CFLAGS=-pipe $(vistasupport) -std=gnu99 @ADD_C_CXX_WARNING_FLAGS@ 
@ADD_C_ONLY_WARNING_FLAGS@
+am_cxxfla...@add_c_cxx_warning_flags@ @ADD_CXX_ONLY_WARNING_FLAGS@
 AM_DLLTOOLFLAGS=-k --as=$(AS) --output-lib $@
 DTDEF=$(DLLTOOL) $(AM_DLLTOOLFLAGS) --def
 DTLIB=$(DTDEF) $(top_srcdir)/`echo $@ | $(SED) 's|/lib|/|;s|\.a|.def|'`
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
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 builds of gmp and mpfr

[JonY]

On 8/24/2009 20:15, Sisyphus wrote:
> Hi,
>
> I'm running Vista64, and I got my mingw-w64 compiler from the
> mingw-w64-bin_i686-mingw_20090819.zip package.
>
> I have the 64-bit builds of gmp and mpfr that come with
> mingw-w64-bin-gmp-mpfr-20080604.tar.bz2 .
>
> In the latter package, mpfr is still at 2.3.1. Is there a 2.4.x build of
> mpfr available somewhere ?


Hi,
Please do not hijack threads, instead, start your own thread and do not 
use the "reply" function in your email client to post messages unrelated 
to your issue. Use the "New" message function instead.

You can build 2.4.x it from source, grab it at .

> Also, is it yet feasible to build gmp and mpfr in the msys shell using the
> w64 compiler ? I've had a couple of goes at building gmp, but configure
> won't accept anything other than ABI=32. (Not that I understand what I'm
> doing all that well, but I had figured I would want ABI=64.) No matter what
> I try, best I can do is to have configure terminate with:
>
> 
> checking if globals are prefixed by underscore... ./configure: nm: command
> not found
> unknown
> configure: WARNING:
> +--
> configure: WARNING: | Cannot determine global symbol prefix.
> configure: WARNING: | nm output doesn't contain a global data symbol.
> configure: WARNING: | Will proceed with no underscore.
> configure: WARNING: | If this is wrong then you'll get link errors referring
> configure: WARNING: | to ___gmpn_add_n (note three underscores).
> configure: WARNING: | In this case do a fresh build with an override,
> configure: WARNING: | ./configure gmp_cv_asm_underscore=yes
> configure: WARNING:
> +--
> checking how to switch to read-only data section... .data
> checking for assembler .type directive...
> checking for assembler .size directive...
> checking for assembler local label prefix... configure: WARNING: "nm"
> failure
> configure: WARNING: cannot determine local label, using default L
> L
> checking for assembler byte directive... .byte
> checking how to define a 32-bit word... ./configure: nm: command not found
> ./configure: nm: command not found
> configure: error: cannot determine how to define a 32-bit word
>
> 
>
> No problems building gmp and mpfr in the msys shell using the mingw32 port
> of gcc-3.4.5 ... it's just the w64 compiler that's being a bit
> unco-operative.
>

Did you remember to pass --build/--host to configure?

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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 builds of gmp and mpfr

[JonY]

<< Starting New Thread >>

On 8/25/2009 07:53, Sisyphus wrote:
>> You can build 2.4.x it from source, grab it at .
>
> Yes, I already have the source. I guess I could use the provided gmp
> binaries to build mpfr, but I would prefer to use a gmp I had built myself.
> Also, building my own gmp would enable me to use gmp-4.3.1.
> (In any case, I expect the issues I'm facing in trying to build gmp would
> still be a stumbling block when it comes to building mpfr.)
>
>> Did you remember to pass --build/--host to configure?
>
> No, I didn't. How do I determine the correct values for --build and --host ?
>

Hi,

Here is what the machine triplet, build, host, and target option does:

* machine triplet - The triplet key identifies a platform. Usually comes 
in the form of "cpu"-"vendor"-"system".

* build - Build machine triplet, usually corresponds with native gcc 
target (gcc -dumpmachine). In this case it is "i686-pc-mingw32".

* host - The platform in which you want the library/program you just 
compiled to run on. You need a cross compiler to this (the mingw-w64 
toolchain targeting win64 from sf is a cross compiler). Since you want 
them to run on win64, it is "x86_64-w64-mingw32".

* target - This option is usually unused. It is reserved for compilers, 
assemblers, or other code generators. It specifies the platform the code 
generator will produce code for.

The toolchain in mingw-w64-bin_i686-mingw_20090819.zip is very old, it 
uses the "pc" vendor key instead of "w64". I suggest you use one of the 
automated toolchain builds targeting win64. There has been a lot of bug 
fixes and feature enhancements since then.

If you are trying to rebuild GCC, you can place gmp and mpfr at the root 
of the GCC source tree as "gmp" and "mpfr" respectively. GCC will pass 
the correct options to it.

If you want them installed as libraries, you should pass 
"--build=i686-pc-mingw32 --host=x86_64-w64-mingw32" to configure. 
configure assumes you want a native build if those aren't specified.

The configure script from GMP is a bit different, it checks the cpu key 
to enable assembly optimizations. Due to the different ABI for Linux and 
win64, it doesn't work yet.

Pass "--host=none-none-none CC=x86_64-w64-mingw32-gcc 
CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar 
LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm 
RANLIB=x86_64-w64-mingw32-ranlib ABI=longlong" to build it without 
assembly optimization.

For MPFR, passing just the --build/--host option should work fine.

HTH


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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 builds of gmp and mpfr

[JonY]

On 8/25/2009 13:01, Sisyphus wrote:
> /bin/sh ../../libtool --mode=link x86_64-w64-mingw32-gcc -O2 -pedantic
> -o t-locale.exe t-locale.o ../../tests/libtests.la ../../libgmp.la
> x86_64-w64-mingw32-gcc -O2 -pedantic -o t-locale.exe t-locale.o
> ../../tests/.libs/libtests.a /c/_32/comp/gmp-4.3.1/.libs/libgmp.a
> ../../.libs/libgmp.a
> c:/_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a(dslcs00660.o):(.text+0x0):
> multiple definition of `localeconv'
> t-locale.o:t-locale.c:(.text+0x0): first defined here
> collect2: ld returned 1 exit status
> make[4]: *** [t-locale.exe] Error 1
> make[4]: Leaving directory `/c/_32/comp/gmp-4.3.1/tests/misc'
> make[3]: *** [check-am] Error 2
> make[3]: Leaving directory `/c/_32/comp/gmp-4.3.1/tests/misc'
> make[2]: *** [check-recursive] Error 1
> make[2]: Leaving directory `/c/_32/comp/gmp-4.3.1/tests'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory `/c/_32/comp/gmp-4.3.1'
> make: *** [check] Error 2
> 
>
> Any advice on how best to address that little niggle (or whether I can
> ignore it) appreciated.
>
> Cheers,
> Rob
>

Hi,
I got to this point too, the localeconv provided in msvcrt unfortunately 
can't be replaced easily, so this test is expected to fail. You can 
ignore it.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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 builds of gmp and mpfr

[JonY]

On 8/26/2009 09:31, Sisyphus wrote:
>
> With mpc-0.6 I get an error building the mpc_set tests (tset.o):
>
> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I../src
> -I/usr/local/include -g -O2 -MT tset.o -MD -MP -MF .deps/tset.Tpo -c -o
> tset.o tset.c
> In file included from ../src/mpc-impl.h:27:0,
> from mpc-tests.h:25,
> from tset.c:37:
> ../src/config.h:1:0: warning: "PACKAGE_STRING" redefined
> ../config.h:71:0: note: this is the location of the previous definition
> mv -f .deps/tset.Tpo .deps/tset.Po
> /bin/sh ../libtool --tag=CC --mode=link 86_64-w64-mingw32-gcc -g -O2
> -L/usr/local/lib -o tset.exe tset.o libmpc-tests.la ../src/libmpc.la
> -lmpfr -lgmp
> x86_64-w64-mingw32-gcc -g -O2 -o tset.exe tset.o -L/usr/local/lib
> ./.libs/libmpc-tests.a ../src/.libs/libmpc.a /usr/local/lib/libmpfr.a
> /usr/local/lib/libgmp.a
> tset.o: In function `check_set':
> c:\_32\comp\mpc-0.6\tests/tset.c:235: undefined reference to `mpc_set_uj'
> c:\_32\comp\mpc-0.6\tests/tset.c:240: undefined reference to `mpc_set_sj'
> c:\_32\comp\mpc-0.6\tests/tset.c:245: undefined reference to
> `mpc_set_uj_uj'
> c:\_32\comp\mpc-0.6\tests/tset.c:250: undefined reference to
> `mpc_set_sj_sj'
> c:\_32\comp\mpc-0.6\tests/tset.c:259: undefined reference to `mpc_set_sj'
> c:\_32\comp\mpc-0.6\tests/tset.c:264: undefined reference to
> `mpc_set_sj_sj'
> collect2: ld returned 1 exit status
> make[2]: *** [tset.exe] Error 1
>
> This a little more serious - those references are, indeed, not defined
> in libmpc.a. This smells to me like a bug in mpc itself. (Again, I'll
> have to take a closer look when time permits.)
>

Hi,
this looks like a real problem, I haven't encountered it before.

I'll investigate further once I get the time; or until xeno shows up on 
irc, he's been doing trying to make a win64 toolchain too. I'm sure he 
has something to say.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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 builds of gmp and mpfr

[JonY]

On 8/26/2009 21:19, sisyph...@optusnet.com.au wrote:
>
> I hacked my way past this problem as follows:
>
> In both src/set_x.c and src/set_x_x.c I changed:
>
> #if HAVE_INTTYPES_H
> to
> #if 1
>
> and I changed
>
> #ifdef _MPC_H_HAVE_INTMAX_T
> to
> #if 1
>
> Then ran 'make distclean' and started afresh. All was then fine, and all 
> tests built and passed.
>
> It seems that, somehow, HAVE_INTTYPES_H is untrue and _MPC_H_HAVE_INTMAX_T is 
> undefined at the 'make' stage, but HAVE_INTTYPES_H is true and 
> _MPC_H_HAVE_INTMAX_T is defined during the 'make check' stage.
>
> I figured (perhaps incorrectly) that this was a problem with the mpc source, 
> and posted to the mpc-discuss mailing list. My post there still awaits 
> moderator approval as the post is just over their allowable 40kb in size. (I 
> think it's the config.log which I sent as an attachment with that post that's 
> providing most of that 40kb.)
>

Hi,

The logs might show something interesting.

you can use gzip or bzip2 to compress the config.log file or post it at 
pastebin.com.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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 builds of gmp and mpfr

[JonY]

On 8/27/2009 02:44, Sisyphus wrote:
>
> Hi JonY,
>
> config.log.gz is attached.
>

Hi,
strangely, at the end of the config.log, I find at the end of config.log:
#define HAVE_INTTYPES_H 1

Maybe some file wasn't including config.h right, or erroneously using 
pthreads config.h.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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-compile fail

[JonY]

On 9/10/2009 04:18, Matthew Talbert wrote:
>> You aren't building with a separate prefix, so you are installing
>> right into your root.  This can cause issues if you have conflicting
>> versions of things installed.  You are best to install into some
>> prefix outside of your main tree until you get the hang of it.
>>
>> I suggest building everything with --prefix=/opt/w64 or something
>> similar.  Then just put /opt/w64/bin in your PATH.
>
>
> Thanks, NightStrike, this helped some. I'm following the instructions
> here: 
> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-doc/howto-build/mingw-w64-howto-build.txt?revision=1281&view=markup
>
> I believe that there is a problem with "install the mingw-w64 header
> set", on step 2. It says to do this:
> cp -r include /mypath/x86_64-w64-mingw32/
>
> Shouldn't it be this:
> mkdir /mypath/x86_64-w64-mingw32/include
> cp -r include /mypath/x86_64-w64-mingw32/include
>
> ?
>
> Without doing it the latter way, making gcc subsequently fails with
> "cannot find /mypath/mingw/include".
>
Hi,
it should really be svn export, you don't need the svn metadata.

> But now, it is still failing on building the crt, with this error:
>
>
> configure:3141: $? = 0
> configure:3148: x86_64-w64-mingw32-gcc -v>&5
> Using built-in specs.
> Target: x86_64-w64-mingw32
> Configured with: ../configure --target=x86_64-w64-mingw32
> --enable-targets=all --prefix=/opt/w64 --with-sysroot=/opt/w64
> Thread model: win32
> gcc version 4.4.1 20090505 (prerelease) (GCC)
> configure:3152: $? = 0
> configure:3159: x86_64-w64-mingw32-gcc -V>&5
> x86_64-w64-mingw32-gcc: '-V' option must have argument
> configure:3163: $? = 1
> configure:3186: x86_64-w64-mingw32-gcc -o conftestconftest.c>&5
> /tmp/ccNWc2p8.s: Assembler messages:
> /tmp/ccNWc2p8.s:2: Error: unknown pseudo-op: `.def'
> /tmp/ccNWc2p8.s:2: Error: unknown pseudo-op: `.scl'
> /tmp/ccNWc2p8.s:2: Error: unrecognized symbol type "32"
> /tmp/ccNWc2p8.s:2: Error: unknown pseudo-op: `.endef'
> /tmp/ccNWc2p8.s:5: Error: unknown pseudo-op: `.def'
> /tmp/ccNWc2p8.s:5: Error: unknown pseudo-op: `.scl'
> /tmp/ccNWc2p8.s:5: Error: unrecognized symbol type "32"
> /tmp/ccNWc2p8.s:5: Error: unknown pseudo-op: `.endef'
> configure:3190: $? = 1
> configure:3395: checking whether we are cross compiling
> configure:3397: result: yes
> configure:3401: checking for suffix of object files
> configure:3427: x86_64-w64-mingw32-gcc -c   conftest.c>&5
> /tmp/cc0D8UM7.s: Assembler messages:
> /tmp/cc0D8UM7.s:2: Error: unknown pseudo-op: `.def'
> /tmp/cc0D8UM7.s:2: Error: unknown pseudo-op: `.scl'
> /tmp/cc0D8UM7.s:2: Error: unrecognized symbol type "32"
> /tmp/cc0D8UM7.s:2: Error: unknown pseudo-op: `.endef'
> /tmp/cc0D8UM7.s:5: Error: unknown pseudo-op: `.def'
> /tmp/cc0D8UM7.s:5: Error: unknown pseudo-op: `.scl'
> /tmp/cc0D8UM7.s:5: Error: unrecognized symbol type "32"
> /tmp/cc0D8UM7.s:5: Error: unknown pseudo-op: `.endef'
> configure:3431: $? = 1
> configure: failed program was:
> | /* confdefs.h.  */
> | #define PACKAGE_NAME "mingw-w64-runtime"
> | #define PACKAGE_TARNAME "mingw-w64-runtime"
> | #define PACKAGE_VERSION "1.0b"
> | #define PACKAGE_STRING "mingw-w64-runtime 1.0b"
> | #define PACKAGE_BUGREPORT "mingw-w64-public@lists.sourceforge.net"
> | #define PACKAGE "mingw-w64-runtime"
> | #define VERSION "1.0b"
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:3445: error: in
> `/home/matthew/source/mingw64/mingw/mingw-w64-crt/build':
> configure:3448: error: cannot compute suffix of object files: cannot compile
>
> I'm sorry to be such a bother. The instructions looked simple enough,
> but I guess I'm still missing something.
>

Maybe the wrong binutils got called, check your $PATH, make sure 
/opt/w64/bin is in it.

> Thanks,
> Matthew
>
> Here's the build script as modified to use /opt/w64:
>
> #! /bin/sh
>
> target=x86_64-w64-mingw32
> prefix=/opt/w64
> top_dir=`pwd`
>
> sudo rm -rf $prefix
> sudo mkdir $prefix
> #sudo chown $USER $prefix
>
> cd binutils/src
> rm -rf build
> mkdir build
> cd build
> ../configure --target=$target \
>  --enable-targets=$target,i686-w64-mingw32 \
>  --with-sysroot=/mypath --prefix=/mypath
>
> if  make ; then
>  echo "built binutils successfully" ;
> else
>  echo "make failed on binutils"
>  exit ;
> fi
>
> sudo make install
>
> cd $top_dir/mingw/mingw-w64-headers
> # copy include directory
> sudo mkdir -p $prefix/$target/include
> sudo cp -r include $prefix/$target/include
> # gcc requires it be mirrored
> sudo ln -s $prefix/$target $prefix/mingw
> # create lib directory
> sudo mkdir $prefix/$target/lib
> sudo ln -s $prefix/$target/lib $prefix/$target/lib64
>
> # configure and build gcc
> cd $top_dir/gcc/gcc
> rm -rf build
> mkdir build
> cd build
> ../configure --target=$target --enable-targets=all --prefix=$prefix
> --with-sysroot=$prefix
> if  make all-gcc  ; then
>  echo "built gcc successfully" ;
> else
>  echo "make

Re: [Mingw-w64-public] cross-compile fail

[JonY]

On 9/10/2009 08:16, Matthew Talbert wrote:
>> Hi,
>> it should really be svn export, you don't need the svn metadata.
>
> Sorry, I don't follow you here.
>
>

Hi,

Use 'svn export include /mypath/x86_64-w64-mingw32/include'. It will 
create the missing directory and copy the headers without the svn 
metadata. The metadata is in a .svn subdirectory in each directory you 
checkout via svn.

>> Maybe the wrong binutils got called, check your $PATH, make sure
>> /opt/w64/bin is in it.
>
> Yes, /opt/w64/bin is in it. I've done this manually as well and it has
> the same problem.
>

Use 'x86_64-w64-mingw32-gcc -print-prog-name=as', to find out where its 
invoking as.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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-compile fail

[JonY]

On 9/10/2009 09:59, Matthew Talbert wrote:
>> Use 'svn export include /mypath/x86_64-w64-mingw32/include'. It will
>> create the missing directory and copy the headers without the svn
>> metadata. The metadata is in a .svn subdirectory in each directory you
>> checkout via svn.
>
> Perhaps I should have mentioned earlier, I'm compiling from the 4.4.0
> release, not from svn. Still, the directions are wrong, yes? (They
> neglect the trailing "include" directory, so you would be copying the
> contents of include to /mypath/x86_64-mingw32).
>

Hi,
I was referring to the svn checkout of the mingw-w64 headers, not gcc. 
Just export the headers directory instead of copying it.

The svn metadata shouldn't be there, accidentally updating the installed 
headers by svn without first checking for ABI change is hazardous to 
your toolchain.

>>
 Maybe the wrong binutils got called, check your $PATH, make sure
 /opt/w64/bin is in it.
>>>
>>> Yes, /opt/w64/bin is in it. I've done this manually as well and it has
>>> the same problem.
>>>
>>
>> Use 'x86_64-w64-mingw32-gcc -print-prog-name=as', to find out where its
>> invoking as.
>
>   /opt/w64/bin/x86_64-w64-mingw32-gcc -print-prog-name=as
> as
>
> I don't even have a x86_64as. Should I?
>

According to your build script, you should have cross binutils already 
installed, -print-prog-name=as is to make sure it is calling the correct 
cross binutils. Do post the output, thanks.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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-compile fail

[JonY]

On 9/10/2009 11:27, Matthew Talbert wrote:
>>>
>>> Perhaps I should have mentioned earlier, I'm compiling from the 4.4.0
>>> release, not from svn. Still, the directions are wrong, yes? (They
>>> neglect the trailing "include" directory, so you would be copying the
>>> contents of include to /mypath/x86_64-mingw32).
>>>
>>
>> Hi,
>> I was referring to the svn checkout of the mingw-w64 headers, not gcc.
>> Just export the headers directory instead of copying it.
>>
>> The svn metadata shouldn't be there, accidentally updating the installed
>> headers by svn without first checking for ABI change is hazardous to
>> your toolchain.
>
> I'm using this
> https://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Release%20for%20GCC%204.4.0/mingw-w64-src-4.4.0-1.tar.bz2/download
> which includes the mingw-w64 headers. So there is no svn metadata
> involved as far as I know.
>
> Matthew
>

Hi,
I see the problem now. GCC-4.4.0 doesn't support a multilib setup, use 
GCC from svn trunk instead.

The GCC, mingw-w64 headers and CRT have undergone huge changes since 
then, lots of bugfixes and etc, its a good advice to use svn versions 
instead of the release versions.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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-compile fail

[JonY]

On 9/10/2009 11:22, Matthew Talbert wrote:
>>>/opt/w64/bin/x86_64-w64-mingw32-gcc -print-prog-name=as
>>> as
>
>> According to your build script, you should have cross binutils already
>> installed, -print-prog-name=as is to make sure it is calling the correct
>> cross binutils. Do post the output, thanks.
>
> That was the command and the output. But here it is again:
>
> matt...@matthew-desktop:~/source/mingw64/mingw/mingw-w64-crt$
> /opt/w64/bin/x86_64-w64-mingw32-gcc -print-prog-name=as
> as
>

Sorry, I missed it because it didn't look like a prompt. Its not finding 
the correct as.

You are sure that you don't have x86_64-w64-mingw32-as or 
/opt/w64/x86_64-w64-mingw32/bin/as?

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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-compile fail

[JonY]

On 9/10/2009 12:06, Matthew Talbert wrote:
> On Wed, Sep 9, 2009 at 11:44 PM, JonY<10wa...@gmail.com>  wrote:
>> On 9/10/2009 11:22, Matthew Talbert wrote:
>>>>> /opt/w64/bin/x86_64-w64-mingw32-gcc -print-prog-name=as
>>>>> as
>>>
>>>> According to your build script, you should have cross binutils already
>>>> installed, -print-prog-name=as is to make sure it is calling the correct
>>>> cross binutils. Do post the output, thanks.
>>>
>>> That was the command and the output. But here it is again:
>>>
>>> matt...@matthew-desktop:~/source/mingw64/mingw/mingw-w64-crt$
>>> /opt/w64/bin/x86_64-w64-mingw32-gcc -print-prog-name=as
>>> as
>>>
>>
>> Sorry, I missed it because it didn't look like a prompt. Its not finding
>> the correct as.
>>
>> You are sure that you don't have x86_64-w64-mingw32-as or
>> /opt/w64/x86_64-w64-mingw32/bin/as?
>
> Yes, completely absent.
>
> But if I can't do multilib with this release, then I'll need to switch
> to svn anyway. I'm still confused about multilib. Is that the only way
> to build for win32, or can this release work for that? Basically I
> just need to build for win32 at this point, though I may need 64-bit
> support in the future.
>

Hi,
you can use i686-w64-mingw32 instead of x86_64-w64-mingw32 to target win32.

Multilib means being able to use the same compiler to produce code for 
more than one platform, in mingw-w64's case, it means win32 and win64. 
Unfortunately multilib won't work for i686-w64-mingw32 configuration, so 
won't be able to target win64 if you do use it.

In any case, you should at least have cross binutils to start building a 
cross compiler. Do use the binutils from CVS too, there have been lots 
of fixes, especially debug data striping.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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-qt4 packages, binutils fuzz.

[JonY]

On 9/14/2009 02:46, Wolfgang Glas wrote:
> Hi all,
>
>After getting our clazzes.org PPA
> (https://www.launchpad.net/~clazzes.org/+archive/ppa) seeded with many
> backported libraries, I was finally able to release a cross-compiled qt-4.5.2
> version for win32 and win64.
>
>There are a number of patches needed to get the beast compiled, all of 
> these
> may be found in our svn repository, which may be browsed under
>
>http://svn.clazzes.org/svn/mingw-pkg/trunk/mingw-w64-deb
>
>The mileage up to know is quite mixed, Qt Designer is running well, othe
> simple Qt examples are crashing by now.
>
>For earlier posting I suppose, that these crashes might be caused by bug of
> the binutils version released together with mingw-w64-src-4.4.0-1.
>

Hi,
mingw-w64 is about to release GCC 4.4.2, which contains many needed 
bugfixes.

>I was trying to find a download URL for newer binutils, but there seems to 
> be
> a great confusion about binutils version numbers. The last officially released
> binutils version is 2.19.1, redhat seems to distribute snapshot with version
> numbers like 2.19.51.
>
>So could somebody please shed more light on the scenery and recommend a
> last-know-good-for-mingw-w64 binutils source download?
>

Sourceware binutils CVS HEAD is generally stable. Version numbers like 
2.20.51 are development snapshots (the HEAD snapshots gets updated 
daily), while 2.19.1 is a released to the public version.

Using a cross build environment, you can easily install an earlier 
revision of binutils if the newer version breaks.

Of course, I wouldn't recommend using CVS HEAD in a production 
environment, but the released version contains some known bugs as well.

>Using debian packaging I may easily switch from one binutils version to
> another and compare the results and will send a report on the stability of the
> generated packages to the list.
>

Thanks.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
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-qt4 packages, binutils fuzz.

[JonY]

On 9/14/2009 20:41, Wolfgang Glas wrote:
> JonY schrieb:
>> On 9/14/2009 02:46, Wolfgang Glas wrote:
>
> [snip]
>
>>> The mileage up to know is quite mixed, Qt Designer is running well, othe
>>> simple Qt examples are crashing by now.
>>>
>>> For earlier posting I suppose, that these crashes might be caused by 
>>> bug of
>>> the binutils version released together with mingw-w64-src-4.4.0-1.
>>>
>>
>> Hi,
>> mingw-w64 is about to release GCC 4.4.2, which contains many needed
>> bugfixes.
>
> Hi,
>
> AFAIK, a gcc-4.4.2 release of mingw-w64 will take some weeks from now 
> (according
> to Kai Tietz), so I'd like to help a bit in testing the current CVS version of
> mingw-w64-headers and newer version of binutils.
>
>>> I was trying to find a download URL for newer binutils, but there seems 
>>> to be
>>> a great confusion about binutils version numbers. The last officially 
>>> released
>>> binutils version is 2.19.1, redhat seems to distribute snapshot with version
>>> numbers like 2.19.51.
>>>
>>> So could somebody please shed more light on the scenery and recommend a
>>> last-know-good-for-mingw-w64 binutils source download?
>>>
>>
>> Sourceware binutils CVS HEAD is generally stable. Version numbers like
>> 2.20.51 are development snapshots (the HEAD snapshots gets updated
>> daily), while 2.19.1 is a released to the public version.
>
> OK, I've found the following recent sourceware binutils packages:
>
> binutils-2.19.51.tar.bz2  2009/09/04 07:4218 057 370
> binutils-2.19.90.tar.bz2  2009/09/10 13:5817 415 613
> binutils-2.20.51.tar.bz2  2009/09/14 07:4118 079 354
>
> Which one should I try in order to get a maximal test coverage for gcc-4.4.2?
> Will a 2.20.x version needed for mingw-w64-4.4.2 or is 2.20 only needed for a
> shared libc++ build? Is 2.19.90 nore stable than 2.19.90 ?
>

Hi,

shared libc++?

I have only used 2.19.51, and with gcc trunk (4.5.0). I haven't 
encountered any notable issues with the recent snapshots. I'll be trying 
2.20.51 soon with multilib i686-w64-mingw32 and x86_64-w64-mingw32 
configuration.

Usually, if there are problems, the binutils devs will ask you to retry 
with CVS HEAD, so I suggest giving the 2.20.x series snapshots testing 
higher priority.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Precompiled mingw-w64-bin_i686-linux?

[JonY]

On 9/17/2009 08:52, Erik de Castro Lopo wrote:
> Hi all,
>
> I'm currently using :
>
>  mingw-w64-bin_i686-linux_20090202.tar.bz2
>
> and ran into some troubles ("%zd" in printf format strings not
> supported) and was going to grab a later version.
>
> Unfortunately I can't seem to find one on the web site. Are these
> being built?
>
> Cheers,
> Erik

Hi,

the most recent build for 32bit linux is 
"mingw-w64-bin_i686-linux_20090612.tar.bz2", but its hidden by sourceforge.

Use 

 
to find it.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Precompiled mingw-w64-bin_i686-linux?

[JonY]

On 9/17/2009 10:43, Erik de Castro Lopo wrote:
> JonY wrote:
>
>> the most recent build for 32bit linux is
>> "mingw-w64-bin_i686-linux_20090612.tar.bz2", but its hidden by sourceforge.
>
> Sourceforge is amazing efficient at hiding files :-).
>
> I just tried the file :
>
>  mingw-w64_x86-64_linux32_4.4.0-1.tar.bz2
>
> from sourceforge which was dated "Thu May 21 2009 17:12". That didn't
> fix the problem.
>
> Then tried "mingw-w64-bin_i686-linux_20090612.tar.bz2. Still no fix.
>
> Cheers,
> Erik

Hi,

I forgot to mention, you can use the __mingw_xxx functions for GNU-ish 
print formats. Take a look at stdio.h, it should be in the there.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] makebuildroot.mk

[JonY]

On 9/21/2009 06:42, Erik de Castro Lopo wrote:
> NightStrike wrote:
>
>> Add TARGET_ARCH=i686-w64-mingw32 to your make command line.
>
> Shouldn't that be i686-w32-mingw32 or maybe even i686-pc-mingw32?
>
> Erik

Hi,

"w64" is already a vendor key recognized by gcc. It will add support for 
mingw-w64 specific features.

Using "w32" is equivalent to "pc".

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] makebuildroot.mk

[JonY]

On 9/21/2009 09:48, Erik de Castro Lopo wrote:
> JonY wrote:
>
>> On 9/21/2009 06:42, Erik de Castro Lopo wrote:
>>> NightStrike wrote:
>>>
>>>> Add TARGET_ARCH=i686-w64-mingw32 to your make command line.
>>>
>>> Shouldn't that be i686-w32-mingw32 or maybe even i686-pc-mingw32?
>>
>> "w64" is already a vendor key recognized by gcc. It will add support for
>> mingw-w64 specific features.
>>
>> Using "w32" is equivalent to "pc".
>
> Sorry, either you or I are missing something :-).
>
> If I want to build a Linux ->  win64 cross compiler I can just use the
> default TARGET_ARCH set in the makebuildroot.mk script.
>
> However, if I want to build a Linux ->  win32 cross compiler I need to
> override the TARGET_ARCH setting. Nightstrike suggested:
>
>  i686-w64-mingw32
>
> and I was questioning whether the "w64" component should be replaced
> with either "pc" or "w32"?
>
> Erik

Hi,
I should explain clearer.

"w64" in the vendor key does not actually mean win64 only. It means that 
mingw-w64 headers are used instead of mingw.org equivalents. It will 
activate stuff like "-municode" in GCC.

If its not "w64", GCC will assume that mingw.org header set and libs are 
used instead of mingw-w64 provided equivalents. It will disable features 
specific to mingw-w64, so its more mingw.org compatible.

Like NightStrike suggested, you should use "w64" if you are using 
mingw-w64 provided headers. "w32" will have the same effect as using 
"pc" as vendor key.

Was it clear? Sorry for the confusion.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] asm eror msg build crt with gcc44 branch

[JonY]

On 10/10/2009 08:04, t66...@gmail.com wrote:
> t66...@gmail.com wrote:
>> t66...@gmail.com wrote:
>>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.  -m32  -pipe  -std=gnu99
>>> -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline
>>> -Wimplicit-function-declaration -Wmissing-noreturn
>>> -Wmissing-prototypes -O3 -mms-bitfields -MT
>>> profile/lib32_libgmon_a-profil.o -MD -MP -MF
>>> profile/.deps/lib32_libgmon_a-profil.Tpo -c -o
>>> profile/lib32_libgmon_a-profil.o `test -f 'profile/profil.c' || echo
>>> './'`profile/profil.c
>>> {standard input}: Assembler messages:
>>> {standard input}:8: Error: suffix or operands invalid for `push'
>>> {standard input}:46: Error: suffix or operands invalid for `pop'
>>> {standard input}:80: Error: suffix or operands invalid for `call'
>>> {standard input}:84: Error: suffix or operands invalid for `call'
>>> {standard input}:141: Error: suffix or operands invalid for `push'
>>> {standard input}:170: Error: suffix or operands invalid for `pop'
>>> {standard input}:175: Error: suffix or operands invalid for `push'
>>> {standard input}:177: Error: suffix or operands invalid for `push'
>>> {standard input}:178: Error: suffix or operands invalid for `push'
>>> {standard input}:200: Error: suffix or operands invalid for `call'
>>> {standard input}:207: Error: suffix or operands invalid for `push'
>>> {standard input}:245: Error: suffix or operands invalid for `pop'
>>> {standard input}:277: Error: suffix or operands invalid for `call'
>>> {standard input}:281: Error: suffix or operands invalid for `call'
>>> make[2]: *** [profile/lib32_libgmon_a-profil.o] Error 1
>>>
>>> Hello:
>>> the above error build with gcc-4_4-branch
>>> mingw-w64-cry
>>> I assue this is a gcc's bug?
>>>
>> oh this is with building multilib oiption if it matters
>>
> I don't understand, gcc was configured with multilib enable-targets=all,
> no error produced without m32 option this means gcc-4_4-branch does not
> support or binutils's problem?
> Anyone?
>
>

Hi,
there is a high chance that binutils wasn't configured for multilib, how 
did you configure binutils?

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] asm eror msg build crt with gcc44 branch

[JonY]

On 10/10/2009 11:53, t66...@gmail.com wrote:
> JonY wrote:
>> On 10/10/2009 09:45, t66...@gmail.com wrote:
>>> t66...@gmail.com wrote:
>>>> JonY wrote:
>>>>> On 10/10/2009 08:04, t66...@gmail.com wrote:
>>>>>> t66...@gmail.com wrote:
>>>>>>> t66...@gmail.com wrote:
>>>>>>>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -m32 -pipe -std=gnu99
>>>>>>>> -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline
>>>>>>>> -Wimplicit-function-declaration -Wmissing-noreturn
>>>>>>>> -Wmissing-prototypes -O3 -mms-bitfields -MT
>>>>>>>> profile/lib32_libgmon_a-profil.o -MD -MP -MF
>>>>>>>> profile/.deps/lib32_libgmon_a-profil.Tpo -c -o
>>>>>>>> profile/lib32_libgmon_a-profil.o `test -f 'profile/profil.c' ||
>>>>>>>> echo
>>>>>>>> './'`profile/profil.c
>>>>>>>> {standard input}: Assembler messages:
>>>>>>>> {standard input}:8: Error: suffix or operands invalid for `push'
>>>>>>>> {standard input}:46: Error: suffix or operands invalid for `pop'
>>>>>>>> {standard input}:80: Error: suffix or operands invalid for `call'
>>>>>>>> {standard input}:84: Error: suffix or operands invalid for `call'
>>>>>>>> {standard input}:141: Error: suffix or operands invalid for `push'
>>>>>>>> {standard input}:170: Error: suffix or operands invalid for `pop'
>>>>>>>> {standard input}:175: Error: suffix or operands invalid for `push'
>>>>>>>> {standard input}:177: Error: suffix or operands invalid for `push'
>>>>>>>> {standard input}:178: Error: suffix or operands invalid for `push'
>>>>>>>> {standard input}:200: Error: suffix or operands invalid for `call'
>>>>>>>> {standard input}:207: Error: suffix or operands invalid for `push'
>>>>>>>> {standard input}:245: Error: suffix or operands invalid for `pop'
>>>>>>>> {standard input}:277: Error: suffix or operands invalid for `call'
>>>>>>>> {standard input}:281: Error: suffix or operands invalid for `call'
>>>>>>>> make[2]: *** [profile/lib32_libgmon_a-profil.o] Error 1
>>>>>>>>
>>>>>>>> Hello:
>>>>>>>> the above error build with gcc-4_4-branch
>>>>>>>> mingw-w64-cry
>>>>>>>> I assue this is a gcc's bug?
>>>>>>>>
>>>>>>> oh this is with building multilib oiption if it matters
>>>>>>>
>>>>>> I don't understand, gcc was configured with multilib
>>>>>> enable-targets=all,
>>>>>> no error produced without m32 option this means gcc-4_4-branch
>>>>>> does not
>>>>>> support or binutils's problem?
>>>>>> Anyone?
>>>>>>
>>>>>>
>>>>>
>>>>> Hi,
>>>>> there is a high chance that binutils wasn't configured for multilib,
>>>>> how did you configure binutils?
>>>> It was configured with :
>>>> --enable-multilib --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32
>>>> objdump --help show this
>>>> objdump: supported targets: pe-x86-64 pei-x86-64 elf64-x86-64
>>>> elf64-l1om elf64-little elf64-big elf32-little elf32-big pe-i386
>>>> pei-i386 elf32-i386 srec symbolsrec verilog tekhex binary ihex
>>>> objdump: supported architectures: i386 i386:x86-64 i8086 i386:intel
>>>> i386:x86-64:intel l1om l1om:intel
>>>> I read "http://www.cadforte.com/wiki/index.php/How_to_build"; and
>>>> pretty much followed the instructions.
>>>> objdump on this object file which was compiled successfully
>>>> lib32_libm_a-_libm_dummy.o: file format pe-x86-64
>>>>
>>> Also ld --help output correctly showing
>>> ld: supported targets: pe-x86-64 pei-x86-64 elf64-x86-64 elf64-l1om
>>> elf64-little elf64-big elf32-little elf32-big pe-i386 pei-i386
>>> elf32-i386 srec symbolsrec verilog tekhex binary ihex
>>> ld: supported emulations: i386pep i386pe
>>>
>>> Is there something wrong with my build or gcc or mingw-w64-crt?
>>>
>>> What's the real difference between pe-x86-64 pei-x86-64?
>>>
>>
>> Hi,
>>
>> I've just built the crt a few days ago without issues. PE and PEI are
>> the executable format and object format used on Windows.
>>
>> It really looks like the assembler is not able to understand 32bit
>> asm. BTW, ld != x86_64-w64-mingw32-ld.
>>
>> What does "x86_64-w64-mingw32-ld --help|grep supported\ targets" say?
>>
> x86_64-w64-mingw32-ld: supported targets: pe-x86-64 pei-x86-64
> elf64-x86-64 elf64-l1om elf64-little elf64-big elf32-little elf32-big
> pe-i386 pei-i386 elf32-i386 srec symbolsrec verilog tekhex binary ihex
> I have the PATH so ld is the actual x86_64-w64 target's ld
>

[Adding mingw-w64-public back, my mail client dropped it]

Hi,
What does "x86_64-w64-mingw32-gcc -print-prog-name=as" say?

I suspect the wrong "as" was called.

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] asm eror msg build crt with gcc44 branch

[JonY]

On 10/10/2009 14:13, t66...@gmail.com wrote:
> JonY wrote:
>> On 10/10/2009 11:53, t66...@gmail.com wrote:
>>> JonY wrote:
>>>> On 10/10/2009 09:45, t66...@gmail.com wrote:
>>>>> t66...@gmail.com wrote:
>>>>>> JonY wrote:
>>>>>>> On 10/10/2009 08:04, t66...@gmail.com wrote:
>>>>>>>> t66...@gmail.com wrote:
>>>>>>>>> t66...@gmail.com wrote:
>>>>>>>>>> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -m32 -pipe -std=gnu99
>>>>>>>>>> -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked
>>>>>>>>>> -Winline
>>>>>>>>>> -Wimplicit-function-declaration -Wmissing-noreturn
>>>>>>>>>> -Wmissing-prototypes -O3 -mms-bitfields -MT
>>>>>>>>>> profile/lib32_libgmon_a-profil.o -MD -MP -MF
>>>>>>>>>> profile/.deps/lib32_libgmon_a-profil.Tpo -c -o
>>>>>>>>>> profile/lib32_libgmon_a-profil.o `test -f 'profile/profil.c' ||
>>>>>>>>>> echo
>>>>>>>>>> './'`profile/profil.c
>>>>>>>>>> {standard input}: Assembler messages:
>>>>>>>>>> {standard input}:8: Error: suffix or operands invalid for `push'
>>>>>>>>>> {standard input}:46: Error: suffix or operands invalid for `pop'
>>>>>>>>>> {standard input}:80: Error: suffix or operands invalid for `call'
>>>>>>>>>> {standard input}:84: Error: suffix or operands invalid for `call'
>>>>>>>>>> {standard input}:141: Error: suffix or operands invalid for
>>>>>>>>>> `push'
>>>>>>>>>> {standard input}:170: Error: suffix or operands invalid for `pop'
>>>>>>>>>> {standard input}:175: Error: suffix or operands invalid for
>>>>>>>>>> `push'
>>>>>>>>>> {standard input}:177: Error: suffix or operands invalid for
>>>>>>>>>> `push'
>>>>>>>>>> {standard input}:178: Error: suffix or operands invalid for
>>>>>>>>>> `push'
>>>>>>>>>> {standard input}:200: Error: suffix or operands invalid for
>>>>>>>>>> `call'
>>>>>>>>>> {standard input}:207: Error: suffix or operands invalid for
>>>>>>>>>> `push'
>>>>>>>>>> {standard input}:245: Error: suffix or operands invalid for `pop'
>>>>>>>>>> {standard input}:277: Error: suffix or operands invalid for
>>>>>>>>>> `call'
>>>>>>>>>> {standard input}:281: Error: suffix or operands invalid for
>>>>>>>>>> `call'
>>>>>>>>>> make[2]: *** [profile/lib32_libgmon_a-profil.o] Error 1
>>>>>>>>>>
>>>>>>>>>> Hello:
>>>>>>>>>> the above error build with gcc-4_4-branch
>>>>>>>>>> mingw-w64-cry
>>>>>>>>>> I assue this is a gcc's bug?
>>>>>>>>>>
>>>>>>>>> oh this is with building multilib oiption if it matters
>>>>>>>>>
>>>>>>>> I don't understand, gcc was configured with multilib
>>>>>>>> enable-targets=all,
>>>>>>>> no error produced without m32 option this means gcc-4_4-branch
>>>>>>>> does not
>>>>>>>> support or binutils's problem?
>>>>>>>> Anyone?
>>>>>>>>
>>>>>>>>
>>>>>>> Hi,
>>>>>>> there is a high chance that binutils wasn't configured for multilib,
>>>>>>> how did you configure binutils?
>>>>>> It was configured with :
>>>>>> --enable-multilib
>>>>>> --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32
>>>>>> objdump --help show this
>>>>>> objdump: supported targets: pe-x86-64 pei-x86-64 elf64-x86-64
>>>>>> elf64-l1om elf64-little elf64-big elf32-little elf32-big pe-i386
>>>>>> pei-i386 elf32-i386 srec symbolsrec verilog tekh

Re: [Mingw-w64-public] Missing twalk in search.h

[JonY]

On 1/7/2010 15:19, Ozkan Sezer wrote:
> On Thu, Jan 7, 2010 at 8:11 AM, t66...@gmail.com  wrote:
>> Hi
>> Due to the latest change in vlc.git
>> http://git.videolan.org/gitweb.cgi/vlc.git/?a=commitdiff;h=19adcbe5be83ce12a07d83092503c3f4a622b3b6
>> Now breaks build due to mingw-w64-headers crt search.h is missing twalk
>> I found twalk inside mingw.org's mingwrt search.h implementation.
>> Is there some reason why mingw-w64 have this missing definitions.
>>
>> regards
>
> Seems like they're just missing, that's all.
> mingw.org implements the tsearch code
> in mingwex, public domain, taken from
> netbsd. I suggest we add them too, both
> to the trunk and to the 1.0 branch.
>
> --
> Ozkan

Hi,

I'm currently working on it, seems like copy and pasting from mingw.org
could fix this, but I'm sure you can do the commit and testing faster. :)

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GDB 7.0.1

[JonY]

On 1/7/2010 23:00, Chris Sutcliffe wrote:
> I've uploaded 32- and 64-bit native builds of GDB for mingw-w64 built
> from the vanilla GNU GDB 7.0.1 sources:
>
> 32-bit: 
> http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/gdb/i686-w64-mingw32-gdb-7.0.1-4.tar.bz2/download
> 64-bit: 
> http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/gdb/x86_64-w64-mingw32-gdb-7.0.1.tar.bz2/download
>
> Please report any issues to this mailing list.
>
> Enjoy!
>
> Chris
>

Hi,

good job pushing out new releases.

By the way, are these built with expat and PDCurses?

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Should I expect to find a version of make in the mingw-w64 download?

[JonY]

On 1/12/2010 05:41, Frank R. Brown wrote:
> To All:
>
> I do not see a version of make in my mingw-w64 installation.  Am I overlooking
> something, or is this to be expected?  (I have looked for things like 
> make.exe,
> mingw-make.exe, mingw32-make.exe, etc.)
>
> I downloaded and unzipped mingw-w64-bin_i686-mingw_20091231.zip, and have
> been able to compile simple test programs.  (This is on 64-bit windows 7.)
>
> Background:  I am looking to build 64-bit versions of some third-party 
> packages
> (at the moment, qt), and this usually requires a make utility.
>
> Thanks.
>
> kf
>

Hi,

make is not part of mingw-w64.

Try mingw32-make instead from the mingw.org project, or MSYS make if
you are using MSYS.

If you are using Cygwin, it already provides its own GNU make.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Should I expect to find a version of make in the mingw-w64 download?

[JonY]

On 1/12/2010 18:55, Ozkan Sezer wrote:
>
> There actually are make binaries posted under
> "External binary packages (Win64 hosted) ->  make"
> on the downloads page. You can try downloading
> make_20091224a_bin.tar.gz for example and
> using it.

I didn't know about that. win64 hosted make should work too.

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Are win64 headers the same as win32 headers?

[JonY]

On 1/19/2010 16:51, Ozkan Sezer wrote:
> On Tue, Jan 19, 2010 at 7:42 AM, Zuxy Meng wrote:
>> Hi,
>>
>> I wonder if the win32api headers from mingw32 can be used directly in
>> mingw64.
>
> No, they cannot.
>
>> If I have already a working msys+mingw32 env installed, can I just
>> copy binutils, gcc and libraries from mingw64 to have a working native
>> compilation env?
>> --

To elaborate further, mingw-w64 comes with its own set of headers to
support win64 as a target.

If you are using it to target win32, you could reuse libs built by
mingw32, in theory. I have not tried this.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Bulding gmp-5.0.0 with MinGW64 (in MSYS shell).

[JonY]

On 1/19/2010 20:03, Sisyphus wrote:
>
> - Original Message -
> From: "Ozkan Sezer"
>
>>> Firstly, the command I'm running to build and test gmp-5.0.0 is:
>>>
>>> ./configure --disable-shared --enable-static --host=none-none-none
>>> CC="x86_64-w64-mingw32-gcc -std=gnu99" CXX=x86_64-w64-mingw32-g++
>>> AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld
>>> NM=x86_64-w64-mingw32-nm
>>> RANLIB=x86_64-w64-mingw32-ranlib ABI=longlong&&  make&&  make check -i
>>>
>>
>> I would have suggested using configure --build=x86_64-w64-mingw32
>> --target=x86_64-w64-mingw32
>
> Unfortunately that doesn't get me very far:
>
> #
> r...@desktop2 /c/_32/comp/gmp-5.0.0
> $ ./configure --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
> configure: error: --target is not appropriate for GMP
> Use --build=CPU-VENDOR-OS if you need to specify your CPU and/or system
> explicitly.  Use --host if cross-compiling (see "Installing GMP" in the
> manual for more on this).
>
> r...@desktop2 /c/_32/comp/gmp-5.0.0
>
> #
>
> Cheers,
> Rob
>

Hi,

--target is only valid for GCC/Binutils, use --build/--host instead.

The localeconv error is a known problem for win32/win64 target, you can
ignore it.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Bulding gmp-5.0.0 with MinGW64 (in MSYS shell).

[JonY]

On 1/19/2010 21:55, Ozkan Sezer wrote:
> On Tue, Jan 19, 2010 at 3:50 PM, JonY  wrote:
>> On 1/19/2010 20:03, Sisyphus wrote:
>>>
>>> - Original Message -
>>> From: "Ozkan Sezer"
>>>
>>>>> Firstly, the command I'm running to build and test gmp-5.0.0 is:
>>>>>
>>>>> ./configure --disable-shared --enable-static --host=none-none-none
>>>>> CC="x86_64-w64-mingw32-gcc -std=gnu99" CXX=x86_64-w64-mingw32-g++
>>>>> AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld
>>>>> NM=x86_64-w64-mingw32-nm
>>>>> RANLIB=x86_64-w64-mingw32-ranlib ABI=longlong&&   make&&   make check -i
>>>>>
>>>>
>>>> I would have suggested using configure --build=x86_64-w64-mingw32
>>>> --target=x86_64-w64-mingw32
>>>
>>> Unfortunately that doesn't get me very far:
>>>
>>> #
>>> r...@desktop2 /c/_32/comp/gmp-5.0.0
>>> $ ./configure --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
>>> configure: error: --target is not appropriate for GMP
>>> Use --build=CPU-VENDOR-OS if you need to specify your CPU and/or system
>>> explicitly.  Use --host if cross-compiling (see "Installing GMP" in the
>>> manual for more on this).
>>>
>>> r...@desktop2 /c/_32/comp/gmp-5.0.0
>>>
>>> #
>>>
>>> Cheers,
>>> Rob
>>>
>>
>> Hi,
>>
>> --target is only valid for GCC/Binutils, use --build/--host instead.
>
> Oops, really meant --host, not --target when I wrote that.
> I guess people can't read mind, don't they ;)
>
>>
>> The localeconv error is a known problem for win32/win64 target, you can
>> ignore it.
>>
>
> The thing is, that particular problem doesn't show up
> with mingw.org compiler (I had tested with their
> gcc-3.4.5 based toolchain in the past, don't know about
> the behavior with their newer 4.4-based compilers).
>

hi,

iiuc, it will fail on modern mingw.org too.

libmsvcrt.a now exports localeconv, but t-locale is trying to use its
own implementation, hence the multiple definition error.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Undefined reference to gai_strerror()

[JonY]

On 1/26/2010 21:50, Chris Spencer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> I'm having a bit of a problem with my networking code. Specifically, the
> linker can't find gai_strerror().
>
> To provide a very simple test case:
>
> #include
> int main() {
>  gai_strerror(0);
>  return 0;
> }
>
> This compiles without issue in mingw32, but with mingw64 it fails:
>
> $ mingw32-gcc test.c
> $ x86_64-w64-mingw32-gcc test.c
> /tmp/ccfVhfda.o:test.c:(.text+0x13): undefined reference to `_gai_strerrorA'
> collect2: ld returned 1 exit status
>
> I can't really figure out what's going on here since it's defined inline
> in the header:
>
> WS2TCPIP_INLINE char *gai_strerrorA(int ecode) { ... }
>
> Any ideas?
>
> $ x86_64-w64-mingw32-gcc --version
> x86_64-w64-mingw32-gcc (Gentoo 4.4.0_alpha20090331, pie-10.1.3)
> 4.4.0-alpha20090331 20090331 (prerelease)
>
> Cheers, Chris.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkte8zEACgkQ6iqRtkAADZgPMgCg4KZfVCawUn6gZztxsjK+43aH
> eMsAnj6sLwQx8Tg2XaaImnNeZvcBZGTk
> =T9Yj
> -END PGP SIGNATURE-
>

Hi,

you forgot to add -lws2_32, "x86_64-w64-mingw32-gcc test.c -lws2_32".


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-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] Question on scanf and modifiers...

[JonY]

On 1/30/2010 12:11, David Cleaver wrote:
> Hello again,
>
> I know it wasn't long ago that I was asking about using %llu in fscanf or
> sscanf.  However, I am wondering if anything has changed in this regard?  Does
> MingW64 support %llu in the scanf functions?
>
> Also, in the future, is there an easy way for me to find out this information 
> on
> my own?  Perhaps if someone could point out which file something like this was
> defined in, I could look at the latest version of the file to see if the 
> change
> is in there?
>
> If it affects the answers, I'm using Windows XP x64 version, and I will be 
> using
> Ozkan's build from mingw-w64-bin_x86_64-mingw_20100123_sezero.zip
>
> I'd like to use the #define __USE_MINGW_ANSI_STDIO 1 in the code.  Can I wrap
> this define inside of a check like:
> #ifdef __MINGW64__
> #define __USE_MINGW_ANSI_STDIO 1
> #endif
>
> Is that the correct ifdef I should be using, or is there a different define I
> should be looking for?
>
> -David C.
>

Hi,

There is no such macro as __MINGW64__, use __MINGW64_VERSION_MAJOR
instead, its guaranteed to be defined if you include any mingw-w64
headers.

I think __USE_MINGW_ANSI_STDIO only applies to the printf family, the
scanf family has not been ported yet, so you'll need to use %I64u
instead of %llu.

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-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] i686-w64-mingw32 and x86_64-w64-mingw32 coexisting

[JonY]

On 2/21/2010 21:35, NightStrike wrote:
> On Fri, Jan 15, 2010 at 8:32 AM, Chris Sutcliffe  wrote:
>> Hi All,
>>
>> Is it possible for i686-w64-mingw and x86_64-w64-mingw32 to coexist in
>> the same directory?  I realize the majority of the directory structure
>> is unique to the compiler, but things like libiberty.a are in the
>> 'lib' directory of both compilers and they both have a 'mingw32'
>> directory that is either a symlink or a copy of the corresponding
>> compiler directory.
>
> Is libiberty used as a host lib or a target lib?
>

Hi,

libiberty is usually built by the host compiler, used by the newly
built gcc backends. Some binutils tools use it too.

IMHO, there is little reason to install it, sourceware make install
does it anyway.


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] common compiler #defines for cross-platform/compiler code

[JonY]

On 2/22/2010 07:59, Jim Michaels wrote:
> compiler-defined #defines so you can write cross-platform code better.
> one source code, multiple targets (djgpp, 9x/me, nt-family, vista/7).
>
> I have a web page with a g++ wrapper batch file that makes vista/7-compatible 
> code by adding a manifest XML windows resource, which you supply parameters.  
> it switches out compiler(s) of your choice.  you only get to choose between a 
> 32-bit and a 64-bit target compiler.
> http://JesusnJim.com/code/mingw.html
> the batch file has built-in help, albeit lengthy, so make sure your command 
> shell has a long enough layout buffer, at least 100 lines - I usually choose 
> 9900.
>
> I have a "common compiler switches" web page.
> http://JesusnJim.com/programming/common-compiler-switches.html
> it lists the most useful of the gcc compiler switches I have discovered along 
> the way.
>
> common compiler #defines page: at 
> http://JesusnJim.com/programming/common-compiler-defines.html
>
> any additions to these pages welcome.
>
> what I don't have is the mingw switches and command-line for making DLL's.
> any contribution would only help me help someone else, and I could augment my 
> g++ wrapper batch file.
>

Hi,

Nice pages.

see  for help on GCC
command line.

More specifically the -shared option in


For compiler defines, see .

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libmangle?

[JonY]

On 3/4/2010 05:25, Erik de Castro Lopo wrote:
> HI all,
>
> I just found libmangle:
>
>  http://mingw-w64.sourceforge.net/libmangle/index.html
>
> Would this make it possible for code compiled using g++ to call
> C++ code compiled by the microsoft compiler? And vice versa?
>
> Erik

Hi,

Maybe, but exception handling still won't work.

See  for help.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Available downloads

[JonY]

On 3/8/2010 10:50, Sisyphus wrote:
>   Hi,
> At http://sourceforge.net/projects/mingw-w64/files/ I see
> mingw-w64-bin_i686-linux_20100307.tar.bz2 but no
> mingw-w64-bin_i686-mingw_20100307.zip. Are the "mingw" cross compiler builds
> no longer being made available ?
>
> Cheers,
> Rob
>

Hi,

there are some technical issues with the gcc that is installed on it,
its too old so the builds kept failing.

It should be fixed soon.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Question about the undercore in svn

[JonY]

On 3/22/2010 07:24, Doug Semler wrote:

On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:

On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler  wrote:

Yeah, I kinda decided to give up on multilib with gcc 4.5 right now.  The
target DLLs for things like libstdc++, etc are installed into the
completely wrong spot due to a -bindir parameter in the libtool portion
of the DLL makefiles. They are installed into the host's binary
directory (which makes no sense to me at all - by the way I use a
different -prefix and -exec-prefix), they cannot be overridden by the
--with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden
and which I have working multilib with a minor patch to
gcc/config/t-cygming), nor do they obey the version specific runtime
libs directory like the native toolchain does.  In addition, the
mulitlib install can clobber the dlls in that (wrong) bindir with the
wrong arch type (the 32bit install puts the 64 bit version there after
all is said and done).


Jon Y has a patch for all of that.


Given that  the trunk of GCC is in stage 4, I wouldn't expect any of this
to be fixed prior to the release even if patches were submitted since I
wouldn't expect this to be classified as a P1 issue (I don't think the
w64-mingw32 toolchain is considered to be a primary target, is it?)


Yeah, it's not getting fixed in 4.5.  And no, we aren't even a
secondary target :(


My frustration right now is that the GCC trunk has been in stage 4 since
December...aside from the fact that I would be wary personally of moving
to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for
these targets...

After saying all that, the documentation about multilib should maybe have
some caveats...


Well, to be fair, we never advertised that it even exists... so.


In both how-to-build docs, yes, you do :)

I know that there was the "the tools now track gcc" statement and "no more
need to patch gcc."   One of the problems really is going to be requiring the
use of the 4.6 trunk to get the correct behavior for installation of the
toolchain (multilib notwithstanding, I still feel the installation of the
target DLLs is also woefully incorrect, so I presume the patch mentioned above
does that as well) unless there are also plans to backport them to 4.5, which
I would doubt.   I would never use the stage 1,2, or 3 trunks to build
production code (well, maybe the stage 3 depending on the issues in it)-- they
are just too unstable --which means I'll track the 4.5 branch for quite a
while.

Don't know what I'll do...wait for the patch(es) to be applied, do the work
myself, or just deal with it (using nonmultilib, moving the files to where they
should be, and modifying the installed .la files correctly...)

OK...vent mode off :)



Hi,

here are the patches to make the dlls not clash, "v1.patch" for
libtool, "gcc_multilib.patch" for gcc. The dlls are prefixed "w32" and
"w64" respectively.

You'll need to regenerate the gcc configury, particularly for the
target support libs, after installing a patched version of libtool.

I'm still waiting for the FSF paperwork to be done.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 80a1ff3..45798fc 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4215,6 +4215,28 @@ func_mode_link ()
continue
;;
 
+  -m32)
+   archive_cmds="$archive_cmds -m32"
+   case $host in
+   *-w64-mingw*)
+   MULTILIB_PREFIX=l32
+   ;;
+   *) ;;
+   esac
+   continue
+   ;;
+
+  -m64)
+   archive_cmds="$archive_cmds -m64"
+   case $host in
+   *-w64-mingw*)
+   MULTILIB_PREFIX=l64
+   ;;
+   *) ;;
+   esac
+   continue
+   ;;
+
   -no-undefined)
allow_undefined=no
continue
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 29f1222..f6bb69a 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2084,6 +2084,7 @@ BEGIN {RS=" "; FS="/|\n";} {
 else
   sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
 fi])
+MULTILIB_PREFIX=
 library_names_spec=
 libname_spec='lib$name'
 soname_spec=
@@ -2227,6 +2228,22 @@ m4_if([$1], [],[
 mingw* | cegcc*)
   # MinGW DLLs use traditional 'lib' prefix
   soname_spec='${libname}`echo ${release} | $SED -e 
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+  case $host_vendor in
+w64)
+soname_spec='`echo ${libname} | sed -e 
's/^lib/\${MULTILIB_PREFIX}/'``echo ${release} | $SED -e 
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+case $host in
+x86_64-*)
+  MULTILIB_PREFIX=l64
+;;
+i?86-*)
+  MULTILIB_PREFIX=l32
+;;
+esac
+;;
+  *)
+soname_spec='${libname}`echo ${release} | $SED -e 
's/[[.]]/-/g'`${versuffix}${shared_ext}'
+  ;;
+  esac
   ;;
 pw32*)
   # pw32 DLLs use 'pw' prefix rather than 'lib'
@@ -2705,6 +2722,8 @@ _LT_DECL([], [libname_spec], [1], [Format of li

Re: [Mingw-w64-public] You could add R to your list

[JonY]

On 3/22/2010 16:51, Prof Brian Ripley wrote:
> Suggestion for the list at
> http://mingw-w64.sourceforge.net/
>
> name = The R Project for Statistical Computing
> url = http://www.r-project.org
>
> The next release (2.11.0, release process starting now) will have
> pre-built binaries using mingw-w64.
>
> Thanks for Kai Tietz for sustained help (this port was first attempted
> in 2007).
>
>

Thanks, the project has been added.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problem building a static gsl-1.14

[JonY]

On 3/24/2010 20:15, Sisyphus wrote:
> Hi,
>
> I've posted to gsl-bugs about this ... without success. I'm not even sure
> that it's a gsl bug - there's a thread at
> http://www.mail-archive.com/bug-libt...@gnu.org/msg00374.html where the
> error is of a very similar type. In that particular instance it turned out
> to be a libtool (ltmain.sh) bug. However, I've been unable to adapt the
> ltmain.sh patch that worked there to my particular situation.
>
> No problems with a dynamic build of gsl-1.14, btw ... it's just the static
> build that's being uncooperative.
>
> When trying to build a static gsl-1.14 library with mingw64 in the MSYS
> shell, I start with:
>
> $ ./configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
> CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++
> AR=x86_64-w64-mingw32-ar
> LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm
> RANLIB=x86_64-w64-mingw32-ranlib --disable-shared --enable-static&&  make
>
> (For the dynamic build I use the same, except that it's
> "--disable-static --enable-shared".)
> Everything is fine until we get near the end of the make process, when this
> happens:
>
> ##
> /bin/sh ./libtool --tag=CC   --mode=link
> x86_64-w64-mingw32-gcc  -g -O2 -version-info 15:0:15 -no-undefined  -o
> libgsl.la -rpath /usr/local/lib version.lo block/libgslblock.la
> blas/libgslblas.la bspline/libgslbspline.la
> [SNIP lots of other.la files]
> wavelet/libgslwavelet.la cblas/libgslcblas.la -lm
> libtool: link: (cd .libs/libgsl.lax/libgslblock.a&&  x86_64-w64-mingw32-ar x
> "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a")
> libtool: link: object name conflicts in archive:
> .libs/libgsl.lax/libgslblock.a//c/_64/comp/gsl-1.14/block/.libs/libgslblock.a
> make[2]: *** [libgsl.la] Error 1
> make[2]: Leaving directory `/c/_64/comp/gsl-1.14'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/c/_64/comp/gsl-1.14'
> make: *** [all] Error 2
> ###
>
> The 'cd .libs/libgsl.lax/libgslblock.a&&  x86_64-w64-mingw32-ar x
> "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a"' command apparently
> succeeds - the 3
> object files in libgslblock.a are to be found in the
> .libs/libgsl.lax/libgslblock.a/ folder.
>
> Does that error mean anything to anyone here ?
> Any advice on something I could try to get around it ?
>
> My "x86_64-w64-mingw32-gcc -v" is provided below my sig.
>
> Cheers,
> Rob
>
> r...@desktop2 ~
> $ x86_64-w64-mingw32-gcc -v
> Using built-in specs.
> Target: x86_64-w64-mingw32
> Configured with:
> ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 
> --prefix=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root
>   
> --with-sysroot=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root 
> --with-gmp=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install
>  
> --with-mpfr=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install
>  
> --with-mpc=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install
>  --enable-languages=all,obj-c++ --enable-fully-dynamic-string 
> --disable-multilibThread model: win32gcc version 4.4.4 20100208 
> (prerelease)(GCC)
>

Hi,

Strange, there should not be any folders below .libs.

this sounds like an MSYS issue, what happens if you used something like
"--prefix=c:/_64"?

Failing that, try building out of tree.


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Question about sys/resource.h...

[JonY]

On 3/28/2010 09:49, David Cleaver wrote:
> Hello all,
>
> I've recently come across a program that includes sys/resource.h and uses that
> for measuring the runtime of some code.  I know that Mingw64 does not have 
> this
> file, but I was wondering why?  Is it something that cannot be done on a 
> Windows
> platform?
>
> Also, I see that there is a struct called rusage inside that file that keeps
> track of user time and system time which are both timeval structs.  If I just
> use a timeval struct in Mingw64 to keep track of time, will that be keeping
> track of (user+system) time?  Or maybe just user (or just system) time?  If
> anyone knows the answer or where I can find more info, I'd really appreciate 
> it.
>
> -David C.
>

Hi,

Windows doesn't really have that, so its not included with mingw-w64,
but you can try with an untested version from:



--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Newer boehm-gc brokes the multilib-arch of libjava on win64

[JonY]

On 4/16/2010 15:06, LunarShaddow wrote:
> Thx for the help of NightStriker. Now i replaced the boehm-gc dir of the gcc 
> tree with the newer test edition
> (I noted that the problem troubling me seemed to have been resolved in 2007 
> but not been imported to gcc...)
> I compiled boehm-gc seperatedly and it works great.
> but after I merged it into the gcc tree i noted that it won't created a 
> multilib directory in "/x86_64-w64-mingw32/32",
> and the "./32/libjava" complains about a "gc_*.po" file has no target to 
> built.
> I manually copied the Makefile from the 64bit directory and added -m32 into 
> each CFLAG and CPPFLAG, but it still goes wrong,
> with a "gc_*.h" missing.
> Any way to solve? Thx
>

Hi,

Check out the Makefile.am AM_ENABLE_MULTILIB macro used by other support 
libs. It should have what you want.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Newer boehm-gc brokes the multilib-arch of libjava on win64

[JonY]

On 4/16/2010 15:06, LunarShaddow wrote:
> Thx for the help of NightStriker. Now i replaced the boehm-gc dir of the gcc 
> tree with the newer test edition
> (I noted that the problem troubling me seemed to have been resolved in 2007 
> but not been imported to gcc...)
> I compiled boehm-gc seperatedly and it works great.
> but after I merged it into the gcc tree i noted that it won't created a 
> multilib directory in "/x86_64-w64-mingw32/32",
> and the "./32/libjava" complains about a "gc_*.po" file has no target to 
> built.
> I manually copied the Makefile from the 64bit directory and added -m32 into 
> each CFLAG and CPPFLAG, but it still goes wrong,
> with a "gc_*.h" missing.
> Any way to solve? Thx
>

Hi,

Check out the Makefile.am AM_ENABLE_MULTILIB macro used by other support 
libs. It should have what you want.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] TDM-GCC binary distribution

[JonY]

On 5/4/2010 02:02, Kai Tietz wrote:
> Hello John,
>
> 2010/5/3 John E. / TDM:
>> MinGW-w64 developers,
>>
>> I'm planning to introduce a set of binary packages based on GCC for
>> x86_64-w64-mingw32 and the MinGW-w64 runtime into the TDM-GCC compiler
>> suite. More info about TDM-GCC is available at
>> , but in essence it's GCC for
>> Windows, based on MinGW (and soon MinGW-w64), with a release schedule
>> following GCC's formal releases, packaged in an NSIS installer/updater.
>
> Fine, we will enjoy this and I agree on your scheduling plan for f
>
>> I'd prefer to avoid duplicating patches and bug reports as much as
>> possible, so I plan to direct users to the MinGW-w64 trackers for these
>> purposes. Are you amenable to this? My documentation would include the
>> following language:
>>
>>> BUGS:
>>> Please do *not* report bugs in this edition of TDM-GCC to the standard
>>> MinGW
>>> (32) mailing list or forums.
>>>
>>> If you encounter any bugs with this edition of TDM-GCC, it is likely
>>> that they
>>> will be inherent to the x86_64-w64-mingw32 GCC target or to the MinGW-w64
>>> runtime API. As such, you are encouraged to report bugs to the tracker
>>> for the
>>> MinGW-w64 project on SourceForge
>>> (). Once
>>> the issue
>>> has been fixed in the mingw-w64 runtime or in GCC, file a feature
>>> request on the
>>> TDM-GCC tracker
>>> ()
>>> to update to the fixed version.
>>>
>>> SUPPORT:
>>> Support for the x86_64-w64-mingw32 GCC target, as well as for any
>>> incompatibilities in its runtime API, is provided where possible by the
>>> MinGW-w64 project. The MinGW-w64 project provides multiple venues for
>>> support
>>> including a mailing list, an IRC channel, a web-based discussion forum on
>>> SourceForge, and a web-based issue tracker on SourceForge.
>>>
>>> For more information about MinGW-w64, see the project's home page at
>>> .
>>
>> Let me know if there's anything you'd prefer I change, or any further
>> considerations.
>
> Yes, it makes in general no sense to duplicate bug-reports at many
> places. Additional any bug-fixes and new features are most welcome,
> too. Yes please direct users to our bug-tracker on SF. Please let us
> know, if your toolchains will contain specific patches, which aren't
> part of the vanilla source, as we can then provide users better
> support. Additional you can tell users to contact us for general
> question on our IRC-channel, too.
>
>

Hi John,

do mention the mingw-w64-public mailing list too.

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

Re: [Mingw-w64-public] pthreads

[JonY]

On 5/4/2010 17:08, Dmitrijs Ledkovs wrote:
> On 4 May 2010 10:03, Ozkan Sezer  wrote:
>> On Tue, May 4, 2010 at 10:53 AM, Dmitrijs Ledkovs
>>   wrote:
>>> On 4 May 2010 07:51, Ozkan Sezer  wrote:
 On Tue, May 4, 2010 at 9:44 AM, Dmitrijs Ledkovs
   wrote:
> the patch link from documentation doesn't apply from me.
>
> neither against tarball nor against cvs please help.

 Is the patch from here?
 http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/patches/pthreads_win32/

 That one applies to the CVS version of pthreads perfectly.
 Otherwise, if you are running on windows, you might have
 hit some dos line endigns issue??

>>>
>>> Ok =) let me state what I need better =)
>>>
>>> I want two more patches ontop of that one:
>>>
>>> how it looks after the sed magic has been applied to make it's
>>> GNUMakefile ready for building i686 and second one for x86_64
>>>
>>> So when I'm building for i686 i would apply that one from the link&
>>> i686_prep.patch;
>>> When building for x86_64 patch from the link above and&  x86_64_prep.patch
>>>
>>> I'm having troubles with running the makebuildroot-test.mk to create
>>> those for me.
>>>
>>
>> I don't have experience with that buildbot makefile, however I can
>> not find any reference to a i686_prep.patch or x86_64_prep.patch in
>> it, either.  If your problem is that a second sed magic (such as for
>> prep'ing it for x86_64) not working on the GNUmakefile once a first
>> one (such as for prep'ing for i686) is applied, you should always
>> work on a backup copy of the original GNUmakefile the one resulting
>> from the applying of w64sup.patch.
>>
>> My own scripts has something like:
>>
>> cvs -z9 -d:pserver:anon...@sourceware.org:/cvs/pthreads-win32 co pthreads
>> cd pthreads
>> patch -p1<  ../pthreads-w64sup.patch
>> cp -p config.h pthreads_win32_config.h
>> cp -p pthread.h pthread.h.bak
>> sed -e 's/HAVE_CONFIG_H/1/' \
>> -e 's/config.h/pthreads_win32_config.h/' \
>> <  pthread.h.bak>pthread.h
>> cp -p GNUmakefile GNUmakefile.bak
>>
>> The resulting source tree at this point is my reference.
>>
>> Then, for x86_64-w64-mingw32 I do:
>>
>> sed -e 's/dlltool$/&  -m i386:x86-64/' \
>> -e 's/gcc$/&  -m64/' \
>> -e 's/g++$/&  -m64/' \
>> -e 's/windres$/&  -F pe-x86-64/' \
>> -e 's/pthreadGC\$(DLL_VER)/&-w64/g' \
>> -e 's/pthreadGCE\$(DLL_VER)/&-w64/g' \
>> <  GNUmakefile.bak>  GNUmakefile
>> make CROSS="x86_64-w64-mingw32-" clean GC
>>
>> ... and then for i686-w64-mingw32, I do:
>>
>> sed -e 's/dlltool$/&  -m i386/' \
>> -e 's/gcc$/&  -m32/' \
>> -e 's/g++$/&  -m32/' \
>> -e 's/windres$/&  -F pe-i386/' \
>> -e 's/pthreadGC\$(DLL_VER)/&-w32/g' \
>> -e 's/pthreadGCE\$(DLL_VER)/&-w32/g' \
>> <  GNUmakefile.bak>  GNUmakefile
>> make CROSS="i686-w64-mingw32-" clean GC
>>
>> As you see, I always do the sed magic on the backup GNUmakefile.bak
>> and output a new GNUmakefile for every new target.
>>
>> Hope these help.
>>
>
> Yeap thanks.the -test makefile a bit more obsuscated and whey i tried
> to run just the mangling target it started to checkout binutils =/
>

Hi,

I wrote the -test makefile, its designed to build everything from 
binutils to the crt to gcc. Ozkan's script is quite similar to the one 
in the -test makefile.

Are you trying to build only pthreads?

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

Re: [Mingw-w64-public] Adding perl to Projects successfully using MinGW-w64

[JonY]

On 5/4/2010 19:01, Dmitrijs Ledkovs wrote:
> 2010/5/4 kmx:
>> Hi,
>>
>> could you please add the following 2 items to the list of Projects
>> successfully using MinGW-w64
>>
>> 1/ "perl (5.12.0 and later)" with link to http://www.perl.org/
>>
>> 2/ "strawberry perl (contains bundled mingw-w64 gcc toolchain)" with link to
>> http://strawberryperl.com/
>>
>> Thanks
>>
>
> If you are ok with svn you can checkout
> https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/web and send
> the patch with how you want this to tool like =)
>

No need to do that, I've already added them, but I forgot to notify. 
Thanks for using mingw-w64!

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

Re: [Mingw-w64-public] pthreads

[JonY]

On 5/4/2010 18:58, Dmitrijs Ledkovs wrote:
> On 4 May 2010 10:40, JonY  wrote:
>> On 5/4/2010 17:08, Dmitrijs Ledkovs wrote:
>>>
>>> On 4 May 2010 10:03, Ozkan Sezerwrote:
>>>>
>>>> On Tue, May 4, 2010 at 10:53 AM, Dmitrijs Ledkovs
>>>> wrote:
>>>>>
>>>>> On 4 May 2010 07:51, Ozkan Sezerwrote:
>>>>>>
>>>>>> On Tue, May 4, 2010 at 9:44 AM, Dmitrijs Ledkovs
>>>>>> wrote:
>>>>>>>
>>>>>>> the patch link from documentation doesn't apply from me.
>>>>>>>
>>>>>>> neither against tarball nor against cvs please help.
>>>>>>
>>>>>> Is the patch from here?
>>>>>>
>>>>>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/patches/pthreads_win32/
>>>>>>
>>>>>> That one applies to the CVS version of pthreads perfectly.
>>>>>> Otherwise, if you are running on windows, you might have
>>>>>> hit some dos line endigns issue??
>>>>>>
>>>>>
>>>>> Ok =) let me state what I need better =)
>>>>>
>>>>> I want two more patches ontop of that one:
>>>>>
>>>>> how it looks after the sed magic has been applied to make it's
>>>>> GNUMakefile ready for building i686 and second one for x86_64
>>>>>
>>>>> So when I'm building for i686 i would apply that one from the link&
>>>>> i686_prep.patch;
>>>>> When building for x86_64 patch from the link above and&
>>>>>   x86_64_prep.patch
>>>>>
>>>>> I'm having troubles with running the makebuildroot-test.mk to create
>>>>> those for me.
>>>>>
>>>>
>>>> I don't have experience with that buildbot makefile, however I can
>>>> not find any reference to a i686_prep.patch or x86_64_prep.patch in
>>>> it, either.  If your problem is that a second sed magic (such as for
>>>> prep'ing it for x86_64) not working on the GNUmakefile once a first
>>>> one (such as for prep'ing for i686) is applied, you should always
>>>> work on a backup copy of the original GNUmakefile the one resulting
>>>> from the applying of w64sup.patch.
>>>>
>>>> My own scripts has something like:
>>>>
>>>> cvs -z9 -d:pserver:anon...@sourceware.org:/cvs/pthreads-win32 co pthreads
>>>> cd pthreads
>>>> patch -p1<../pthreads-w64sup.patch
>>>> cp -p config.h pthreads_win32_config.h
>>>> cp -p pthread.h pthread.h.bak
>>>> sed -e 's/HAVE_CONFIG_H/1/' \
>>>> -e 's/config.h/pthreads_win32_config.h/' \
>>>> <pthread.h.bak>pthread.h
>>>> cp -p GNUmakefile GNUmakefile.bak
>>>>
>>>> The resulting source tree at this point is my reference.
>>>>
>>>> Then, for x86_64-w64-mingw32 I do:
>>>>
>>>> sed -e 's/dlltool$/&-m i386:x86-64/' \
>>>> -e 's/gcc$/&-m64/' \
>>>> -e 's/g++$/&-m64/' \
>>>> -e 's/windres$/&-F pe-x86-64/' \
>>>> -e 's/pthreadGC\$(DLL_VER)/&-w64/g' \
>>>> -e 's/pthreadGCE\$(DLL_VER)/&-w64/g' \
>>>> <GNUmakefile.bak>GNUmakefile
>>>> make CROSS="x86_64-w64-mingw32-" clean GC
>>>>
>>>> ... and then for i686-w64-mingw32, I do:
>>>>
>>>> sed -e 's/dlltool$/&-m i386/' \
>>>> -e 's/gcc$/&-m32/' \
>>>> -e 's/g++$/&-m32/' \
>>>> -e 's/windres$/&-F pe-i386/' \
>>>> -e 's/pthreadGC\$(DLL_VER)/&-w32/g' \
>>>> -e 's/pthreadGCE\$(DLL_VER)/&-w32/g' \
>>>> <GNUmakefile.bak>GNUmakefile
>>>> make CROSS="i686-w64-mingw32-" clean GC
>>>>
>>>> As you see, I always do the sed magic on the backup GNUmakefile.bak
>>>> and output a new GNUmakefile for every new target.
>>>>
>>>> Hope these help.
>>>>
>>>
>>> Yeap thanks.the -test makefile a bit more obsuscated and whey i tried
>>> to run just the mangling target 

Re: [Mingw-w64-public] pthreads

[JonY]

On 5/4/2010 21:24, Dmitrijs Ledkovs wrote:
> On 4 May 2010 12:57, JonY  wrote:
>> On 5/4/2010 18:58, Dmitrijs Ledkovs wrote:
>>>
>>> On 4 May 2010 10:40, JonYwrote:
>>>>
>>>> On 5/4/2010 17:08, Dmitrijs Ledkovs wrote:
>>>>>
>>>>> On 4 May 2010 10:03, Ozkan Sezer  wrote:
>>>>>>
>>>>>> On Tue, May 4, 2010 at 10:53 AM, Dmitrijs Ledkovs
>>>>>>   wrote:
>>>>>>>
>>>>>>> On 4 May 2010 07:51, Ozkan Sezer  wrote:
>>>>>>>>
>>>>>>>> On Tue, May 4, 2010 at 9:44 AM, Dmitrijs Ledkovs
>>>>>>>>   wrote:
>>>>>>>>>
>>>>>>>>> the patch link from documentation doesn't apply from me.
>>>>>>>>>
>>>>>>>>> neither against tarball nor against cvs please help.
>>>>>>>>
>>>>>>>> Is the patch from here?
>>>>>>>>
>>>>>>>>
>>>>>>>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/patches/pthreads_win32/
>>>>>>>>
>>>>>>>> That one applies to the CVS version of pthreads perfectly.
>>>>>>>> Otherwise, if you are running on windows, you might have
>>>>>>>> hit some dos line endigns issue??
>>>>>>>>
>>>>>>>
>>>>>>> Ok =) let me state what I need better =)
>>>>>>>
>>>>>>> I want two more patches ontop of that one:
>>>>>>>
>>>>>>> how it looks after the sed magic has been applied to make it's
>>>>>>> GNUMakefile ready for building i686 and second one for x86_64
>>>>>>>
>>>>>>> So when I'm building for i686 i would apply that one from the link&
>>>>>>> i686_prep.patch;
>>>>>>> When building for x86_64 patch from the link above and&
>>>>>>>   x86_64_prep.patch
>>>>>>>
>>>>>>> I'm having troubles with running the makebuildroot-test.mk to create
>>>>>>> those for me.
>>>>>>>
>>>>>>
>>>>>> I don't have experience with that buildbot makefile, however I can
>>>>>> not find any reference to a i686_prep.patch or x86_64_prep.patch in
>>>>>> it, either.  If your problem is that a second sed magic (such as for
>>>>>> prep'ing it for x86_64) not working on the GNUmakefile once a first
>>>>>> one (such as for prep'ing for i686) is applied, you should always
>>>>>> work on a backup copy of the original GNUmakefile the one resulting
>>>>>> from the applying of w64sup.patch.
>>>>>>
>>>>>> My own scripts has something like:
>>>>>>
>>>>>> cvs -z9 -d:pserver:anon...@sourceware.org:/cvs/pthreads-win32 co
>>>>>> pthreads
>>>>>> cd pthreads
>>>>>> patch -p1<  ../pthreads-w64sup.patch
>>>>>> cp -p config.h pthreads_win32_config.h
>>>>>> cp -p pthread.h pthread.h.bak
>>>>>> sed -e 's/HAVE_CONFIG_H/1/' \
>>>>>> -e 's/config.h/pthreads_win32_config.h/' \
>>>>>> <  pthread.h.bak>pthread.h
>>>>>> cp -p GNUmakefile GNUmakefile.bak
>>>>>>
>>>>>> The resulting source tree at this point is my reference.
>>>>>>
>>>>>> Then, for x86_64-w64-mingw32 I do:
>>>>>>
>>>>>> sed -e 's/dlltool$/&  -m i386:x86-64/' \
>>>>>> -e 's/gcc$/&  -m64/' \
>>>>>> -e 's/g++$/&  -m64/' \
>>>>>> -e 's/windres$/&  -F pe-x86-64/' \
>>>>>> -e 's/pthreadGC\$(DLL_VER)/&-w64/g' \
>>>>>> -e 's/pthreadGCE\$(DLL_VER)/&-w64/g' \
>>>>>> <  GNUmakefile.bak>  GNUmakefile
>>>>>> make CROSS="x86_64-w64-mingw32-" clean GC
>>>>>>
>>>>>> ... and then for i686-w64-mingw32, I do:
>>>>>>
>>>>>> sed -e 's/dlltool$/&  -m i386/' \
>>>>>> -e 's/gcc$/&  -m32/' \
>>>>>> -e 's/g++$/&  -m32/' \
>>>>>> -e 's/windres$/&  -F pe-i386/' \
>>>>>> -e 's/pthreadGC\$(DLL_VER)/&-w32/g' \
>>>>>> -e 's/pthreadGCE\$(DLL_VER)/&-w32/g' \
>>>>>> <  GNUmakefile.bak>  GNUmakefile
>>>>>> make CROSS="i686-w64-mingw32-" clean GC
>>>>>>
>>>>>> As you see, I always do the sed magic on the backup GNUmakefile.bak
>>>>>> and output a new GNUmakefile for every new target.
>>>>>>
>>>>>> Hope these help.
>>>>>>
>>>>>
>>>>> Yeap thanks.the -test makefile a bit more obsuscated and whey i tried
>>>>> to run just the mangling target it started to checkout binutils =/
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> I wrote the -test makefile, its designed to build everything from
>>>> binutils
>>>> to the crt to gcc. Ozkan's script is quite similar to the one in the
>>>> -test
>>>> makefile.
>>>>
>>
>> I mean the pthread build script. Actually, I'm still not understanding what
>> you wanted with the -test makefile, isn't it supposed to pull binutils too?
>>
>
> I'm using it as a reference when i get stuck with debian specific challenges.
>

I see, its better to read 
"trunk/mingw-w64-doc/howto-build/mingw-w64-howto-build-adv.txt" for 
instructions. The test makefile incorporates most if not all of the 
instructions mentioned.

The text is less obfuscated and should explain what all the configure 
options are for.

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

Re: [Mingw-w64-public] libgcc_s_sjsj-1.dll

[JonY]

On 5/6/2010 08:12, Jarrod Chesney wrote:
>> pavel wrote:
>>
>>> On Tue, 2010-05-04 at 13:26 +0200, pavel wrote:

 why the latest release links the programs with the
 "libgcc_s_sjsj-1.dll"? Is it possible to avoid that?
>>>
>>> I have figured this out already.
>>
>> Just for the record, how do you avoid this?
>
> You use --enable-static-libgcc or similar when linking.
> Also to note : With out this you will have issues when exceptions are thrown 
> across DLL boundaries.

You mean -static-libgcc command for gcc.

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

Re: [Mingw-w64-public] I'm probably building pthreads wrong....

[JonY]

On 5/13/2010 08:11, Dmitrijs Ledkovs wrote:
> In gcc configure I have:
>
> --enable-libmudflap
>
> And then the build fails at $ make all stage (the last make
> invocation) with this:
>
> checking for stdint.h... (cached) yes
> checking pthread.h usability... yes
> checking pthread.h presence... yes
> checking for pthread.h... yes
> checking for thread model used by GCC... win32
> win32 is an unsupported thread package
> make[2]: *** [configure-target-libmudflap] Error 1
> make[2]: Leaving directory
> `/home/dmitrij/src/mingw-w64/superv32/build_dir/i686-w64-mingw32/gcc'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> `/home/dmitrij/src/mingw-w64/superv32/build_dir/i686-w64-mingw32/gcc'
> dh_auto_build: make -j1 returned exit code 2
>
> I've modified the patch to make it is easier for me to build (based on
> target I set all the correct variables&  added install target)
> With my patch applied i do:
>
> PATH=$(CURDIR)/root/usr/bin:$PATH make -C pthreads
> target=i686-w64-mingw32 prefix=$(CURDIR)/root/usr clean GC-inlined
> install
>
> $(CURDIR)/root is my sysroot used for the whole build.
>
> What's wrong? there is nothing interesting in the config.log.
>
> Please help to get me on the pthread bandwagon =)
>

No, this has nothing to do with win32, likely how mudflap works to 
prevent stack smashing.

--

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

Re: [Mingw-w64-public] suggestion

[JonY]

On 5/15/2010 11:34, Jim Michaels wrote:
> one easy thing you could include with the compiler is a batch file which sets 
> the environment variables for the compiler.  put it in the bin directory for 
> consistency.
>
> the variables that need to be set (I think) at least, are
> OBJC_INCLUDE_PATH
> C_INCLUDE_PATH
> INCLUDE_PATH
> CPATH
> CPLUS_INCLUDE_PATH
> LIBRARY_PATH
> COMPILER_PATH
>
>

Hi,

can you please explain why it is needed?

Furthermore these variables do not work on cross compilers as I 
remember. Maybe somebody can correct me on that.


--

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

Re: [Mingw-w64-public] 4 compiler issues

[JonY]

On 5/15/2010 12:12, Jim Michaels wrote:
> 1.
> I have noticed that for sezero and auto compilers, there averages
> 7-8 LONG directories for lib path totalling 284-328 characters
> 5 LONG directories for include path totalling 274-310 characters
> 1-2
> directories for bin path.
>
> I suggest at least a .cmd batch file to set the paths and environment 
> variables.
> .cmd files are not subject to the 127 character command.com .bat command-line 
> limitation.
>
> http://jesusnjim.com/pc-repair/limitations.html
>

Well, not much we can do about that, its the GCC install convention. You 
could also use cmd.exe instead of command.com.

> 2.
> problem:
> the include and lib
> paths change with every release.
>
> wanted:
> merged include
> directory, merged lib directory, so that it is simpler to use the
> compiler, as simple as using %mingw64basepath%/include/ and
> %mingw64basepath%/lib/.
>
> or build into the compiler the include and lib directories.
>

What do you mean by "merged" and "paths change with every release"?

> 3.
> strangely enough, on the i686 x64
> compiler, g++.exe or any of the short-named tools in the
> C:\mingw-w64-bin_i686-mingw_20100428_sezero\mingw64\x86_64-w64-mingw32\bin
> directory does not execute without error.  only the long-named
> tools like
> x86_64-w64-mingw32-windres.exe in the
> C:\mingw-w64-bin_i686-mingw_20100428_sezero\mingw64\bin
> directory execute.
>
> as a result, the toolset is not
> consistent with executable names across i686 32, i686 64, x86_64,
> meaning, g++.exe on one side and x86_64-w64-mingw32-g++.exe on the
> other.  should all be g++.exe (short names).
>

As I have said, you are not supposed to use "g++", use the fully 
qualified name. Cross compilers are installed that way on purpose.

In cross GCC, the "short" name versions are never to be used directly by 
users, even when its tempting. They're there to support the compiler and 
used internally.

> 4.
> a BASH shell
> and MSYS-like tools is needed. preferably without using the curses
> library.  can't build any unix sources or most source trees without them 
> (ugh!  it's the dreaded ./configure wall) (actually you can't build any unix 
> sources *with* them either, so I guess this is a moot point).  No, I don't 
> have UNIX, and I would prefer not to install it - high
> maintenance OS.
>

Use MSYS provided by mingw.org, they have already done all the work to 
set it up. Just edit and set your PATHs appropriately after install.

You do not need a different version of MSYS for mingw-w64.

Use Cygwin if you want more UNIX-ish tools.

--

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

Re: [Mingw-w64-public] Underscore problem with mpfr configure

[JonY]

On 5/17/2010 18:23, t66...@gmail.com wrote:
> Hello,
> I'm using gcc-4.5 branch multi-lib cross compiler
> And today I tries to compile GDB 7.1
> gdb x86_64-w64 target build successfully
>
> Trying to build mpfr host = i686-w64 or i686-pc
>
>> checking for __gmpz_init in -lgmp... no
>> configure: error: libgmp not found or uses a different ABI.
>> Please read the INSTALL file -- see "In case of problem".
>
> Does anybody encounter this problem ?
>

Hi,

do you have gmp installed? If so, post the mpfr config.log file.

Gcc multilib install hasn't been fixed in svn afaik.


--

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

Re: [Mingw-w64-public] link error when building openexr ilmbase library...

[JonY]

On 5/31/2010 03:42, Hradec wrote:
> Hi there...
>
> before anything I would like to thank you all by the amazing mingw64... In
> my opnion, the best mingw ever... really neat, simple and clean... well
> done!!
>
> I'm working on cross-compile openexr and ilmbase on a mac. I got the latest
> darwin binary package, mingw32.4.6.0_20100528, 32 bits to start with. I'm
> having this missing references that I can't figure why they are coming up,
> when linking ilmbase libHalf.lib. I "greped" all mingw libraries for the
> missing references, and apparently libmingw32.a have it and its already
> included, so I'm not sure whats going on...
>
> Is there any other library that I should also include in the link to account
> for those?
>
> the list of libraries that have those references are:
> Binary file ../compilers/darwin.mingw32.4.6.0_20100528/mingw/lib/crt1.o
> matches
> Binary file ../compilers/darwin.mingw32.4.6.0_20100528/mingw/lib/crt1u.o
> matches
> Binary file ../compilers/darwin.mingw32.4.6.0_20100528/mingw/lib/crt2.o
> matches
> Binary file ../compilers/darwin.mingw32.4.6.0_20100528/mingw/lib/crt2u.o
> matches
> Binary file
> ../compilers/darwin.mingw32.4.6.0_20100528/mingw/lib/libkernel32.a matches
> Binary file
> ../compilers/darwin.mingw32.4.6.0_20100528/mingw/lib/libmingw32.a matches
> Binary file
> ../compilers/darwin.mingw32.4.6.0_20100528/mingw/lib/libmingwex.a matches
> Binary file ../compilers/darwin.mingw32.4.6.0_20100528/mingw/lib/libws2_32.a
> matches
>
> only mingw32 in included in the link command line... also, none of the
> crt1/2 object files are being used... only crtend.o, which doesn't have
> those references...
>
> any insights would be greatly appreciate!!
>
> thanks in advance!
>
> -H
>
> output log:
> 
> 
> 
> 
> i686-w64-mingw32-g++
> -I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/include/
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/lib/
> -I./src/include -DWINAPI=__stdcall -D__MINGW32__ -D_WIN32 -DMINGW
> -DHAVE_STRUCT_TIMESPEC
> -I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/dist/mingw/include/zlib-1.2.3
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/dist/mingw/lib/zlib-1.2.3
> -shared -nostdlib
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/crtbegin.o
> .libs/half.o  -Wl,--rpath
> -Wl,/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/
> -Wl,--rpath
> -Wl,/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/lib/
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/dist/mingw/lib/zlib-1.2.3
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib//libstdc++.dll.a
> -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname
> -lmingwex -lmsvcrt
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/crtend.o
> -Wl,-soname -Wl,libHalf.so.6 -o .libs/libHalf.so.6.0.0
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-tlssup.o):
> In function `__dyn_tls_i...@12':
> /Users/jchesney/mingw-w64-buildslave/darwin-x86-x86/build/build/mingw/obj/../../../build/mingw/mingw-w64-crt/crt/tlssup.c:102:
> undefined reference to `__imp__loadlibra...@4'

Re: [Mingw-w64-public] link error when building openexr ilmbase library...

[JonY]

On 5/31/2010 16:11, Hradec wrote:
> thanks for the idea... just tried and now I got multiple definitions:
>
> i686-w64-mingw32-g++
> -I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/include/
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/lib/
> -I./src/include -DWINAPI=__stdcall -D__MINGW32__ -D_WIN32 -DMINGW
> -DHAVE_STRUCT_TIMESPEC
> -I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/dist/mingw/include/zlib-1.2.3
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/dist/mingw/lib/zlib-1.2.3
> -shared
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/crtbegin.o
> .libs/half.o  -Wl,--rpath
> -Wl,/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/
> -Wl,--rpath
> -Wl,/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/lib/
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/dist/mingw/lib/zlib-1.2.3
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib//libstdc++.dll.a
> -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname
> -lmingwex -lmsvcrt
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/crtend.o
> -Wl,-soname -Wl,libHalf.so.6 -o .libs/libHalf.so.6.0.0
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o:
> In function `_crt_i...@12':
> /Users/jchesney/mingw-w64-buildslave/darwin-x86-x86/build/build/mingw/obj/../../../build/mingw/mingw-w64-crt/crt/crtdll.c:76:
> multiple definition of `__crt_i...@12'
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o:/Users/jchesney/mingw-w64-buildslave/darwin-x86-x86/build/build/mingw/obj/../../../build/mingw/mingw-w64-crt/crt/crtdll.c:76:
> first defined here
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o:
> In function `dllmaincrtstar...@12':
> /Users/jchesney/mingw-w64-buildslave/darwin-x86-x86/build/build/mingw/obj/../../../build/mingw/mingw-w64-crt/crt/crtdll.c:159:
> multiple definition of `_dllmaincrtstar...@12'
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o:/Users/jchesney/mingw-w64-buildslave/darwin-x86-x86/build/build/mingw/obj/../../../build/mingw/mingw-w64-crt/crt/crtdll.c:159:
> first defined here
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o:crtdll.c:(.CRT$XIAA+0x0):
> multiple definition of `_pcinit'
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o:crtdll.c:(.CRT$XIAA+0x0):
> first defined here
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/crtbegin.o:cygming-crtbegin.c:(.text+0x0):
> multiple definition of `___gcc_register_frame'
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100528/bin/../lib/gcc/i686-w64-mingw32/4.6.0/crtbegin.o:cygming-crtbegin.c:(.text+0x0):
> first defined here
> 

Re: [Mingw-w64-public] link error when building openexr ilmbase library...

[JonY]

On 6/1/2010 09:57, Hradec wrote:
> cool... I'll try that!
>
>   a question... the ilmbase configure script if figuring all that out by
> itself... I'm wondering if there's a default mechanism that a configure
> script can use to query gcc in order to obtain those options... if so, is
> there a way to change the default options using an environment variable to
> remove booth .o and -nostdlib options? this way I can avoid patching the
> standard configure script...
>
> -H
>
>

Hi,

this is libtool being stubborn, if you are good with shell scripts, you 
can look into the libtool file for clues, if not, you could just grep 
for the strings in libtool to remove them.

--

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

Re: [Mingw-w64-public] link error when building openexr ilmbase library...

[JonY]

On 6/1/2010 10:30, Hradec wrote:
> yeah... I already find it... the problem is that libtool is being generated
> after the configure script, and my automatic build system runs before
> configure, so I would have to patch configure in order to get it to output
> libtool already patched... (kinda confusing)...
>
> That's why I was wondering if there was a way to get configure to get the
> right parameters from outside instead of patching it...
>
> I'll try removing the objects manually and see if that fixes the link...
> hopefully it will fix it all! :)
>
> thanks for the great help !!! really appreciate! :)
>
> -H
>

Hi,

instead of editing configure, edit libtool instead. It is generated at 
the directory you ran configure in.

--

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

Re: [Mingw-w64-public] link error when building openexr ilmbase library...

[JonY]

On 6/2/2010 06:28, Hradec wrote:
> Works!! I got it linking correctly... I actually found the libtool template
> code inside configure, so it was pretty simple to delete it from there and
> now I got a proper configure patch which generates a patched libtool.
>
> Although it links correctly now, I'm not getting any DLLs out of it... just
> .la and .a and it should be dumping the DLLs as weel... could it be because
> I took the objects out? or it is missing some command line that instructs it
> to generate dlls?
>
> I tried to build openexr (ilmbase is a dependency for openexr) with the .la
> and .a libs, but openexr build complains about not finding references
> again... I know from past experience with mingw that I was only able to
> build openexr if I used the DLLs intead of the .la files, or else I would
> get those same missing references... that's why I need to get the DLLs out
> of ilmbase!
>
> -H
>

Hi,

can you post the error or warning message from libtool? If it says 
something to the effect of "undefined symbol reference not supported on 
this platform", you need to add "-no-undefined" parameter when calling 
libtool.

--

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

Re: [Mingw-w64-public] link error when building openexr ilmbase library...

[JonY]

On 6/2/2010 10:08, Hradec wrote:
> i686-w64-mingw32-g++
> -I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/include/
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/lib/
> -I./src/include -DWINAPI=__stdcall -D__MINGW32__ -D_WIN32 -DMINGW
> -DHAVE_STRUCT_TIMESPEC
> -I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/dist/mingw/include/zlib-1.2.3
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/dist/mingw/lib/zlib-1.2.3
> -g -O2
> -I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/include/OpenEXR
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib
> -L/usr/local/lib -lImath -lHalf -lIex -lIlmThread  b44ExpLogTable.cpp   -o
> b44ExpLogTable

Hi,

move the -l* libraries to the back, after the cpp file.

This is a not a gcc bug, the manual says dependencies are scanned left 
to right.

--

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

Re: [Mingw-w64-public] Installing MSYS to use mingw-w64

[JonY]

On 6/10/2010 01:41, Chris Saunders wrote:
> I think that I installed MSYS correctly for my Windows 7 64-bit system.  I
> downloaded and attempted to run configure on GMP-5.0.1 and got some output
> that made me think I have a problem:
>
> $ ./configure --disable-shared --enable-alloca=no
> checking build system type... i686-pc-mingw32
> checking host system type... i686-pc-mingw32
>
> In the post-install part I set the location to the directory where I
> extracted the 64-bit version of MinGW(on my computer it is C:\MinGW_64).
> What made me wonder is that I am seeing "i686-pc-mingw32" and think that I
> should be seeing 64 at the end of this.  I'm wondering if I likely did
> something wrong or should I expect to see this?
>

you forgot to set --build and --host, msys usually means mingw.org gcc, 
which you are not trying to use.

you need to set host to x86_64-w64-mingw32. Build can stay i686-pc-mingw32.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Dwarf-2 debugging support?

[JonY]

On 6/11/2010 23:07, Aaron Giles wrote:
> Hi there,
>
> Our project (MAME) recently converted a bunch of C code to C++, and as a 
> result our symbol size has bloated tremendously (EXE is now 280MB(!) with 
> symbols, versus 40MB without), killing our link times. Our cohorts on the 
> Linux side have not noticed any significant difference. After some 
> investigation, it looks like the difference is due to stabs versus DWARF 
> debugging information.
>
> We are using the sezero builds. I tried forcing mingw-w32 to output DWARF-2 
> (via -gdwarf-2; also tried -ggdb) but the binary size ends up almost 
> identical. I strongly suspect that the compiler was not built with support 
> for generating DWARF symbols and is just ignoring my pleas.
>
> I know the DWARF EH model is not supported, but from what I understand, the 
> support for DWARF debugging information is independent of the EH model.
>
> So basically:
>
> 1. Can you confirm/deny the existence of DWARF debugging support in current 
> sezero builds?
>
> 2. Are there other builds of the 4.4.x tree we can use that have this enabled?
>
> 3. Or alternately, Ozkan, can we convince you to turn this on for your 
> builds? :)
>
> Thanks,
> Aaron
>

Hi,

you are confusing dwarf-2 debug and EH, they are different animals. DW-2 
debug is already in use with -gdwarf-2, but DW2 EH on win64 don't work 
at all.

There have been work on SEH but its not in GCC yet.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Blog post regarding my experience using the mingw-w64 toolchain

[JonY]

On 6/12/2010 14:19, Michael Adams wrote:
> I heartily thank the developers for putting together this project: it
> allowed me to port several pieces of software to 64-bit that I regularly
> use.
>
> http://unquietwiki.blogspot.com/2010/06/evening-spent-cranking-out-windows-x64.html
>

Hi,

To clear up some confusion:

> * Make a copy of "mingw32-make.exe" as "make.exe" for easier compiling.

You shouldn't do this as make.exe is for msys make. msys make can 
understand UNIX paths that are used with autotools based packages. For 
make command under plain cmd, use mingw32-make instead.

This is a deliberate decision by the msys/mingw.org developers.

> * The x64 toolchain uses filenames prefixed with "x86_64-w64-mingw32-": 
> lengthy, but it keeps them distinct from the 32-bit toolchain and you can 
> quickly change commands in Makefiles to reflect its usage.

Prefixed filenames are used because they are really setup as cross 
compilers, but from Window's point of view, they behave similarly.

> * I did learn that it may be useful to copy other 64-bit .lib files as .la or 
> .a files to the x64 toolchain's lib folder

true, the folder layout differs from traditional mingw.org layout, so 
installing libs will be more involved.

Hope that helped.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Installing MSYS to use mingw-w64

[JonY]

On 6/15/2010 03:28, Andreas Fabri wrote:
>
> Hello,
>
> I try to install mingw-64, msys, and gmp 5.0.1
>
> I follow the explanation gven by Ruben Van Boxem  in the mailing list (I removed the prefix of the .exe files though)
>
> https://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTilI0Pv5dbWeckloeDyjbOwSUJBEGYwpCwQbpIRq%40mail.gmail.com&forum_name=mingw-w64-public
>
>
> and I get stuck with an error message. Any help is welcome.
>
> Best regards,
>
> Andreas Fabri
>
>
> $ ./configure --enable-shared --disable-static --enable-alloca=no
> --host=x86_64
> -w64-mingw32
> configure: WARNING: If you wanted to set the --build type, don't use
> --host.
> If a cross compiler is detected then cross compile mode will be used.
> checking build system type... core2-pc-mingw32
>
> .
> .
> .
> checking for assembler global directive attribute...
> checking if globals are prefixed by underscore... link: invalid option -- d
> Try `link --help' for more information.
> unknown
> configure: WARNING:
> +--
> configure: WARNING: | Cannot determine global symbol prefix.
> configure: WARNING: | link -dump -symbols output doesn't contain a
> global data s
> ymbol.
> configure: WARNING: | Will proceed with no underscore.
> configure: WARNING: | If this is wrong then you'll get link errors
> referring
> configure: WARNING: | to ___gmpn_add_n (note three underscores).
> configure: WARNING: | In this case do a fresh build with an override,
> configure: WARNING: | ./configure gmp_cv_asm_underscore=yes
> configure: WARNING:
> +--
> checking how to switch to read-only data section... .data
> checking for assembler .type directive...
> checking for assembler .size directive...
> checking for assembler local label prefix... configure: WARNING: "link
> -dump -sy
> mbols" failure
> configure: WARNING: cannot determine local label, using default L
> L
> checking for assembler byte directive... .byte
> checking how to define a 32-bit word... link: invalid option -- d
> Try `link --help' for more information.
> link: invalid option -- d
> Try `link --help' for more information.
> configure: error: cannot determine how to define a 32-bit word
>
>

Hi,

The linker is ld, not link. Do check out what link is and what it does. 
I suspect it is from coreutils.

gmp configure is a bit strange, since you are cross compiling, suggest 
you set "CC=x86_64-w64-mingw32-gcc LD=x86_64-w64-mingw32-ld 
AR=x86_64-w64-mingw32-ar ABI=64 --build=core2-pc-mingw32 
--host=core2-pc-mingw32".

Example: configure CC=c86_64-w64-mingw32-gcc LD= --disable-static

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Update of MSYS package

[JonY]

On 6/15/2010 18:47, Ruben Van Boxem wrote:
> I have updated the MSYS package to provide an out-of-the-box solution for
> problems with MSYS's link.exe and configure scripts. Should you still need
> it, you can download the MSYS coreutils package from the mingw sourceforge
> site under MSYS->coreutils.
>
> You don't have to explicitely redownload, as only one file has been removed,
> namely msys/bin/link.exe. If you have it, please remove it yourself if you
> experience problems with a configure script and "link" is mentioned as the
> cause.
>

Hi,

No, coreutils is not at fault, do not remove link.exe. It is due to 
configure not finding the correct "ld" linker.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Installing MSYS to use mingw-w64

[JonY]

On 6/15/2010 18:01, Ruben Van Boxem wrote:
> 2010/6/15 Ruben Van Boxem
>
>> 2010/6/14 Andreas Fabri
>>
>>
>>> Hello,
>>>
>>> I try to install mingw-64, msys, and gmp 5.0.1
>>>
>>> I follow the explanation gven by Ruben Van Boxem>> in the mailing list  (I removed the prefix of the .exe files though)
>>>
>>>
>>> https://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTilI0Pv5dbWeckloeDyjbOwSUJBEGYwpCwQbpIRq%40mail.gmail.com&forum_name=mingw-w64-public
>>>
>>> and I get stuck with an error message.  Any help is welcome.
>>>
>>> Best regards,
>>>
>>> Andreas Fabri
>>>
>>>
>>> $ ./configure --enable-shared --disable-static --enable-alloca=no
>>> --host=x86_64
>>>
>>> -w64-mingw32
>>> configure: WARNING: If you wanted to set the --build type, don't use
>>> --host.
>>>  If a cross compiler is detected then cross compile mode will be used.
>>> checking build system type... core2-pc-mingw32
>>>
>>
>> First, to get people reading this list to use our wiki page:
>> http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS
>> It mentions the solution I describe below for your problem.
>>
>> Some oddities:
>> --
>>   - build system type should always be reported as i686-pc-mingw32, but I'm
>> assuming this is a typo.

No, not a typo, its GMP configure trying to be smart.

>>   - It might be necessary to keep a copy of the prefixed toolchain (the
>> x86_64-w64-mingw32-gcc.exe and so forth), especially when using MSYS because
>> you are *essentially* crosscompiling. If you hate renaming everything and
>> don't *need* GCC 4.5, use sezero's toolchains, they are "MSYS-ready" so to
>> speak (contain both prefixed and unprefixed copies).
>>   - I tried configuring GMP and am also having trouble. It seems configure
>> is not pleased with ld or gcc/g++ as a linker (should be reported imho,
>> link.exe is a coreutils app, not part of any toolchain).
>>

I didn't have such issues cross compiling GMP in Cygwin or Linux.

>> A solution:
>> 
>> I just built GMP successfully:
>> configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
>> --enable-shared --disable-static --enable-alloca=no
>> make
>> make check
>> make install
>>
>> The "target" is not necessary for most other builds, but apparantly GMP
>> requires it.
>>

Don't you mean --build?

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Installing MSYS to use mingw-w64

[JonY]

On 6/15/2010 19:31, Ruben Van Boxem wrote:
>> I didn't have such issues cross compiling GMP in Cygwin or Linux.
>
>
> Well, MSYS is special :s (see other thread on my link.exe removal).
>

MSYS is not special at all to configure scripts. How does your PATH 
look? I am very puzzled how this can happen.

>
>> Don't you mean --build?
>>
>
> Yeah, pretty sure I mean --target (although --host should be equal to target
> if the latter is unspecified).
> http://www.linuxquestions.org/questions/slackware-14/explaining-build-host-target-509739/
>
> This tells me --target is useless for anything but gcc itself, and build
> should always be i686-pc-mingw32, which it is:
>

Usually it won't look at the prefixed toolchains at all.

iirc by setting --build==--host, configure will look for the prefixed 
toolchain first, and the unprefixed version after. In either case, it 
will assume it is not cross compiling.

If you can actually execute win64 apps, you can use this to your 
advantage for prefixed toolchains.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Installing MSYS to use mingw-w64

[JonY]

On 6/15/2010 20:30, Ruben Van Boxem wrote:
> 2010/6/15 JonY
>
>> On 6/15/2010 19:31, Ruben Van Boxem wrote:
>>
>>> I didn't have such issues cross compiling GMP in Cygwin or Linux.
>>>>
>>>
>>>
>>> Well, MSYS is special :s (see other thread on my link.exe removal).
>>>
>>>
>> MSYS is not special at all to configure scripts. How does your PATH look? I
>> am very puzzled how this can happen.
>>
>
> I know this, I meant the precautions and gotcha's MSYS sometimes has, like
> the link.exe issue we are having here.
> My PATH from within MSYS is this:
> .:/usr/local/bin:/mingw/bin:/bin:/c/Program Files (x86)/MiKTeX
> 2.8/miktex/bin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/Program
> Files/MATLAB/R2010a/runtime/win64:/c/Program
> Files/MATLAB/R2010a/bin:/c/Program Files (x86)/MKVtoolnix
>
> I'm guessing /usr/local/bin is /bin, and mingw/bin is set by the postinstall
> script to wherever you have a mingw compiler installed
>

Hmm, I think /mingw/bin or where your mingw-w64 toolchain bindir is 
should always be before MSYS's bindir, and that "." will certainly cause 
trouble with GCC's build system.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Installing MSYS to use mingw-w64

[JonY]

On 6/15/2010 21:49, Ruben Van Boxem wrote:
>> Hmm, I think /mingw/bin or where your mingw-w64 toolchain bindir is should
>> always be before MSYS's bindir, and that "." will certainly cause trouble
>> with GCC's build system.
>>
>
> That's exactly why I said MSYS is special... and I don't know what will
> break if I try to fix it. I still find it very odd that GMP configure even
> knows about the name "link", because no mingw toolchain even has such a
> thing. Shouldn't the script use ld or something else for its tests?
>

IIRC MSYS post installs sets mingw/bin before MSYS bins, not after, and 
there was never a "." in my MSYS, never a good idea on anything 
resembling UNIX.

Are you sure its a vanilla install?

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Installing MSYS to use mingw-w64

[JonY]

On 6/16/2010 01:37, Ruben Van Boxem wrote:
> 2010/6/15 JonY
>
>> On 6/15/2010 21:49, Ruben Van Boxem wrote:
>>
>>> Hmm, I think /mingw/bin or where your mingw-w64 toolchain bindir is should
>>>> always be before MSYS's bindir, and that "." will certainly cause trouble
>>>> with GCC's build system.
>>>>
>>>>
>>> That's exactly why I said MSYS is special... and I don't know what will
>>> break if I try to fix it. I still find it very odd that GMP configure even
>>> knows about the name "link", because no mingw toolchain even has such a
>>> thing. Shouldn't the script use ld or something else for its tests?
>>>
>>>
>> IIRC MSYS post installs sets mingw/bin before MSYS bins, not after, and
>> there was never a "." in my MSYS, never a good idea on anything resembling
>> UNIX.
>>
>> Are you sure its a vanilla install?
>>
>
> I downloaded all MSYS packages, extracted them to the same dir, and
> double-clicked msys.bat. Then I did "sh /postinstall/pi.sh" and "y" "y"
> "m:/development/mingw64". It was pleased to not find "make" and said
> everything was set up.
>
> But: path *order* is okay, /usr/local/bin points to /local/bin and is empty
> (until you put something in there yourself), then /mingw/bin, then /bin, so
> mingw/bin is before MSYS bin. The "." comes from the /etc/profile file,
> which explicitely prepends this to the rest of the path on line 19/21. I
> just noticed Earnie's justification:
> # My decision to add a . to the PATH and as the first item in the path list
> # is to mimick the Win32 method of finding executables.
>
> This still has nothing to do with the configure script even looking for a
> "link" command IMHO.
>

OK, but I still cannot understand how it can fail.

That "." in PATH is a recipe for failure especially if you want to build 
GCC.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Installing MSYS to use mingw-w64

[JonY]

On 6/16/2010 18:51, Ruben Van Boxem wrote:
>
>> Either way, without more of the config log it's difficult to tell why
>> it's trying to use a half-msvc toolchain.
>>
>
> I have attached stderr and stdout logs for
> configure --host=x86_64-w64-mingw32 --disable-shared --enable-alloca=no
>

the config.log file would give more info.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Strange auto-import issue with libstdc++

[JonY]

On 7/1/2010 10:21, Paarvai Naai wrote:
> As I have mentioned in some recent emails, I am building my mingw-w64
> toolchain using upstream binutils-2.20.1, gcc 4.5.0, and
> mingw-w64-v1.0-20100604 snapshot.  The host is i386-linux and the
> target is x86_64-w64-mingw32 with multilib support.
>
> I am running into a strange auto-import issue when compiling for C++:
>
> ] /usr/local/gcc/x86_64-windows-gcc/bin/x86_64-windows-g++ -o
> hello.exe hello.cxx
> Info: resolving std::cout  by linking to __imp___ZSt4cout (auto-import)
> /usr/local/gcc/x86_64-windows-gcc/lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/bin/ld:
> warning: auto-importing has been activated without
> --enable-auto-import specified on the command line.
> This should work unless it involves constant data structures
> referencing symbols from auto-imported DLLs.
>
> But the libstdc++ library should already be a proper import library:
> /usr/local/gcc/x86_64-windows-gcc/x86_64-w64-mingw32/lib64/libstdc++.dll.a
>
> The test program is again simple:
> --
> #include
> #include
> using namespace std;
>
> int main (int argc, char *argv[])
> {
>  printf("hello world!\n");
>  cout<<  "bye world!\n";
>  return 0;
> }
> --
>
> I'd prefer not to turn on auto-importing with the --enable-auto-import
> option as it will mask auto-importing in other libraries.  Does anyone
> have any idea why this is happening or how to fix it?
>
> Paarvai

Hi,

its not due to having libstdc++.dll.a around. Its a warning saying that 
gcc and the linker wasn't expecting an import library to be used. The 
libstdc++-v3 headers don't have the dllimport statements.

ktietz has since patched ld to properly do auto-imports with the 
--enable-runtime-pseudo-reloc-v2 changes becoming default. In short you 
can ignore this warning.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems using -municode with mingw-w64 target

[JonY]

On 7/1/2010 10:16, Paarvai Naai wrote:
> Hi again,
>
> Sorry for the multiple emails on this, but I forgot to mention the following:
>
> I am using upstream binutils-2.20.1, gcc 4.5.0, and
> mingw-w64-v1.0-20100604 snapshot.
>
> Also, the g++ compilation works if I use "main" instead of "wmain" and
> do not pass -municode.
>
> Paarvai
>

Hi,

try using -c to compile to a .o file and run nm on it. I'm curios to see 
whats in there.

Do also compare the .o file produced by gcc and g++.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems using -municode with mingw-w64 target

[JonY]

On 7/1/2010 11:36, Paarvai Naai wrote:
> Hi Jon,
>
> Ah, it looks like a name mangling problem.
>
> /usr/local/gcc/x86_64-windows-gcc/bin/x86_64-windows-nm hello.gcc.o
>  b .bss
>  d .data
>  r .rdata
>  t .text
>  T _wmain
>   U _wprintf
>
> /usr/local/gcc/x86_64-windows-gcc/bin/x86_64-windows-nm hello.g++.o
>  b .bss
>  d .data
>  r .rdata
>  t .text
>  T __Z5wmainiPPw
>   U _wprintf
>
> Including  doesn't help the name mangling either, but I can
> do a workaround by defining wmain with the extern "C" qualifier.
>
> However, note that I don't have to do that for a non-unicode program's
> main function.  Is this something that should be fixed through some
> mingw-w64 header file?
>
> Paarvai
>


GCC probably recognizes main() so it doesn't mangle it.

Adding extern "C" is fine, I usually see it accompanying 
WinMain/wWinMain and wmain in C++ code, just to be explicit.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Jonathan break build on r2963 due to typo in Makefile.am

[JonY]

On 7/27/2010 15:20, Dongsheng Song wrote:
> Hi Jonathan,
>
> Here is the patch:
>
> Index: Makefile.in
> ===
> --- Makefile.in(revision 2968)
> +++ Makefile.in(working copy)
> @@ -3697,7 +3697,7 @@
>   @LIB64_TRUE@  lib64/libks.a lib64/librpcdiag.a
> lib64/librpchttp.a lib64/libresutil.a lib64/libslwga.a \
>   @LIB64_TRUE@  lib64/libslc.alib64/libslcext.a
> lib64/libvsstrace.alib64/libmsctfmonitor.a lib64/libtbs.a  \
>   @LIB64_TRUE@  lib64/libtdh.alib64/libtxfw32.a
> lib64/libwlanui.a  lib64/libwlanapi.a lib64/libwlanutil.a  \
> -...@lib64_true@  lib64/libwer.alib64/libndis.a
> lib64/libd2d1.alib64/libwdscsl.deflib64/libpcwum.def   \
> +...@lib64_true@  lib64/libwer.alib64/libndis.a
> lib64/libd2d1.alib64/libwdscsl.a  lib64/libpcwum.a \
>   @LIB64_TRUE@  lib64/libwdscore.alib64/libcryptsp.a
> lib64/libwdsclient.a   lib64/libwdsupgcompl.a lib64/libwdsclientapi.a  \
>   @LIB64_TRUE@  lib64/libwdsutil.alib64/libmsvcr90.a
> lib64/libmsvcr100.alib64/libmsvcr90d.alib64/libwdsimage.a
>
> Index: Makefile.am
> ===
> --- Makefile.am(revision 2968)
> +++ Makefile.am(working copy)
> @@ -969,7 +969,7 @@
> lib64/libks.a lib64/librpcdiag.alib64/librpchttp.a
> lib64/libresutil.a lib64/libslwga.a \
> lib64/libslc.alib64/libslcext.a lib64/libvsstrace.a
> lib64/libmsctfmonitor.a lib64/libtbs.a  \
> lib64/libtdh.alib64/libtxfw32.a lib64/libwlanui.a
> lib64/libwlanapi.a lib64/libwlanutil.a  \
> -  lib64/libwer.alib64/libndis.a   lib64/libd2d1.a
> lib64/libwdscsl.deflib64/libpcwum.def   \
> +  lib64/libwer.alib64/libndis.a   lib64/libd2d1.a
> lib64/libwdscsl.a  lib64/libpcwum.a \
> lib64/libwdscore.alib64/libcryptsp.alib64/libwdsclient.a
> lib64/libwdsupgcompl.a lib64/libwdsclientapi.a  \
> lib64/libwdsutil.alib64/libmsvcr90.alib64/libmsvcr100.a
> lib64/libmsvcr90d.alib64/libwdsimage.a
>
>

Hi,

Thanks for spotting them.

Btw, your client wraps long lines, making the patch hard to read.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Change from 4.4.4 to 4.6.0

[JonY]

On 7/27/2010 21:30, Sisyphus wrote:
> Hi,
>
> I have binaries for gcc-4.4.4 20100208 and gcc-4.6.0 20100414
> (cross-compilers).
> The former builds libssh2-1.2.6 fine (in msys shell), but the latter
> doesn't.
>
> The errors produced by 4.6.0 (during the 'make' stage) are attached in
> m.txt.
>
> Any ideas on how this change of behaviour from one compiler to the other
> has come about ?
>
> The first error is:
> libssh2_priv.h: In function 'writev':
> libssh2_priv.h:121:24: error: 'LPWSABUF' undeclared (first use in this
> function)
> libssh2_priv.h:121:24: note: each undeclared identifier is reported only
> once for each function it appears in
>
> I can get rid of that error by #include'ing winsock2.h near the
> beginning of libssh2_priv.h (immediately after windows.h has been
> #include'd) ... but that doesn't help with the subsequent "redefinition"
> and "conflicting types" errors.
>
> Cheers,
> Rob
>

Hi,

you're supposed to include winsock2.h before windows.h, as windows.h by 
default includes the incompatible and older winsock.h.

Plenty of software packages make this mistake. You'll need to fix up 
this assumptions.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

[JonY]

On 7/28/2010 07:13, Luis Lavena wrote:
> Hello,
>
> At this time I'm using TDM64 provided 4.5.0 binaries, but before
> (using the 32-to-64 compiler) found the same issue.
>
> Using the standard config.guess (and sub) both 32bits and 64bits are
> identified as "i686-pc-mingw32"
>
> I heard that before mingw64 gained it's own identification, but using
> the files from config.git:
>
> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
>
> Still showed i686-pc-mingw32
>
> Should I be using a customized config.guess? What I would like to do
> is properly detect it (natively) or patch some libraries that include
> config.guess files.
>
> Thank you for your time and looking forward suggestions.

Hi,

just use --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 and you 
should be fine.

MSYS has been strongly associated with mingw.org for a very long time, 
hence to autotools, MSYS uname string can be assumed to be i686-pc-mingw32.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

[JonY]

On 7/28/2010 20:32, Dongsheng Song wrote:
> 于 2010-7-28 16:02, Kai Tietz 写道:
>> 2010/7/28 Dongsheng Song:
>>> 于 2010-7-28 15:43, Kai Tietz 写道:
 2010/7/28 Dongsheng Song:
> Hi Kai,
>
> When we cross build gcc 4.5 for windows, I found we can build windows gcc 
> binary one
> week ago, but now the build failed.
>
> After I do a binary search, I found the issue caused by r2945.
>
> r2950 | 2010-07-24 05:50:28 | FAILED
> r2945 | 2010-07-24 02:44:15 | FAILED
> r2944 | 2010-07-24 02:38:30 | SUCCESS
> r2939 | 2010-07-23 17:55:30 | SUCCESS
> r2928 | 2010-07-23 05:21:20 | SUCCESS
> r2924 | 2010-07-22 18:32:25 | SUCCESS
>
> r2945 remove some *IMPORTANT* macros from 
> /trunk/mingw-w64-headers/crt/float.h,
> e.g. FLT/DBL/LDBL_MANT_DIG, FLT_EVAL_METHOD, *ALL* decimal macros 
> (DEC32/64/128_*, ...)
>
> When I add FLT/DBL/LDBL_MANT_DIG and FLT_EVAL_METHOD back to 
> /trunk/mingw-w64-headers/crt/float.h,
> then the gcc cross build success again.
>
> So I recommend you apply the attached patch at least.
>
> btw, I know FLT_EVAL_METHOD added by C99, but libgfortran/m4/nearest.m4 
> use it,
> is it mean we should use ISO C99 compiler to build gcc 4.5 or later, not 
> ISO C90 as
> http://gcc.gnu.org/install/prerequisites.html ?
>
> Regards,
> Dongsheng

 Hello Dongsheng,

 the recent change to float.h was necessary to support the new
 include_next patch of 4.6. So how are you exactly installing headers?
 As usual you should just see gcc's internal float.h for older gcc's
 then 4.6. So I am a bit puzzled. Are you removing gcc's float.h here?

 Regards,
 Kai

>>>
>>> Hi Kai,
>>>
>>> I use Debian 6.0 i686 with latest update, gcc 4.4.4 build a gcc 4.5 cross 
>>> compiler for windows,
>>> then use the cross compiler to build a native gcc 4.5 compiler for windows.
>>>
>>> Without the patch, both i686-windows and x64-windows failed during build 
>>> native
>>> compiler.
>>>
>>> It's strange since I can build cross compiler, it maybe a gcc bug.
>>>
>>> The related packages is:
>>> gcc 4.5 branch, mingw64 trunk, binutils trunk, gmp 5.0 branch, mpfr 3.0 
>>> branch,
>>> mpc 0.8.2, ppl 0.10.2, cloog-ppl 0.15.9.
>>>
>>> Regards,
>>> Dongsheng
>>>
>>>
>>
>> Well, yes it is a gcc bug in respect to native/cross toolchains. I
>> assume that your search path installs headers (and libraries) in
>> standard_include for native. This cause that the system-headers get
>> included before fixed-include and gcc-include.
>> For this I can provide a patch. See revision 2986. But indeed this
>> include-order of gcc is a conceptional flaw.
>>
>> Cheers,
>> Kai
>>
>
> This build error fixed now, thank your excellent work !
>
> Thank you very much !
>
> But new error occurred when I use cross compiler to build native compiler:
>
> ...
> i686-w64-mingw32-gcc  -O2 -pipe -DIN_GCC   -W -Wall -Wwrite-strings 
> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overlength-strings -Wold-style-definition -Wc++-compat
> -DHAVE_CONFIG_H -s -o f951.exe \
>   fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o 
> fortran/cpp.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o
> fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o 
> fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchexp.o
> fortran/misc.o fortran/module.o fortran/openmp.o fortran/options.o 
> fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o
> fortran/simplify.o fortran/st.o fortran/symbol.o fortran/target-memory.o  
> fortran/convert.o fortran/dependency.o fortran/f95-lang.o
> fortran/trans.o fortran/trans-array.o fortran/trans-common.o 
> fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o
> fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o 
> fortran/trans-stmt.o fortran/trans-types.o main.o  libbackend.a
> ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   
> ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  attribs.o
> -L/home/oracle/gcc-4.5-w32_i686-linux/lib -lcloog 
> -L/home/oracle/gcc-4.5-w32_i686-linux/lib -lppl_c -lppl -lgmpxx 
> -L/home/oracle/gcc-4.5-w32/lib
> -L/home/oracle/gcc-4.5-w32/lib -L/home/oracle/gcc-4.5-w32/lib -lmpc -lmpfr 
> -lgmp   -L../zlib -lz
> /home/oracle/gcc-4.5-w32_i686-linux/lib/libppl_c.a(ppl_c_implementation_common.o):
>  In function `__tcf_0':
>
> ...
>
> /home/oracle/gcc-4.5-w32/lib/libgmpxx.a(isfuns.o):isfuns.cc:(.text+0x2be): 
> undefined reference to `std::ios_base::Init::Init()'
> collect2: ld returned 1 exit status
> make[2]: *** [cc1plus-dummy.exe] Error 1
> rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod gfortran.pod
> make[2]: Leaving directory `/home/oracle/tmp/gcc-4.5-w32-obj/gcc/gcc'
> make[1]: *** [all-gcc] Error 2
> make[1]: 

Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

[JonY]

On 7/30/2010 05:59, Luis Lavena wrote:
> On Thu, Jul 29, 2010 at 4:57 PM, Earnie  wrote:
>> NightStrike wrote:
>>> On Thu, Jul 29, 2010 at 3:20 PM, Earnie
>>> wrote:
>>>
 NightStrike wrote:

>On a long term scale, it'd be nice to compile msys natively for
>win64. That's a long way off, though.
>
>
 I have no way to even begin to try it.  First though one would need to
 bootstrap GCC 64 bits with the MSYS runtime while at the same time
 bootstrapping MSYS runtime into 64 bits.

>>> I thought the first step was porting newlib.  Doesn't msys still use that?
>>>
>> Yes, it uses newlib and a mix of Windows API calls.  But newlib may
>> actually be the easier part to convert.
>>
>
> Earnie: where specifically is uname source code? I can take a look to
> Windows API and since I have a x64 OS can check different results and
> let you know.
>
> If I can add proper identification of x86_64 (based from the OS it is
> running) will make me feel better for making you guys waste all this
> time answering this thread.
>

Hi,

I think its a bad idea to jump to conclusions based on OS running. What 
if I wanted to run plain mingw.org GCC on win64?

IMHO, setting MSYSTEM would be a better approach.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Jonathan break build on r2963 due to typo in Makefile.am

[JonY]

On 7/29/2010 23:39, NightStrike wrote:
> On Tue, Jul 27, 2010 at 5:01 AM, JonY  wrote:
>> On 7/27/2010 15:20, Dongsheng Song wrote:
>>> Hi Jonathan,
>>>
>>> Here is the patch:
>>>
>>> Index: Makefile.in
>>> ===
>>> --- Makefile.in(revision 2968)
>>> +++ Makefile.in(working copy)
>>> @@ -3697,7 +3697,7 @@
>>>@LIB64_TRUE@  lib64/libks.a lib64/librpcdiag.a
>>> lib64/librpchttp.a lib64/libresutil.a lib64/libslwga.a \
>>>@LIB64_TRUE@  lib64/libslc.alib64/libslcext.a
>>> lib64/libvsstrace.alib64/libmsctfmonitor.a lib64/libtbs.a  \
>>>@LIB64_TRUE@  lib64/libtdh.alib64/libtxfw32.a
>>> lib64/libwlanui.a  lib64/libwlanapi.a lib64/libwlanutil.a  \
>>> -...@lib64_true@  lib64/libwer.alib64/libndis.a
>>> lib64/libd2d1.alib64/libwdscsl.deflib64/libpcwum.def   \
>>> +...@lib64_true@  lib64/libwer.alib64/libndis.a
>>> lib64/libd2d1.alib64/libwdscsl.a  lib64/libpcwum.a \
>>>@LIB64_TRUE@  lib64/libwdscore.alib64/libcryptsp.a
>>> lib64/libwdsclient.a   lib64/libwdsupgcompl.a lib64/libwdsclientapi.a  \
>>>@LIB64_TRUE@  lib64/libwdsutil.alib64/libmsvcr90.a
>>> lib64/libmsvcr100.alib64/libmsvcr90d.alib64/libwdsimage.a
>>>
>>> Index: Makefile.am
>>> ===
>>> --- Makefile.am(revision 2968)
>>> +++ Makefile.am(working copy)
>>> @@ -969,7 +969,7 @@
>>>  lib64/libks.a lib64/librpcdiag.alib64/librpchttp.a
>>> lib64/libresutil.a lib64/libslwga.a \
>>>  lib64/libslc.alib64/libslcext.a lib64/libvsstrace.a
>>> lib64/libmsctfmonitor.a lib64/libtbs.a  \
>>>  lib64/libtdh.alib64/libtxfw32.a lib64/libwlanui.a
>>> lib64/libwlanapi.a lib64/libwlanutil.a  \
>>> -  lib64/libwer.alib64/libndis.a   lib64/libd2d1.a
>>> lib64/libwdscsl.deflib64/libpcwum.def   \
>>> +  lib64/libwer.alib64/libndis.a   lib64/libd2d1.a
>>> lib64/libwdscsl.a  lib64/libpcwum.a \
>>>  lib64/libwdscore.alib64/libcryptsp.alib64/libwdsclient.a
>>> lib64/libwdsupgcompl.a lib64/libwdsclientapi.a  \
>>>  lib64/libwdsutil.alib64/libmsvcr90.alib64/libmsvcr100.a
>>> lib64/libmsvcr90d.alib64/libwdsimage.a
>>>
>>>
>>
>> Hi,
>>
>> Thanks for spotting them.
>>
>> Btw, your client wraps long lines, making the patch hard to read.
>>
>> --
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
> Came through fine on gmail
>

Hi,

there is an HTML blob at the end of the message body, but I configured 
my mail client to be text only.

gmail should display HTML messages fine.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?

[JonY]

On 7/30/2010 08:57, Luis Lavena wrote:
> On Thu, Jul 29, 2010 at 9:33 PM, JonY  wrote:
>> On 7/30/2010 05:59, Luis Lavena wrote:
>>>
>>> Earnie: where specifically is uname source code? I can take a look to
>>> Windows API and since I have a x64 OS can check different results and
>>> let you know.
>>>
>>> If I can add proper identification of x86_64 (based from the OS it is
>>> running) will make me feel better for making you guys waste all this
>>> time answering this thread.
>>>
>>
>> Hi,
>>
>> I think its a bad idea to jump to conclusions based on OS running.
>
> I think get it identified is way better than 'unknown'
>

IMHO, status quo is preferable than changing a "feature" that some 
software might depend on.

>> What if I
>> wanted to run plain mingw.org GCC on win64?
>>
>> IMHO, setting MSYSTEM would be a better approach.
>
> You mean force compilation to something that is not the native one?
> --host will still be available.
>

No, I mean gcc.exe is a 32bit target gcc, from a mingw.org release. As 
far as the toolchain is concerned, running in WOW is native enough.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

[JonY]

On 7/30/2010 09:50, Dongsheng Song wrote:
> On Wed, Jul 28, 2010 at 21:42, JonY  wrote:
>> On 7/28/2010 20:32, Dongsheng Song wrote:
>>>
>>> 于 2010-7-28 16:02, Kai Tietz 写道:
>>>>
>>>> 2010/7/28 Dongsheng Song:
>>>>>
>>>>> 于 2010-7-28 15:43, Kai Tietz 写道:
>>>>>>
>>>>>> 2010/7/28 Dongsheng Song:
>>>>>>>
>>>>>>> Hi Kai,
>>>>>>>
>>>>>>> When we cross build gcc 4.5 for windows, I found we can build windows
>>>>>>> gcc binary one
>>>>>>> week ago, but now the build failed.
>>>>>>>
>>>>>>> After I do a binary search, I found the issue caused by r2945.
>>>>>>>
>>>>>>> r2950 | 2010-07-24 05:50:28 | FAILED
>>>>>>> r2945 | 2010-07-24 02:44:15 | FAILED
>>>>>>> r2944 | 2010-07-24 02:38:30 | SUCCESS
>>>>>>> r2939 | 2010-07-23 17:55:30 | SUCCESS
>>>>>>> r2928 | 2010-07-23 05:21:20 | SUCCESS
>>>>>>> r2924 | 2010-07-22 18:32:25 | SUCCESS
>>>>>>>
>>>>>>> r2945 remove some *IMPORTANT* macros from
>>>>>>> /trunk/mingw-w64-headers/crt/float.h,
>>>>>>> e.g. FLT/DBL/LDBL_MANT_DIG, FLT_EVAL_METHOD, *ALL* decimal macros
>>>>>>> (DEC32/64/128_*, ...)
>>>>>>>
>>>>>>> When I add FLT/DBL/LDBL_MANT_DIG and FLT_EVAL_METHOD back to
>>>>>>> /trunk/mingw-w64-headers/crt/float.h,
>>>>>>> then the gcc cross build success again.
>>>>>>>
>>>>>>> So I recommend you apply the attached patch at least.
>>>>>>>
>>>>>>> btw, I know FLT_EVAL_METHOD added by C99, but
>>>>>>> libgfortran/m4/nearest.m4 use it,
>>>>>>> is it mean we should use ISO C99 compiler to build gcc 4.5 or later,
>>>>>>> not ISO C90 as
>>>>>>> http://gcc.gnu.org/install/prerequisites.html ?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Dongsheng
>>>>>>
>>>>>> Hello Dongsheng,
>>>>>>
>>>>>> the recent change to float.h was necessary to support the new
>>>>>> include_next patch of 4.6. So how are you exactly installing headers?
>>>>>> As usual you should just see gcc's internal float.h for older gcc's
>>>>>> then 4.6. So I am a bit puzzled. Are you removing gcc's float.h here?
>>>>>>
>>>>>> Regards,
>>>>>> Kai
>>>>>>
>>>>>
>>>>> Hi Kai,
>>>>>
>>>>> I use Debian 6.0 i686 with latest update, gcc 4.4.4 build a gcc 4.5
>>>>> cross compiler for windows,
>>>>> then use the cross compiler to build a native gcc 4.5 compiler for
>>>>> windows.
>>>>>
>>>>> Without the patch, both i686-windows and x64-windows failed during build
>>>>> native
>>>>> compiler.
>>>>>
>>>>> It's strange since I can build cross compiler, it maybe a gcc bug.
>>>>>
>>>>> The related packages is:
>>>>> gcc 4.5 branch, mingw64 trunk, binutils trunk, gmp 5.0 branch, mpfr 3.0
>>>>> branch,
>>>>> mpc 0.8.2, ppl 0.10.2, cloog-ppl 0.15.9.
>>>>>
>>>>> Regards,
>>>>> Dongsheng
>>>>>
>>>>>
>>>>
>>>> Well, yes it is a gcc bug in respect to native/cross toolchains. I
>>>> assume that your search path installs headers (and libraries) in
>>>> standard_include for native. This cause that the system-headers get
>>>> included before fixed-include and gcc-include.
>>>> For this I can provide a patch. See revision 2986. But indeed this
>>>> include-order of gcc is a conceptional flaw.
>>>>
>>>> Cheers,
>>>> Kai
>>>>
>>>
>>> This build error fixed now, thank your excellent work !
>>>
>>> Thank you very much !
>>>
>>> But new error occurred when I use cross compiler to build native compiler:
>>>
>>> ...
>>> i686-w64-mingw32-gcc  -O2 -pipe -DIN_GCC   -W -Wall -Wwrite-strings
>>> -Wcast-qual -Wstrict-prototypes -Wmissing-

Re: [Mingw-w64-public] Issues compiling Info-zip's zip 3.1c

[JonY]

On 7/31/2010 22:09, Chris Sutcliffe wrote:
>On 7/30/10 11:40 PM, Chris Sutcliffe wrote:
>> Doing a little more digging, it seems like it's not dllwrap at all,
>> it's gcc:
>>
>> x86_64-w64-mingw32-gcc -Wl,--enable-stdcall-fixup -ozip32z64.dll -s
>> -shared windll.o windllrc.o api.o zipl.o cryptl.o ttyiol.o zipfilel.o
>> zipupl.o fileiol.o utill.o crc32l.o  globalsl.o deflatel.o treesl.o
>> zbz2errl.o win32l.o win32zpl.o win32i64l.o ntl.o  -luser32 -ladvapi32
>> zipfilel.o:zipfile.c:(.text+0x15b1): undefined reference to
>> `__p___mb_cur_max'
>> fileiol.o:fileio.c:(.text+0x508): undefined reference to
>> `__p___mb_cur_max'
>> fileiol.o:fileio.c:(.text+0x59a): undefined reference to
>> `__p___mb_cur_max'
>> fileiol.o:fileio.c:(.text+0x5b7): undefined reference to
>> `__p___mb_cur_max'
>> fileiol.o:fileio.c:(.text+0x61b): undefined reference to
>> `__p___mb_cur_max'
>> fileiol.o:fileio.c:(.text+0x64c): more undefined references to
>> `__p___mb_cur_max' follow
>>
>> Yet as previously mentioned, mb_cur_max is exported my libmsvcrt.a.
>>
>> I'm stumped.
>
> It turns out it's not gcc, it's due to the fact that libmsvcrt.a doesn't
> export `__p___mb_cur_max'.  The mingw.org msvcrt.def file contains:
>
> __p___mb_cur_max
>
> where as the mingw-w64-crt does not.  Would it be possible to have this
> added?
>
> Thank you,
>
> Chris
>

OK.

I'll work on it.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Issues compiling Info-zip's zip 3.1c

[JonY]

On 7/31/2010 22:17, JonY wrote:
> On 7/31/2010 22:09, Chris Sutcliffe wrote:
>> On 7/30/10 11:40 PM, Chris Sutcliffe wrote:
>>> Doing a little more digging, it seems like it's not dllwrap at all,
>>> it's gcc:
>>>
>>> x86_64-w64-mingw32-gcc -Wl,--enable-stdcall-fixup -ozip32z64.dll -s
>>> -shared windll.o windllrc.o api.o zipl.o cryptl.o ttyiol.o zipfilel.o
>>> zipupl.o fileiol.o utill.o crc32l.o globalsl.o deflatel.o treesl.o
>>> zbz2errl.o win32l.o win32zpl.o win32i64l.o ntl.o -luser32 -ladvapi32
>>> zipfilel.o:zipfile.c:(.text+0x15b1): undefined reference to
>>> `__p___mb_cur_max'
>>> fileiol.o:fileio.c:(.text+0x508): undefined reference to
>>> `__p___mb_cur_max'
>>> fileiol.o:fileio.c:(.text+0x59a): undefined reference to
>>> `__p___mb_cur_max'
>>> fileiol.o:fileio.c:(.text+0x5b7): undefined reference to
>>> `__p___mb_cur_max'
>>> fileiol.o:fileio.c:(.text+0x61b): undefined reference to
>>> `__p___mb_cur_max'
>>> fileiol.o:fileio.c:(.text+0x64c): more undefined references to
>>> `__p___mb_cur_max' follow
>>>
>>> Yet as previously mentioned, mb_cur_max is exported my libmsvcrt.a.
>>>
>>> I'm stumped.
>>
>> It turns out it's not gcc, it's due to the fact that libmsvcrt.a doesn't
>> export `__p___mb_cur_max'. The mingw.org msvcrt.def file contains:
>>
>> __p___mb_cur_max
>>
>> where as the mingw-w64-crt does not. Would it be possible to have this
>> added?
>>
>> Thank you,
>>
>> Chris
>>
>
> OK.
>
> I'll work on it.

Hi,

it looks like 64bit msvcrt doesn't export __p___mb_cur_max, but thanks 
for the heads up, they need updating anyway.

Some other fix is needed.

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Installing MinGW 64-bit and MSYS

[JonY]

On 8/9/2010 09:01, Sisyphus wrote:
>
> - Original Message -
> From: "Chris Saunders"
> To: "MinGW 64-bit"
> Sent: Monday, August 09, 2010 9:30 AM
> Subject: [Mingw-w64-public] Installing MinGW 64-bit and MSYS
>
>
> I had the 64-bit version installed before but had to re-install my OS.  I
> downloaded the file mingw-w64-v1.0-snapshot-20100730.tar.bz2 but this
> doesn't seem to extract to the same directory structure I had before.
>
> ==
>
> I think that was a source tarball that you downloaded - you're after an x64
> pre-built mingw64 binary.
>
> But geez, it's currently hard to find such a beast at
> http://sourceforge.net/projects/mingw-w64/files/ .
>
> I was thinking, maybe:
>
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-1.0-bin_i686-mingw_20100702.zip/download
>
> But that might be a 32-bit compiler ? (I'm thinking that the "i686-mingw"
> part denotes 32-bit, and that you're looking for "x86_64-mingw" instead 
> which I don't see anywhere.)
>

Thats the 64bit compiler.

The "w64" means 64bit target. i686-mingw means it runs natively on 32bit 
windows.

See link for basic outline of the file name structure:


For MSYS to work, you want the i686-mingw version.

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] add quakespasm among projects using mingw-w64

[JonY]

On 8/20/2010 21:25, Ozkan Sezer wrote:
> I've been forgetting this for quite some time:
> http://quakespasm.sourceforge.net/
>
> We've been compiling for w64 using mingw-w64 for some time.
> The project uses SDL, so we are including x64 builds of SDL
> also prepared using mingw-w64. It has been successful since
> the beginning.
>

OK. Added in r3423.

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Warning running configure with --host=i686-w64-mingw32

[JonY]

On 8/23/2010 06:27, Chris Saunders wrote:
> If I run configure for GMP, MPFR, MPC and MPFI I get this warning from 
> configure:
>
> configure: WARNING: If you wanted to set the --build type, don't use --host.
>  If a cross compiler is detected then cross compile mode will be used.
>
> Now, all of the libraries cited seem to work just fine but I am wondering if 
> there is a way to avoid this warning.  I'll point out that I am building 
> these libraries using MSYS on Windows 7 64-bit.
>
> Regards
> Chris Saunders
>

Hi,

you could use --build in conjunction with --host. All autotools is 
saying is that "are you sure you want to cross compile?".

--build is usually the native triplet.

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] gcc (tdm) 4.5 - broken assembler? (invalid instruction suffix for `push')

[JonY]

On 8/27/2010 09:37, mescali...@gmail.com wrote:
>hi,
> I just installed a mingw-w64 toolcain using the ossbuild script.
>
> I started building tcl, but it stopped at some point with this error:
>
> ~tcl8.5.8/win $ ./configure --enable-shared --host=x86_64-w64-mingw32
> --target=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
> [...]
> x86_64-w64-mingw32-gcc -c -O2 -fomit-frame-pointer -Wall
> -I"./../generic" -DTCL_TOMMATH -DMP_PREC=4 -I"./../libtommath" -I"."
> -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1
> -DHAVE_NO_SEH=1 -DHAVE_NO_LPFN_DECLS=1 -DHAVE_ALLOCA_GCC_INLINE=1
> -DHAVE_CAST_TO_UNION=1 -DTCL_CFGVAL_ENCODING=\"cp1252\"
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
> -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1   -DBUILD_tcl "tclWinChan.c" -o
> tclWinChan.o
> tclWinChan.c: In function 'TclpGetDefaultStdChannel':
> tclWinChan.c:1226:22: warning: cast from pointer to integer of different
> size
> tclWinChan.c: In function 'TclWinOpenFileChannel':
> tclWinChan.c:1339:39: warning: cast from pointer to integer of different
> size
> C:\Users\Federico\AppData\Local\Temp\ccDDhQ7j.s: Assembler messages:
> C:\Users\Federico\AppData\Local\Temp\ccDDhQ7j.s:834: Error: invalid
> instruction suffix for `push'
> make: *** [tclWinChan.o] Error 1
>
> how come?? I checked the x86_64 instruction set [1], and it appears
> PUSHL is not a valid instruction.
> so what's happening? it's using a x86 compiler to generate assembly,
> ignoring --target/--build/--host directives?
>
>
> [1]: http://support.amd.com/us/Processor_TechDocs/24594.pdf
>

pushl is not a valid 64bit insn, there is only pushq.

It is only valid for 32bit x86. Your program might be using inline 
assemblies.

The "cast from pointer to integer of different size" warning is a big 
red flag that the program assumes LP64 instead of LLP64. This program 
will not work properly in win64 unless you fixed those issues.

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] import library overlap

[JonY]

On 8/30/2010 21:00, Chris Sutcliffe wrote:
> The latest crt (at least the one in the Cygwin 'dist' release) has
> conflicting exports:
>
> csutc...@eush65 /usr/x86_64-w64-mingw32/sys-root/mingw/lib
> $ x86_64-w64-mingw32-nm.exe libadvapi32.a | grep -i OpenProc
>  T OpenProcessToken
>  I __imp_OpenProcessToken
>
> csutc...@eush65 /usr/x86_64-w64-mingw32/sys-root/mingw/lib
> $ x86_64-w64-mingw32-nm.exe libkernel32.a | grep -i OpenProc
>  T OpenProcessToken
>  I __imp_OpenProcessToken
>  T OpenProcess
>  I __imp_OpenProcess
>
> The OpenProcessToken in particular has come to bite me in a bad way
> with Emerge Desktop.  I ran in to this issue when using gendef to
> update the def files for w32api, in that I had to check for multiple
> export definitions of the same function and go to MSDN to determine
> which library is expected to export a given function.
>

Thanks for the report. Do you have a list of symbols that are known to 
conflict?


--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] gettext/libintl

[JonY]

On 9/1/2010 15:35, Erwin Waterlander wrote:
> Hi,
>
> Are there plans to add gettext and libintl packages to mingw-w64?
>
> Erwin Waterlander
>

Hi,

gettext isn't part of the toolchain, so no, we don't provide them, 
unless somebody is willing to maintain it.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Canadian cross still broken?

[JonY]

On 9/6/2010 05:27, İsmail Dönmez wrote:
> Hi;
>
> On Mon, Sep 6, 2010 at 12:12 AM, Kai Tietz  wrote:
>> Well, could you please try '../configure --host=x86_64-w64-mingw32
>> --enable-lib32 --enable-lib64  --prefix=/usr/local/mingw64'. Does this
>> change the behavior? At least for me it worked that way.
>
> Sadly that didn't help either. I'll do more tinkering tomorrow. Thanks
> for your help, its appreciated.
>
> Regards,
> ismail

Hi,

Did you remember to link /usr/local/mingw64/mingw/ to 
/usr/local/mingw64/x86_64-w64-mingw32?

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Canadian cross still broken?

[JonY]

On 9/6/2010 15:11, İsmail Dönmez wrote:
> Hi;
>
> On Mon, Sep 6, 2010 at 4:03 AM, JonY  wrote:
>> On 9/6/2010 05:27, İsmail Dönmez wrote:
>>>
>>> Hi;
>>>
>>> On Mon, Sep 6, 2010 at 12:12 AM, Kai Tietz
>>>   wrote:
>>>>
>>>> Well, could you please try '../configure --host=x86_64-w64-mingw32
>>>> --enable-lib32 --enable-lib64  --prefix=/usr/local/mingw64'. Does this
>>>> change the behavior? At least for me it worked that way.
>>>
>>> Sadly that didn't help either. I'll do more tinkering tomorrow. Thanks
>>> for your help, its appreciated.
>>>
>>> Regards,
>>> ismail
>>
>> Hi,
>>
>> Did you remember to link /usr/local/mingw64/mingw/ to
>> /usr/local/mingw64/x86_64-w64-mingw32?
>>
>
> Yes it was in my PATH. I just re-tried from scratch and same error. ld
> seems to be misbehaving somehow.
>
> Regards,
> ismail
>
>

No, not path. By link, I meant using symlinks on Linux and junction 
points in Windows.

The compiler looks in /usr/local/mingw64/mingw instead of 
/usr/local/mingw64/x86_64-w64-mingw32, so you'll need to link them.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Canadian cross still broken?

[JonY]

On 9/6/2010 15:52, Mario Emmenlauer wrote:
>
> Hi,
>
> I'm the original author of the issue [0] that Ismail referenced. During
> the last months since my report, I've repeatedly re-tried numerous times,
> but failed to build the canadian cross. Actually, back then mostly the
> same suggestions where given, tried, and failed. As you can see from my
> post, I've tried the following compile instructions:
>   - makefile: mingw64 svn experimental/buildsystem/makebuildroot-test.mk
>   - makefile: mingw64 svn experimental/buildsystem/makebuildroot.mk
>   - compile instructions from mingw64 sourceforge wiki
> all with variations of multilib, gcc-versions, ld-versions etc...
>
>
> Would it maybe be a good idea that someone who got the canadian cross
> running create a working Makefile? There are the excellent Makefiles
> "makebuildroot-test.mk" and "makebuildroot.mk" (from your project), that
> both follow the wiki compile instructions (more or less), but both fail
> in the pre-last step of ld linking.
> A working Makefile would be a good documentation, reference, and a perfect
> standard for regression testing.
>
> All the best, and keep up the good work!
>
> Mario
>
>
> [0]
> http://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg00839.html
>
>

Did you link lib to lib64? And do you have lib32? Native cross-back 
works fine for me.

Are you talking about a triple cross? I tried 
i686-linux->sparc-linux-mingw64 before, it works fine too.

You might have better chance with makebuildroot-test.mk for canadian 
cross, I've used it for the sparc triple cross.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problem configuring wxWidgets-2.9.1 withTDM64-GCC 4.5.1

[JonY]

On 9/6/2010 17:36, Bidski wrote:
> OK, I solved that original problem by copying the files from the
> C:\MinGW\x86_64-w64-mingw32 directory to the C:\MinGW directory, but now I
> am getting a problem with strnlen not being declared. The error is once
> again from building wxWidgets-2.9.1, during the make stage this time though.
>
> In file included from ../include/wx/crt.h:20:0,
>   from ../include/wx/string.h:4280,
>   from ../include/wx/memory.h:16,
>   from ../include/wx/object.h:20,
>   from ../include/wx/utils.h:19,
>   from ../include/wx/vector.h:31,
>   from ../src/stc/scintilla/src/Selection.h:134,
>   from ../src/stc/scintilla/src/Editor.cxx:41:
> ../include/wx/wxcrt.h: In function 'size_t wxStrnlen(const char*, size_t)':
> ../include/wx/wxcrt.h:174:92: error: 'strnlen' was not declared in this
> scope
> make: *** [wxscintilla_Editor.o] Error 1
>
> The check in configure returns positive for finding strnlen
>
> configure:36036: checking for strnlen
> configure:36092: gcc -o conftest.exe -m64  -m64
> conftest.c  -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 
> -ladvapi32
>   -lwsock32 -lgdi32>&5
> configure:36098: $? = 0
> configure:36116: result: yes
>
> Im sure this has to be a problem with TDM64-4.5.1 as this exact copy of
> wxWidgets was built successfully without any problems at all under
> TDM64-4.5.0.
>
> Is anyone else having problems like this?
>
> Regards
> Bidski
>
>
>

Hi,

Note the driver used for the compile test. C test passes but not C++. I 
think strnlen is disabled for C++, or maybe somebody forgot to include 
the correct headers.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public