Re: [Mingw-w64-public] Compiling OpenSSL with mingw-w64

[Kai Tietz]

Hi Stefan,
Hi,
 
 I just tried to compile OpenSSL-0.9.8h with mingw-w64 (see
 http://sourceforge.net/projects/mingw-w64/) and needed a couple
 of changes to the source code (see attached patch).
 
 Some notes:
 - I added a mingw64 line to Configure and (think I) told it to use
 .exe
   extension for compiling. Nothing surprising here, I think. Note that
   you currently need to Configure mingw64 no-asm no-hw.
 
 - windows.h apparently includes wincrypt.h (no idea whether that's
   specific to that compiler, but it seems so ...), so I needed to 
   #undefine a couple of names messed up by wincrypt.h
   (patches to rand.h, x509.h and e_os.h).
 
 - It's using a very recent snapshot of gcc, so there also is the
   problem in e_os2.h, that has already been reported for
   gcc-4.3: the compiler complains about the same variable
   being declared as both extern and static - so I changed that
   to use static both times - but I'm not really sure what's the
   correct thing to do here.

The cygwin specific options - like -mno-cygwin - in the mingw64 line 
of configure are not necessary. There is no cygwin for 64-bit for now 
IIRC.

Thank you for porting.

Regards,
  Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/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] FW: Mail delivery failed: returning message to sender

[Kai Tietz]

Hi Stefan,

  I agree that the declaration of alarm is a way not telling truth
  here,  but I found some applications, which are dependent to
  such a not honest way.
 
 I find it surprising that they actually work with such a trick, but
 there always are interesting surprises in porting ...
 
  I could agree to remove the declaration from headerset by using a 
  macro clause '__MINGW_POSIX_ALARM' (in io.h). The declaration of 
  SIGALRM I  dislike to remove, but if it is necessary to remove this
  define,  please describe me the reason more detailed.
 
 Actually, openssl is using availability of SIGALRM to decide between
 alarm-based implementation and a replacement, so removing alarm
 itself doens't really help. Anyway, now that I know which way to go,
 I can also suggest to patch openssl in such a way as to simply
 #undef SIGALRM for mingw-w64 instead of including the header
 needed for the dummy alarm implementation.
 
 Something different:
 Why are there both 
   /home/mingw-w64/lib/gcc/x86_64-pc-mingw32/4.4.0/include/float.h
   /home/mingw-w64/x86_64-pc-mingw32/include/float.h
 (at least in the linux 32-bit package I'm using for cross-compilation)
 with only the last containing prototypes for _finite and a couple
 of other functions, but the first being the one that's found and used
 by the compiler? 
Normally the local version should be used. There are some small but 
important difference between the gcc version and our.

 It's causing the current compile failure of wxWidgets (trunk) visible
 on that daily rebuild page (at least until the next recompile, I've
 added a hack to my local mingw-w64-headers to work around
 that problem)...

I missed to change implementation files necessary by prototype changes I 
did. Thanks for telling me that.
Committed revision 451.

   Regards,
Stefan
 
 P.P.S.: Concerning that type of the return value of the thread function,
I mentioned in some old mail,  your software was right and wx
was wrong (has been fixed in the meantime...).

Regards,
Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] FW: Mail delivery failed: returning message to

[Kai Tietz]

Hi,
 
 [Sorry for the messed up subject line, but I guess I'll better
  continue with it rather than starting a new thread ...]
 
   Something different:
   Why are there both 
 /home/mingw-w64/lib/gcc/x86_64-pc-mingw32/4.4.0/include/float.h
 /home/mingw-w64/x86_64-pc-mingw32/include/float.h
   (at least in the linux 32-bit package I'm using for 
cross-compilation)
   with only the last containing prototypes for _finite and a couple
   of other functions, but the first being the one that's found and 
used
   by the compiler? 
  Normally the local version should be used. There are some small but 
  important difference between the gcc version and our.
 
 Sorry, I don't understand, which one you mean by local version...
 Anyway, the way the built-in include paths are set up, it's the one
 in lib/gcc/x86_64-pc-mingw32/4.4.0/include that's used by default.
 Is that good or bad?
Normally it should be good, but may you could sent me your local hack and 
I can see what problems there are.

   It's causing the current compile failure of wxWidgets (trunk) 
visible
   on that daily rebuild page (at least until the next recompile, I've
   added a hack to my local mingw-w64-headers to work around
   that problem)...
  
  I missed to change implementation files necessary by prototype changes 
I 
  did. Thanks for telling me that.
  Committed revision 451.
 
 Huh? What did I tell? I'm lost ...
The build failures in mingw-w64 crt about exece  co ;)

Regards,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
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 with main() parameters in subsystem:windows apps

[Kai Tietz]

Hi Tor,

[EMAIL PROTECTED] wrote on 08.08.2008 
08:33:16:

 I recently built the GTK+ stack and its dependencies with mingw-w64
 (as cross-compilation from win32), and was pleasantly surprised with
 how easy it was. Then I built GIMP, but there I ran into just one
 problem: In an executable built with -mwindows, the argc and argv
 parameters to main() are bogus. (__argc and __argv from stdlib.h work
 fine, though.) Is this a known problem?

Nice to hear. If you build an executable by using -mwindows the main 
routine is crt internally use only. The arguments passed here are bogus. 
You should use instead the standard function WinMain as entry proint for 
your user application. This works very well. The function main is normally 
just used by -mconsole (the default setting of gcc).

Cheers,
 Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] setjmp/longjmp issue

[Kai Tietz]

Hi,

2008/11/13 Alon Bar-Lev [EMAIL PROTECTED]:
 Hello,

 I almost sure it worked until recently... But now a simple program:
 #include setjmp.h
 #include stdlib.h

 int main(void) {
setjmp(NULL);
longjmp(NULL, 0);
 }

 Cannot be compiled.
 x86_64-pc-mingw32-gcc a.c
 /tmp/cctlj9Wj.o:a.c:(.text+0xe): undefined reference to `_mingw_getsp'
 /tmp/cctlj9Wj.o:a.c:(.text+0x2a): undefined reference to `_longjmp'
 collect2: ld returned 1 exit status

 Using i686-pc-mingw32 it compiles.

 Any clue?
 Using:
 binutils CVS head
 gcc-4.2.3
 mingw-w64 svn trunk

 Alon.

 -
 This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
 Build the coolest Linux based applications with Moblin SDK  win great prizes
 Grand prize is a trip for two to an Open Source event anywhere in the world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


ok, to support you I need some more details

Which host you are using?
Which x86_64-pc-mingw32-gcc you are invoking ? Do you use it from
root/bin, or from root/x86_64-pc-mingw32/bin?
Have you installed the crt itself?

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] -fno-leading-underscore should be default?

[Kai Tietz]

Graham Greene graham.gre...@charter.net wrote on 04.03.2009 07:17:05:

 NightStrike wrote:
   On Tue, Mar 3, 2009 at 2:16 PM, Jackie 
 kjac...@gmail.com wrote:
   Hello,
  
   I got some problems when I tried to use the library compiled by
   mingw-w64 in VS2008, then I search the issue on the web. It says
   mingw-64 and msvc use different function name decoration, and it 
seems
   can be solved by using -fno-leading-underscore to compile CRT and
   other base libraries. However, all of the binaries (for Linux)
   distributed on SF.net still have this problem. Both Win64 and MSVC 
are
   created by M$, and mingw-w64 is intent to create things for Win64, 
isn't
   it? Why not make things compatible with MSVC?
  
   Best regards,
  
   Kai-Chieh Ku.
  
   I see your point.  Since we are emulating MS, you are saying we 
should
   emulate them as default, and provide alternates via options.
   Currently, we are using the alternate as the default and emulating MS
   as an option.
  
   I don't personally know which is best.
 
 Does this have to do with exported __stdcall functions not having an 
 underscore prefix on their symbol name?
 
 gg
 

On Win64 there is just __fastcall convention. Any other calling convention 
is treated, but makes no differences on calling convention, nor on name 
decoration. At the moment we decorate C symbols by an underscore, this 
have to be changed in future release. The reason why I did this was, that 
first the world within our toolchain has to proven as valid. While 4.5 gcc 
is running, I plan to change the default behaviour of x64.

Cheers,
Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Instabilities in mingw-w64 and mingw-w32 generated binaries.

[Kai Tietz]

2009/3/9 Wolfgang Glas wolfgang.g...@ev-i.at:
 Hi all,

  I've now established to compile all of my source code for a mid-sized
 production C++ Windows Service using mingw-w64-20090307 and 
 mingw-w32-20090307.

  All of this code is running stable with mingw32's gcc-3.4.5 version. (The
 service is a multithreaded CORBA servant using omniORB-4.1 and runs for weeks
 w/o memory leak or crashes...) The code has also undergone intensive valgrind
 testing under Linux.

  Nevertheless I'm getting various crashes in my application, which I'm unable
 to reproduce in a test case:

 - The 32bit executable seems to work on Windows XP x86 without flaws.

 - The 32bit executable crashes in CosNaming::NamingContext::_narrow() insode
 omniORB413_nt.dll when started under Windows XP x64.

 - The 64bit executable crashes when alloca() is called. If the use of alloca()
 is pmitted, it crashes lateron.

 The stack traces of gdb are definitely unusable, but I got the impression that
 the programs are crashing. However, when I registers Microsoft's windbg tools 
 as
 the default post-mortem debugger, I get no popup from windbg nor a dump file 
 on
 disk...

 At this point I'm completely stuck. I have to wait until Linux rules the world
 or until MSVC has turned into a reasonable C compiler :(

 (Gosh, how old will I be when one of these happens...)

 Are there any ideas/hints on how to sort out these problems?

 Might it be possible, that the stack layout of mingw-w{32,64} does not conform
 to any subtle detail of the specification?
I don't assume that the stack layout itself is the problem.

 Might the fact, that the 32bit executable crashes under x64 be a hint, that 
 the
 calling conventions confuse the ntdll.dll calls? (ntdll.dll is AFAIK the only
 DLL, which has been replaced for WOW64 in order to dispatch kernel calls of
 32bit apps to the 64bit kernel...)

Well, for 32-bit we use the same calling convention (and
implementation) as mingw32.
So I assume we have an optimization issue here in gcc. My guess is
that gimplifier, SSA, or IRA are making here troubles. Because, if you
compile your code without optimizations I bet, that your application
will work proper for mingw-w64's 64-bit and 32-bit version.

So I assume we have to take care about finding optimization problems here.
So to figure out more closely what's going wrong, we need regular
testsuite runs for 64-bits and 32-bits variant. So we have a better
chance to figure out, where the problems are.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun no resolution yet.

[Kai Tietz]

2009/3/15 Wolfgang Glas wolfgang.g...@ev-i.at:
 Hi all,

  I've been trying very hard to reduce my alloca() problems and at got stuck
 with every attempt to isolate the problem.

  Finally I linked a mildly complex C-program, which crashed before using a
 handcrafted Makefile and luckily I found out, that the program crashes, when I
 add a bunch Window's system libraries to the linker command line. (A practice 
 I
 cowardly copied from another project years ago...)

  I've uploaded a self-contained (but not small) testcase to our weebserver 
 under

  http://www.ev-i.at/tmp/mingw_hpgspdf_test.tar.gz

 The makefile generates two executables: One linked just with the 
 self-generated
 DLLs and one linked with a long list of windows system libraries. The 
 executable
 linked with the windows libraries is called hpgspdffile-read-fail.exe and has 
 a
 different size than the executable hpgspdffile-read.exe linked with just the
 self-generated libraries. Besides, it has the same runtime dependencies and
 however it *does* crash right after alloca(), while the other one survives
 flawlessly.

  The program reads a PDF-file, interprets it's internal structure and
 re-serializes the file afterwards. (Should work with any normal PDF-file).

  This is my debug-session:

 **
 H:\wglas\CC\mingw_hpgspdf_test\bin64gdb-w64 .\hpgspdffile-read-fail.exe
 GNU gdb 6.7.50.20080109-cvs
 Copyright (C) 2008 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as x86_64-pc-mingw32...

 warning: A handler for the OS ABI Cygwin is not built into this 
 configuration
 of GDB.  Attempting to continue with the default i386:x86-64 settings.

 (gdb) break hpgspdffile.c:1230
 Breakpoint 1 at 0x40eead: file hpgspdffile.c, line 1230.
 (gdb) r H:\wglas\doc\hp\bpl13205.pdf x.pdf
 Starting program: 
 H:\wglas\CC\mingw_hpgspdf_test\bin64/.\hpgspdffile-read-fail.e
 xe H:\wglas\doc\hp\bpl13205.pdf x.pdf
 len=28.
 value=C:\Program Files (x86)\cdes.
 prefix=C:\Program Files (x86)\cdes.
 Opening file H:\wglas\doc\hp\bpl13205.pdf.
 Reading file H:\wglas\doc\hp\bpl13205.pdf.

 Breakpoint 1, hpgs_pdf_file_read_xref (pdf=0x3f7720) at hpgspdffile.c:1230
 1230    hpgspdffile.c: No such file or directory.
        in hpgspdffile.c
 (gdb) print tail_data
 $1 = 0x22fda0 
 (gdb) print len
 $2 = (size_t *) 0x22fdb0
 (gdb) n

 Program received signal SIGSEGV, Segmentation fault.
 0x07ff7fc52806 in ?? ()
 (gdb) bt
 #0  0x07ff7fc52806 in ?? ()
 #1  0x07ff7fc4a949 in ?? ()
 #2  0x0003 in ?? ()
 #3  0x0003 in ?? ()
 #4  0x0003 in ?? ()
 #5  0x0033d627 in ?? ()
 #6  0x in ?? ()
 (gdb) q
 The program is running.  Exit anyway? (y or n) y

 H:\wglas\CC\mingw_hpgspdf_test\bin64
 **

  Explanation:

 tail_data is a char-array of size 2048, which has been allocated through
 alloca(), 'len' is a local variable. The problem her is, that alloca() places
 tail_data 16 bytes before len, which is far less than the required 2048 
 bytes...

  Hopefully, this will bring us one step further in resolving this curious 
 problem.

  Regards,

    Wolfgang


 --
 Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
 powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
 easily build your RIAs with Flex Builder, the Eclipse(TM)based development
 software that enables intelligent coding and step-through debugging.
 Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


By trying to reduce this test case I stumble over the assembly produced
 leaq30(%rbx), %rax
 andq$-16, %rax
 call___chkstk

so, if %rbx is zero (len == 0) this happens what you are describing.
that tail_data is just 16 bytes away from file_len. So possibly you
should check the result of hpgs_istream_tell(pdf-is,file_len), if
file_len is not equal to zero. If it is, all points to an alias issue.

Cheers,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day 

Re: [Mingw-w64-public] alloca()-Problems, a smoking gun no resolution yet.

[Kai Tietz]

2009/3/15 Shaun Barlow shaun.d.bar...@gmail.com:
 Hi,

 Ok, I found the issue. Your application calls __chkstk from kernel32,
 which is pretty false. Because the MS variant just probes the stack,
 but does not allocate it as the cygwin variant. There are two possible
 ways to solve this, a) Remove the export from kernel32.def in lib64,
 or rename the method in gcc/config/i386 defined in cygwin.asm and
 referenced in i386.md

 Thank you very much to Wolfgang for making the testcase, and Kai for
 finding the problem :)
 Applying Kai's solution a) Remove the export from kernel32.def in
 lib64, to a local checkout
 of the mingw-w64 crt has gotten rid of the segfaults I was
 experiencing in my program

 In my opinion, solution a) would be the correct course because it
 matches the behaviour of both
 the mingw project's export library and Microsoft own export library
 (referencing __chkstk in either
 and then linking to kernel32 gives an unresolved symbol). Its naming
 (double underscore prefix), would
 also seem to indicate that it is not intended for outside use.

 It is obviously Kai's decision which route to take.

 Thanks and best regards,
 Shaun


Yes, this issue is a bit annoying and is ported from mingw32. I
disabled temporary the export symbol __chkstk in ntdll.def,
kernel32.def, and ntoskernl.def. So always the variant of gcc is used
and those kind of errors a prevented. But this means of course that vc
generated libraries, which are using __chkstk will fail (as the do on
32-bits).
I want to provide a change in 4.5 gcc to avoid this issue completely
and allow the co-existance of gcc's and vc's stack checking routine
for 64-bit and 32-bit by renaming the gcc's variant to __gnu_chkstk.

Fix is on mingw-w64 trunk rev.678.

Cheers,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-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] cross link problem

[Kai Tietz]

Hello Zhou,

2009/3/18 zhou drangon drangon.z...@gmail.com:
 2009/1/13 NightStrike nightstr...@gmail.com:
 On Thu, Oct 23, 2008 at 9:17 AM, Kai Tietz kai.ti...@onevision.com wrote:
 Jesper Quorning jquorn...@clcbio.com wrote on 23.10.2008 14:13:08:

 Hi All,
 I try to link together a module compiled with x86_64-pc-mingw32-gcc and
 a module compiled with MS cl (64bit). link with MS link, but it fails
 with

 hello.obj : error LNK2019: unresolved external symbol call_me referenced

 in function main

 I have tryed with different call conventions but without any luck. What
 am I missing here ?

 Regards,
 Jesper Quorning

 The problem here is the name decoration. MS doesn't extend the public
 symbols in objects by underscores, mingw-w64 does this by default. But you
 can recompile mingw-w64 crt and your app by using option
 -fno-leading-underscores. This should work.
 The other solution would be, name the exported method call_me in VS
 _call_me, and reference in gcc just without the leading underscore.

 I hope I could help.

 Cheers, Kai

 I have the similar problem and the -fno-leading-underscores resolve the 
 problem.
 Now I can use VS2005 to link with static library created by mingw-w64.
 But when I want to change the static library to dynamic library, the
 following error emit :

 g++ -g -Wall -pipe  -fno-leading-underscore -DDLL_CREATE -c -o adlib.o 
 adlib.cpp

 g++ -g -Wall -pipe  -fno-leading-underscore -DDLL_CREATE -shared 
 -Wl,--out-impli
 b,adlib.lib -o adlib.so adlib.o
 Creating library file: adlib.lib
 Cannot export _ZN4ADYC4FuncEi: symbol not found
 Cannot export _ZN4ADYCC1Ev: symbol not found
 Cannot export _ZN4ADYCC2Ev: symbol not found
 Cannot export _ZN4ADYCD1Ev: symbol not found
 Cannot export _ZN4ADYCD2Ev: symbol not found
 Cannot export g_dy_data: symbol not found
 Cannot export g_dy_func: symbol not found
 collect2: ld returned 1 exit status
 make: *** [adlib.so] Error 1

 Even If I do not create the import-library for VS2005, the error emit :
 g++ -g -Wall -pipe  -fno-leading-underscore -DDLL_CREATE -c -o adlib.o 
 adlib.cpp

 g++ -g -Wall -pipe  -fno-leading-underscore -DDLL_CREATE -shared -o adlib.so 
 adl
 ib.o
 Cannot export _ZN4ADYC4FuncEi: symbol not found
 Cannot export _ZN4ADYCC1Ev: symbol not found
 Cannot export _ZN4ADYCC2Ev: symbol not found
 Cannot export _ZN4ADYCD1Ev: symbol not found
 Cannot export _ZN4ADYCD2Ev: symbol not found
 Cannot export g_dy_data: symbol not found
 Cannot export g_dy_func: symbol not found
 collect2: ld returned 1 exit status
 make: *** [adlib.so] Error 1

 The gcc version I used is :

 E:\code\test_intergcc -v
 Using built-in specs.
 Target: x86_64-pc-mingw32
 Configured with: ../gcc/configure --host=x86_64-pc-mingw32 
 --target=x86_64-pc-mi
 ngw32 --disable-nls --enable-languages=c,c++ 
 --with-gmp=/compile/mingw/for_targe
 t --enable-twoprocess --disable-libstdcxx-pch --prefix=/compile/mingw/target 
 --w
 ith-sysroot=/compile/mingw/target
 Thread model: win32
 gcc version 4.4.0 20090307 (experimental) (GCC)



 Jesper, did this fix your issue?

 --
 This SF.net email is sponsored by:
 SourcForge Community
 SourceForge wants to tell your story.
 http://p.sf.net/sfu/sf-spreadtheword
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 regards,

 drangon
 -
 homepage : http://www.drangon.org/
 mingw stuff : http://www.drangon.org/mingw/
 -

 --
 Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
 powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
 easily build your RIAs with Flex Builder, the Eclipse(TM)based development
 software that enables intelligent coding and step-through debugging.
 Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Yes, there are some issues in binutils, gcc, and our crt about this.
We plan to fix this while 4.5 Stage 1.

See 
http://sourceforge.net/tracker2/?func=detailaid=2688335group_id=202880atid=983354

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net

Re: [Mingw-w64-public] how to invoke (install?) mingw64.

[Kai Tietz]

Hello Patrick,

2009/4/24 patrick flaherty p...@well.com:

 Hi,

 I successfully built the Sourceforge pyOpenSSL project with mingw32.

 But I'm on a 64-bit machine and have had problems with loading the project's
 DLLs at runtime (on a 32 bit machine loading the DLLs works fine) and when I
 found mingw-64 on sourceforge thought I'd give it a try and see if it helped
 me out on my 64 bit machine.  The code will eventually need to be deployed
 on 64 bit machines.

 Downloaded a recent toolchain build.  The instructions I used are here:

 http://mingw-w64.wiki.sourceforge.net/Installation+of+binary+toolchain+packages

 So I can copy the whole of the toolchain directory structure to any
 directory location; add the bin directory within the toolchain to my PATH;
 and at least according to the instructions above I should be good to go.

 Yeah right.

Yes, so far everything seems ok. Which toolchain you are using and
which build environment?

 The compile quickly exits with:

 L:\MyID\Python\pyOpenSSLsetup.py build_ext -Ic:\openssl\include -c
 x86_64-pc-mingw32
 running build_ext
 error: don't know how to compile C/C++ code on platform 'nt' with
 'x86_64-pc-mingw32' compiler

Hmm, what means 'nt' here?

 Looking around the web, I believe x86_64-pc-mingw32 to be the correct name
 to be use.  However when I look under where I installed mingw64, I find 3
 bin directories:

 pat$ pwd
 /cygdrive/d/mingw64
 pat$ find . -name bin
 ./bin
 ./mingw/bin
 ./x86_64-pc-mingw32/bin
 pat$

Yes, (in fact there are just two directories, because mingw is a link
to x86_64-pc-mingw32) this absolutly correct. In top bin directory you
find the binaries you should use (and you should just add this
directory to your path). The other are just for internal toolchain's
sake and you should just keep them.

 I originally set the location in PATH to the first of the 3.  Didn't work.
 And then I tried #s 2 and 3 and they provoked exactly the same error from
 the build.

 pat

I assume, that you are using the mingw 32-bit to 64-bit cross-compiler
toolchain. So there are two different possible errors I see here.
First, the python script doesn't call the proper toolchain (prefix of
all tools is x86_64-pc-mingw32- ...), or you are passing 32-bit only
parameters to 64-bit compiler.

If you can give me some more details about this issue, I'll try to help.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Crystal Reports #45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty#45;free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] how to invoke (install?) mingw64.

[Kai Tietz]

2009/4/25 patrick flaherty p...@well.com:
 Starting with this:

 http://oldwiki.mingw.org/index.php/Python%20extensions

 I believe the problem to be in distutils.  Something needs to be
 modified to accommodate  x86_64-pc-mingw32-gcc.

 So far, from distutils, I've been through msvccompiler.py,
 msvc9compiler.py and cccompiler.py.  I'm making progress but haven't
 fully gotten there yet.

 pat

Well, by configure you would specify it via the --host argument. I
assume that you have to make sure that all gcc, g++, as, windres, ld,
... calls are getting prefixed by the target triplet part. By this you
could use here nearly any cross-compilers.
But I am not very familiar with this python build script, so I am here
not much help.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Crystal Reports #45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty#45;free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
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 with mingw-w32-bin_i686-cygwin-1.5.25-15_20090612.tar.bz2

[Kai Tietz]

2009/6/22 Chris Sutcliffe ir0nh...@gmail.com:
 A subsequent issue I found was that Windows complains that the
 libgcc_s_sjlj-1.dll in the 20090612 build is not a valid windows DLL.
 Reverting to the 20090606 automated build solved the problem.

 I noticed that the 20090612 build are no longer listed so I tried the
 20090619 build and experienced the same issue of Windows complaining
 that the libgcc_s_sjlj-1.dll is not valid.  I'm testing with the
 cygwin mingw-w32 build.

 Chris

 --
 Chris Sutcliffe
 http://emergedesktop.org

 --
 Are you an open source citizen? Join us for the Open Source Bridge conference!
 Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
 Need another reason to go? 24-hour hacker lounge. Register today!
 http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Well, I just noticed that this seems to be a regression caused by
debugging information. I tried to compile a small test application,
and my vista said, that this isn't a valid x64-bit format. When I
compile together with -Wl,-S everything seems to work. So I assume
there is an issue in ld and linking debugging information. Could it be
that the debugging sections still have relocation entries, but are
marked to be *not* loaded?

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
___
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, cannot obtain back trace

[Kai Tietz]

2009/6/26 David Cournapeau courn...@gmail.com:
 On Fri, Jun 26, 2009 at 8:56 PM, Kai Tietzktiet...@googlemail.com wrote:
 Hello David,

 2009/6/26 David Cournapeau courn...@gmail.com:
 Hi,

    I am building python extensions with the mingw-w64, but I have
 some crashes which I would like to debug. Unfortunately, even when the
 extension is built with debug options (-g -DDEBUG), running the
 offending code under gdb does not bring anything useful: the backtrace
 only gives me a couple of absolute addresses. Does gdb work at all on
 windows 64 bits ? (I used the one from equations.com)

 cheers,

 David

 gdb support of x64 is present, but still limited. For the version of
 equaltions.com I don't know which version they are providing. AFAIK
 there is an issue about gdb DLLs with symbol information. The version
 provided on our site gets normally those event, but those from gdb's
 head doesn't.

 The only reason why I am using the version from equations.com is that
 I need native gcc builds (python cannot be cross-compiled easily, even
 from windows 32 bits), and I could not get gdb to build at all. Which
 version of gdb sources should I use ? Last time I tried, the configure
 stage failed telling me that the architecture is not supported (I use
 the same as for gcc/binutils, which work fine).

 David


Ah, you have to use the head version of gdb. With next release version
of gdb the target will be supported. (Use for configure of gdb
--target=x86_64-pc-mingw32 --host=x86_64-pc-mingw32). This worked fine
for me.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
___
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

[Kai Tietz]

2009/7/2 McWilliams, Steven steven_mcwilli...@bmc.com:

 Attached is the config.log file from the postgres configuration attempt.  The 
 accept() function is a socket library function.  The config.log file shows 
 it trying to compile a bunch of different test programs using accept with 
 different function signatures.  Note that when I configure postgres for 
 compilation on a 32 bit windows platform using mingw (not mingw-w64) it uses 
 the signature extern unsigned int PASCAL accept (unsigned int, struct 
 sockaddr *, int *);.

 
 From: JonY [10wa...@gmail.com]
 Sent: Thursday, July 02, 2009 9:54 AM
 To: mingw-w64-public@lists.sourceforge.net
 Cc: McWilliams, Steven
 Subject: Re: [Mingw-w64-public] basic question

 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



Well the issue is here

configure:15432: x86_64-w64-mingw32-gcc.exe -c -O2 -Wall
-Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv  -I./src/include/port/win32 -DEXEC_BACKEND  conftest.c 5
conftest.c:50: error: conflicting types for 'accept'
c:/mingw_64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:1291:
note: previous declaration of 'accept' was here

This configure test fails, as it uses a wrong function definition of
accept. This configure test needs to be fixed, then it will continue
build. Btw be sure that it uses ws2_32 as library and not wsock32 as
the later doesn't exists on x64 platforms.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

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

Re: [Mingw-w64-public] Help building a win64 native compiler from Linux

[Kai Tietz]

2009/8/21 Ozkan Sezer seze...@gmail.com:
 On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote:
 2009/8/21 t66...@gmail.com t66...@gmail.com:
 Hello,
 I filed a bug report at gcc bug tracker
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136
 Is anyone encountering this bug and is there any possible workaround ?

 --
 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


 Hello,

 thank you for reporting this. Please report such kind of failures to
 mingw-w64 project's bug tracker first. This looks not as a gcc bug
 itself, it seems to be more reasoned by other issues possibly reasoned
 by our runtime.

 Please describe also the environment you are using to build the native
 compiler, the date of runtime headers and crt you are using, and the
 binutils version you are using.

 Regards,
 Kai

 This happens because the autotools idiocy decides
 that LFS is not available and _GLIBCXX_USE_LFS is
 left undefined which is the first issue, it falls back to
 fstat instead of fstat64 and fstat wraps onto fstat64i32.
 This is actually a GCC bug, IMO.
 The second issue is that fstat64i32 is in _fstat64i32.c
 but fstat() being defined as an inline wrapping around
 it in sys/stat.h is marked __MINGW_ATTRIB_NO_OPTIMIZE
 The no-optimize maybe causing an issue here ?.

 --
 Ozkan


Hmm, well the issue in libstdc++ could be a bug in it. But the issue
about double present symbols is an issue related to the fact that it
uses the inlined version. Therefore the __NO_INLINE__ is in our
headers. Is this function not protected by an __NO_INLINE__?
This bug is reasoned IMHO by the fact, that within the file we
implement fstat64i32 and the fstat functions are within one .c file.
We should split this file, so that each function is within one
separate file here. So we avoid this.

Cheers,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Help building a win64 native compiler from Linux

[Kai Tietz]

2009/8/21 Ozkan Sezer seze...@gmail.com:
 On Fri, Aug 21, 2009 at 10:42 AM, Ozkan Sezerseze...@gmail.com wrote:
 On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote:
 2009/8/21 t66...@gmail.com t66...@gmail.com:
 Hello,
 I filed a bug report at gcc bug tracker
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136
 Is anyone encountering this bug and is there any possible workaround ?

 --
 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


 Hello,

 thank you for reporting this. Please report such kind of failures to
 mingw-w64 project's bug tracker first. This looks not as a gcc bug
 itself, it seems to be more reasoned by other issues possibly reasoned
 by our runtime.

 Please describe also the environment you are using to build the native
 compiler, the date of runtime headers and crt you are using, and the
 binutils version you are using.

 Regards,
 Kai

 This happens because the autotools idiocy decides
 that LFS is not available and _GLIBCXX_USE_LFS is
 left undefined which is the first issue, it falls back to
 fstat instead of fstat64 and fstat wraps onto fstat64i32.
 This is actually a GCC bug, IMO.

 Hmm,

 configure:19184: checking for LFS support
 configure:19276:
 /home/ozzie/deneme1/W64_150956-src/build-gcc/./gcc/xgcc -shared-libgcc
 -B/home/ozzie/deneme1/W64_150956-src/build-gcc/./gcc -nostdinc++
 -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/libstdc++-v3/src
 -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/libstdc++-v3/src/.libs
 -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/winsup/mingw
 -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/winsup/w32api/lib
 -isystem /home/ozzie/deneme1/W64_150956-src/gcc44-svn/winsup/mingw/include
 -isystem /home/ozzie/deneme1/W64_150956-src/gcc44-svn/winsup/w32api/include
 -B/home/ozzie/cross_win64/x86_64-pc-mingw32/bin/
 -B/home/ozzie/cross_win64/x86_64-pc-mingw32/lib/ -isystem
 /home/ozzie/cross_win64/x86_64-pc-mingw32/include -isystem
 /home/ozzie/cross_win64/x86_64-pc-mingw32/sys-include -o conftest.exe
 -g -O2   -fno-exceptions   conftest.cc  5
 conftest.cc: In function 'int main()':
 conftest.cc:57: error: aggregate 'stat64 buf' has incomplete type and
 cannot be defined
 conftest.cc:58: error: 'fstat64' was not declared in this scope
 configure:19282: $? = 1
 configure: failed program was:
 | /* confdefs.h.  */
 |
 | #define PACKAGE_NAME package-unused
 | #define PACKAGE_TARNAME libstdc++
 | #define PACKAGE_VERSION version-unused
 | #define PACKAGE_STRING package-unused version-unused
 | #define PACKAGE_BUGREPORT 
 | #ifdef __cplusplus
 | extern C void exit (int);
 | #endif
 | #define STDC_HEADERS 1
 | #define HAVE_SYS_TYPES_H 1
 | #define HAVE_SYS_STAT_H 1
 | #define HAVE_STDLIB_H 1
 | #define HAVE_STRING_H 1
 | #define HAVE_MEMORY_H 1
 | #define HAVE_STRINGS_H 1
 | #define HAVE_INTTYPES_H 1
 | #define HAVE_STDINT_H 1
 | #define HAVE_UNISTD_H 1
 | #define HAVE_DLFCN_H 1
 | #define LT_OBJDIR .libs/
 | #define _GLIBCXX_HOSTED 1
 | #define _GLIBCXX_SJLJ_EXCEPTIONS 1
 | #define HAVE_GTHR_DEFAULT 1
 | #define _GLIBCXX_ATOMIC_BUILTINS_1 1
 | #define _GLIBCXX_ATOMIC_BUILTINS_2 1
 | #define _GLIBCXX_ATOMIC_BUILTINS_4 1
 | #define _GLIBCXX_ATOMIC_BUILTINS_8 1
 | #define _GLIBCXX_USE_LONG_LONG 1
 | #define HAVE_WCHAR_H 1
 | #define HAVE_MBSTATE_T 1
 | #define HAVE_WCTYPE_H 1
 | #define _GLIBCXX_USE_WCHAR_T 1
 | #define _GLIBCXX_USE_C99_MATH 1
 | #define HAVE_TGMATH_H 1
 | #define HAVE_COMPLEX_H 1
 | #define HAVE_VFWSCANF 1
 | #define HAVE_VSWSCANF 1
 | #define HAVE_VWSCANF 1
 | #define HAVE_WCSTOF 1
 | #define HAVE_INT64_T 1
 | #define HAVE_INT64_T_LONG_LONG 1
 | /* end confdefs.h.  */
 | #include unistd.h
 |        #include stdio.h
 |        #include sys/stat.h
 |
 | int
 | main ()
 | {
 | FILE* fp;
 |        fopen64(t, w);
 |        fseeko64(fp, 0, SEEK_CUR);
 |        ftello64(fp);
 |        lseek64(1, 0, SEEK_CUR);
 |        struct stat64 buf;
 |        fstat64(1, buf);
 |   ;
 |   return 0;
 | }
 configure:19317: result: no

 We have struct _stat64, with the leading underscore,
 not without one.  This kind of crap is killing me..
 And the whole tree relies on the posix style non-
 underscored versions.

 The second issue is that fstat64i32 is in _fstat64i32.c
 but fstat() being defined as an inline wrapping around
 it in sys/stat.h is marked __MINGW_ATTRIB_NO_OPTIMIZE
 The no-optimize maybe causing an issue here ?.

 --
 Ozkan



Hmm, well. struct stat we define in wchar.h and in 

Re: [Mingw-w64-public] Help building a win64 native compiler from Linux

[Kai Tietz]

2009/8/21 Ozkan Sezer seze...@gmail.com:
 On Fri, Aug 21, 2009 at 10:57 AM, Kai Tietzktiet...@googlemail.com wrote:
 2009/8/21 Ozkan Sezer seze...@gmail.com:
 On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote:
 2009/8/21 t66...@gmail.com t66...@gmail.com:
 Hello,
 I filed a bug report at gcc bug tracker
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136
 Is anyone encountering this bug and is there any possible workaround ?

 --
 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


 Hello,

 thank you for reporting this. Please report such kind of failures to
 mingw-w64 project's bug tracker first. This looks not as a gcc bug
 itself, it seems to be more reasoned by other issues possibly reasoned
 by our runtime.

 Please describe also the environment you are using to build the native
 compiler, the date of runtime headers and crt you are using, and the
 binutils version you are using.

 Regards,
 Kai

 This happens because the autotools idiocy decides
 that LFS is not available and _GLIBCXX_USE_LFS is
 left undefined which is the first issue, it falls back to
 fstat instead of fstat64 and fstat wraps onto fstat64i32.
 This is actually a GCC bug, IMO.
 The second issue is that fstat64i32 is in _fstat64i32.c
 but fstat() being defined as an inline wrapping around
 it in sys/stat.h is marked __MINGW_ATTRIB_NO_OPTIMIZE
 The no-optimize maybe causing an issue here ?.

 --
 Ozkan


 Hmm, well the issue in libstdc++ could be a bug in it. But the issue

 Yes. The problem is in acinclude.m4 of libstdc++ with its
 GLIBCXX_CHECK_LFS procedure.

 about double present symbols is an issue related to the fact that it
 uses the inlined version. Therefore the __NO_INLINE__ is in our
 headers. Is this function not protected by an __NO_INLINE__?

 Yes, it is protected.

 This bug is reasoned IMHO by the fact, that within the file we
 implement fstat64i32 and the fstat functions are within one .c file.
 We should split this file, so that each function is within one
 separate file here. So we avoid this.

 Can you explain? (I'm newly awoken..)


in crt stdio/_fstat64i32.c we implement the following functions:
_fstat64i32, _stat64i32, fstat, and stat. So if one of those
functions is already in a library (e.g _fstat64i32), but fstat is
referenced by this library, too, then linker want to take the function
fstat from object stdio/_fstat64i32.o. But this object also includes
_fstat64i32 function, so it leads to double defined linker errors. We
should split this file into its four different functions.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] gcc-4.4.1 based mingw-w64 release?

[Kai Tietz]

2009/8/31 Wolfgang Glas wolfgang.g...@ev-i.at:
 Hi all,

  We appreciate very much the efforts to bring forward the latest and greatest
 gcc technology to Windows by publishing gcc-4.5 based snapshots ;-)

  However, since our company is developping Windows software we need to rely on
 a stable compiler and hence are quite happy with the gcc-4.4 release series 
 for
 the moment.

  I've noticed that gcc-4.4.1 has been released quite a while ago, so my
 question is whether there are plans to release a mingw-w64-4.4.1 tarball in
 succession to the mingw-w64-4.4.0 tarball. We are really satisfied with the
 4.4.0 release and would like to have the upstream bufixes integrated in the
 stable compiler series at some point in time.

  If there are no plans and/or no resources to prepare such a tarball, I may as
 well contribute one. However, I may need some advice on which components I
 should update.

  Best regards,

    Wolfgang

Hello Wolfgang,

the next version for 4.4 branch, we will release, is 4.4.2 as it has
some major fixes for x64 code. So if you want to use newer version of
gcc, I would recomment not using 4.4.1, and instead 4.4.2 (at the
moment as pre-release available).
Also we plan to do our first stable release of runtime soon. We are
working at the moment hard to finalize some things, like header,
library, and top-level configure, and also to fix remaining issues
found in our header-set. We plan to do this end of September beginning
October this year.

Best regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] delay import support for mingw-w64

[Kai Tietz]

2009/9/10 GCC G++ cplusplu...@gmail.com:
 Since dlltool delay import has been add in the newest binutils-2.20, will
 mingw-w64 people add w64 support to it in the near future?
 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



For 32-bit mingw-w64 already supports delayed load library feature.
For 64-bit some adjustments in dll tool are necessary (the assembly
written there for x64 case isn't correct), but by changing this, it
should work for x64 then, too.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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.

[Kai Tietz]

2009/9/14 Wolfgang Glas wolfgang.g...@ev-i.at:
 Kai Tietz schrieb:
 2009/9/14 Wolfgang Glas wolfgang.g...@ev-i.at:
 JonY schrieb:
 On 9/14/2009 02:46, Wolfgang Glas wrote:
 [snip]
 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:42        18 057 370
 binutils-2.19.90.tar.bz2        2009/09/10 13:58        17 415 613
 binutils-2.20.51.tar.bz2        2009/09/14 07:41        18 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 ?

 to preferred versions of binutils are 2.19.90 and 2.20.x (I assume we
 will release already with 2.20.x)

 i Kai,

  I will then try to augment mingw-w64-gcc-4.4.0-1 with binutils-2.19.90 and
 current CVS's HEAD of mingw-w64-headers. I will then try to build
 omniorb/libxml2/qt-4 and give you feedback of my mileage.

  Does this configuration give you reasonable quality data for you upcoming
 gcc-4.4.2 based release?

  Or should I push binutils to 2.20 and try a shared libstdc++ build?

  Regards,

    Wolfgang


Hi Wolfgang,

Well, better build for 4.4.1 instead. This gives us for i?86 better
information. The x64 build should be done with 4.4.2 (prerelease), as
there were major changes with big impact. As 4.4.2 is nearly stable
(some few issues are pending of not that much impact in comparision to
4.4.1), I would say try it with this version better.

Cheers,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] qt-4.5.2 builds with recent toolchain.

[Kai Tietz]

Hello Wolfgang,

thanks for those two patches. I applied both changes to mingw-w64's trunk.

If you want to contact someone from OpenSuse, you can make contact on
IRC with Fridrich.

Thanks,
Kai

2009/9/18 Wolfgang Glas wolfgang.g...@ev-i.at:
 Hello Kai,

  Now qt-4.5.2 compiles with mingw-w64-src-4.4.1-1 plus your xmmrestore44 
 patch.

  This means, I was unable to reproduce my ICE from yesterday with cleaned up
 interlocked patch. My assumption is, that the compiler is crashing because my
 ubuntu jaunty has huge virtual memory leaks. I encountered mutliple crashes in
 the x86_64 compiler, when doing a 32 and 64 bit build in parallel here on my
 laptop. (Although I have 4G of physical memory and 8G of swap space :-/)

  All the patches I need are in the svn repository browsable at
 http://svn.clazzes.org/svn/mingw-pkg/trunk/mingw-w64-deb

  I have two patches for ming-w64-headers, which are additionally attached to
 this mail.

  One is declaring _fileno even if _POSIX is defined, which is somehow needed 
 by
 qt. The other patch is including the dependant header schemadef.h in 
 tmschema.h
 in lowercase letters (#include schemadef.h instead of 
 #includeSchemaDef.h),
 which is need under Linux, because the files in your source tarball is in
 lowercase, too. (It will run under native Windows, because the filesystem is 
 not
 case-sensitive)

  So, I beg you to apply these two trivial things, so I can build qt-4.5.2 in
 the next turn without patches for mingw-w64-header.

  If all goes well and the binaries produce good results, I will push all the
 packages to our launchpad PPA, which will take a whole day or so, because
 launchpad is not so fast at compiling the stuff. And, yes, the whole toolchain
 takes a long while to compile ;-

  For the patches against Qt and the compiler options I'd like to have a review
 cycle maybe with opensuse mingw-w64 packagers. Do you have an URL/contact of
 these guys?

  Best regards,

    Wolfgang

 For the records, here are the versions of my toolchain:

 # x86_64-pc-mingw32-as -v
 GNU assembler version 2.20.51 (x86_64-pc-mingw32) using BFD version (GNU
 Binutils) 2.20.51.20090910

 # x86_64-pc-mingw32-gcc -v
 Es werden eingebaute Spezifikationen verwendet.
 Ziel: x86_64-pc-mingw32
 Konfiguriert mit: ../configure --target=x86_64-pc-mingw32 --prefix=/usr
 --with-sysroot=/usr/x86_64-pc-mingw32 --datadir=/usr/x86_64-pc-mingw32/share
 --mandir=/usr/x86_64-pc-mingw32/share/man
 --infodir=/usr/x86_64-pc-mingw32/share/info
 Thread-Modell: win32
 gcc-Version 4.4.2 20090910 (prerelease) (GCC)

 # i686-pc-mingw32-as -v
 GNU assembler version 2.20.51 (i686-pc-mingw32) using BFD version (GNU 
 Binutils)
 2.20.51.20090910

 # i686-pc-mingw32-gcc -v
 Es werden eingebaute Spezifikationen verwendet.
 Ziel: i686-pc-mingw32
 Konfiguriert mit: ../configure --target=i686-pc-mingw32 --prefix=/usr
 --with-sysroot=/usr/i686-pc-mingw32 --datadir=/usr/i686-pc-mingw32/share
 --mandir=/usr/i686-pc-mingw32/share/man 
 --infodir=/usr/i686-pc-mingw32/share/info
 Thread-Modell: win32
 gcc-Version 4.4.2 20090910 (prerelease) (GCC)





-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
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] Printf %z format specifier?

[Kai Tietz]

2009/9/20 Ozkan Sezer seze...@gmail.com:
 On Sun, Sep 20, 2009 at 2:55 AM, Erik de Castro Lopo
 mle+...@mega-nerd.com wrote:

 Please note, I am subscribed to the list. No need to CC me on reply.

 Ozkan Sezer wrote:

 A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org
 compiler for your w32 builds?  I think the warning may be a gcc-4.4+
 thing and not actually a mingw-w64 issue, but I don't know for sure.

 Now that I've checked, it seems a little more complicated than I first
 thought.

 The mingw32 compiler that I'm using is the one from the Ubuntu 9.04
 mingw32 package. It reports its version as:

    gcc version 4.2.1-sjlj (mingw32-2)

 This compiler JustWorks(tm) and accepts '%zd in printf/snprintf as well
 as the other C99 format string stuff.


 OK, looked at the mingw.org phovided gcc4.2.1-2 source
 and they add windows specific format specifiers like %I32
 in gcc/config/i386/mingw32.h but with a note like:

 /* MSVCRT supports additional length specifiers for printf.  (In
   fact, it does not support some of the C99 specifiers, like
   ll.  However, we do not presently have a mechanism for disabling
   a specifier.)  */

 4.4 was the version that ms-printf format support officially
 went into gcc along with mechanisms catching what is OK
 and what is not.

 A note out of curiosity: Does your versions compiled by
 gcc  4.4 of mingw.org give correct output ?

 The mingw32 package on Debian Sid is:

    gcc version 4.4.1 (GCC)

 and it too gives a warning on both c99 and gnu99.  For this compiler,
 not even -D__USE_MINGW_ANSI_STDIO=1 can fix it.

 Me, I'd just like to compile the one piece of source code on as many systems
 as possible without hacking it to bits with  #ifdefs. I'd  also like,
 where possible, to get the compiler using apt-get, instead of compling it
 myself.

 Erik
 --
 --
 Erik de Castro Lopo
 http://www.mega-nerd.com/


 --
 Ozkan

 --
 Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
 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


As mingw.org doesn't use any printf formatter rules for their
redirected functions (which is IMHO a bug), they don't get warnings
for anything passed into this functions.
IMHO as more as I think about this feature, it should be turned on on
user demand by defining __USE_MINGW_ANSI_STDIO explicit. To turn it on
for some cX9 standards, or for __GNU_SOURCE, etc is misleading and a
mis-concept. We can automatically turn it on, if _POSIX is defined,
but the rest is just buggy.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
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] WIA UUIDs for mingw-w64-crt.

[Kai Tietz]

Hello Wolfgang,

2009/10/3 Wolfgang Glas wolfgang.g...@ev-i.at:
 Hi all,

  We have recently compiled a Win32-app using mingw-w64, which uses the WIA
 (Windows Image Acquisition) API. The headder files in mingw-w64-headers are 
 fine
 and the app compiled without any flaws.

  However, UUIDs for the WIA interfaces et al. are missing in lbuuid.a, so we
 gathered them and made an addition to libuuid.a

  So, I'd like the attached source file to be integrated in 
 mingw-w64-crt/libsrc
 (don't forget to add the file to Makefile.am...).

  TIA, Wolfgang

Thanks for the patch. Some of those GUIDs are missing, so we are glad
about any updates here.

I applied it to trunk and branch at revision1445  1446.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
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] pseudo-reloc2 test cases

[Kai Tietz]

Hello Chuck,

2009/10/2 Charles Wilson cwils...@users.sourceforge.net:
 Kai --

 As your pseudo-reloc-v2 support has been integrated into the (32bit)
 mingw runtime, I'd also like to add it to the cygwin runtime. However,
 to do this I need some test cases demonstrating where v2 works and v1
 doesn't.

 I assume that, while developing the code for v2, you had some
 quick-n-dirty test cases for that. If so, and they are not already
 publicly available -- then if you're willing to make them public, I'd
 appreciate a pointer to them.  They don't need to be production ready;
 just whatever you were using during development would be helpful.

 Thanks,
 Chuck

I have to search my testcases. If I find some specific I used for
testing new pseudo-relocation, I'll add them to our crt's testcase
folder and give you a hint.

Kai

PS: This list needs subscription, so next time please subscribe before posting.

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
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] WIA UUIDs for mingw-w64-crt.

[Kai Tietz]

Hello Wolfgang,

2009/10/4 Wolfgang Glas wolfgang.g...@ev-i.at:
 Hello Kia,

  Thanks for applying ;-)

  I found some time to think about the remaining problems, which you were 
 unable
 to push upstream like float.h, stddef.h header clash between mingw-w64-crt and
 gcc or making -mms-bitfields default. IMHO I would be best to maintain a small
 set of patches to gcc, which should be applied to a gcc tarball before 
 building.

  This solution is not very elegant, but it might help to convince the gcc
 developers, that a patch, which is useful to many users should be applied to 
 the
 mainline dispite all concerns...

To prepare such a patch and provide it as optional could be a way to
solve this. But the experience has shown that such patches don't
getting applied to mainline. So I have here some concerns about such a
approach.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Redefintion of popen

[Kai Tietz]

Hello,

2009/10/22 Sisyphus sisyph...@optusnet.com.au:
 Hi,
 The test script (try.c):

 ###
 C:\_32\Ctype try.c
 #include stdio.h

 int main(void) {

 #ifdef NO_OLDNAMES
 printf(\NO_OLDNAMES\ defined\n);
 #else
 printf(\NO_OLDNAMES\ not defined\n);
 #endif

 #define popen 1

 printf(%d\n, popen);

 return 0;

 }


 C:\_32\C
 ###

 Irrespective of whether I compile that script with mingw32 (either 3.4.5 or
 4.4.0) or mingw64 (4.5.0), the executable outputs the same:

 ###
 C:\_32\Ctry
 NO_OLDNAMES not defined
 1

 C:\_32\C
 ###

 No problem with that ... what puzzles me is that, while the script compiles
 silently with mingw32 (even with '-pedantic -Wall') when I compile with
 mingw64 I get a warning about popen being redefined:

 ###
 C:\_32\Cx86_64-w64-mingw32-gcc -o try.exe try.c
 try.c: In function 'main':
 try.c:12:0: warning: popen redefined
 c:/_64/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/stdio.h:213:0: note:
 this is the location of the previous definition
Well, I am not sure why we used here define instead of prototyping.
IIRC it had something to do with previous defined popen, but I think I
can solve this better here.

 C:\_32\C
 ###

 Why the difference ? (It's not so much a question of Why do I get that
 warning with mingw64 ? ... rather, what puzzles me is Why *don't* I get
 that warning with mingw32 ?.)
Well you would get a error by mingw.org, if you would define popen
before including headers.

 The relevant section of mingw64's stdio.h is:

 212: #if !defined(NO_OLDNAMES)  !defined(popen)
 213: #define popen      _popen
 214: #define pclose     _pclose
 215: #endif

 With mingw32's stdio.h, we have:

 #ifndef NO_OLDNAMES
 _CRTIMP FILE* __cdecl __MINGW_NOTHROW popen (const char*, const char*);
 _CRTIMP int __cdecl __MINGW_NOTHROW pclose (FILE*);
 #endif

 Is the redefinition not taking place with mingw32 ? ... or is it just that
 no warning is being produced ?
 (I'm currently looking at __MINGW_NOTHROW and wondering what it does.)

 Does anyone have info on what NO_OLDNAMES is about, and/or the
 ramifications of explicitly defining it ?

NO_OLDNAMES is an option to hide old API, which is deprecated by MS.
These are mainly POSIX function names.

 When building perl with mingw64, I'm getting lots of warnings about popen
 and pclose being redefined  - and I'd like a good way of getting rid of
 them. (I also get the same warnings when building perl modules, as popen and
 pclose are defined in perl's XSUB.h.)

 See below for the respective 'gcc -v' outputs.

 Cheers,
 Rob


Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] 64-bit printf question...

[Kai Tietz]

Hello David,

2009/10/25 David Cleaver wrai...@morpheus.net:
 Hello,

 I'm having problems printing out values that are larger than 32 bits.  My 
 usual
 printf using %llu only outputs the lower 32 bits of my 64-bit numbers.

 Here's an example program that produces incorrect output.

 #include stdio.h

 typedef unsigned long long u64_t;

 int main(int argc, char* argv[])
 {
   u64_t y=6981463658333LL;
   printf(y=%llu\n, y);
   printf(y=%PRIu64\n, y);
   printf(y=%qd\n, y);
   printf(y=%x\n, y);
   return 0;
 }

 Here is the output I get.
 y=2141802333
 y=PRIu64
 y=qd
 y=7fa94f5d

 Can anyone see what I'm doing wrong?  What is the proper way to output 64-bit
 numbers?  I'm using mingw-w64-bin_i686-mingw_20091025.zip for my development
 environment and I've called the compiler like:
 x86_64-w64-mingw32-gcc.exe -o test.exe test.c

 Thanks for any help.

 -David C.

The reason for this is the msvcrt you are using. The %ll width
specifier is support by MS until msvcrt based on msvcr80.dll. The
common width specifier, which works also for older msvcrt.dll
versions, is %I64.
If you want to use POSIX like printf formatters, like %ll or %Lg,
then you should use our POSIX emulation version for it. You need just
to define by command line, or before including the first header file,
the macro __USE_MINGW_ANSI_STDIO with value one.

For the example you gave it would look like that

#define __USE_MINGW_ANSI_STDIO 1
#include stdio.h

typedef unsigned long long u64_t;

int main(int argc, char* argv[])
{
  u64_t y=6981463658333LL;
  printf(y=%llu\n, y);
  printf(y=%PRIu64\n, y);
  printf(y=%qd\n, y);
  printf(y=%x\n, y);
  return 0;
}

I hope I could help you by this.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] delay import support for mingw-w64

[Kai Tietz]

2009/10/26 NightStrike nightstr...@gmail.com:
 On Thu, Sep 10, 2009 at 3:40 AM, Kai Tietz ktiet...@googlemail.com wrote:
 2009/9/10 GCC G++ cplusplu...@gmail.com:
 Since dlltool delay import has been add in the newest binutils-2.20, will
 mingw-w64 people add w64 support to it in the near future?
 Thanks.

 For 32-bit mingw-w64 already supports delayed load library feature.
 For 64-bit some adjustments in dll tool are necessary (the assembly
 written there for x64 case isn't correct), but by changing this, it
 should work for x64 then, too.

 Is there a patch already for this?


No, I have at the moment more important features to do. But it is on
my pile for things to do.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Another compilation problem binutils... after updated the mingw-w64-headers to svn-trunk

[Kai Tietz]

2009/11/2 Ozkan Sezer seze...@gmail.com:
 On Mon, Nov 2, 2009 at 11:49 AM, t66...@gmail.com t66...@gmail.com wrote:
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c: In function
 '_getopt_internal':
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:683: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:708: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:713: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:731: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:760: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:764: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:790: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:793: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:823: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:870: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:888: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:904: error: called
 object '1' is not a function
 /home/slack/gcc/binutils-cvs/libiberty/getopt.c:953: error: called
 object '1' is not a function
 make[3]: *** [getopt.o] Error 1

 Hi
 I have no idea what is happening with the w64-headers it seems to be
 unable to compile binutils target=x86_64-w64-mingw32 the
 mingw-w64-headers from 101009 worked Ok.
 Anyone got a solution ? Or idea of which commit caused the breakage?
 Thanks.

 Is this problem reproducible with revision 1508 of the
 headers?

 --
 Ozkan

 --
 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


This issue is related to the definition in _mingw_mac.h of a temporary
_ as 1. If you add here before the pop_macro call an '#undef _' (we
did this already on our trees), does it helps?

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Missing http.h::_HTTP_DATA_CHUNK_TYPE::HttpDataChunkFromFragmentCacheEx

[Kai Tietz]

2009/12/22 Alon Bar-Lev alon.bar...@gmail.com:
 Thanks!

 When are you going to publish a new snapshot?
 Current snapshot is mingw-w64-snapshot-20090419.tar.bz2 and is it very old.

 Vapier, the lord of toolchain in Gentoo, recently added out-of-the-box
 support for mingw64... However he will only use formal snapshots for
 the runtime.

 Can you please consider to publish a more up-to-date snapshot?

 Thanks!


Hello,

Sorry for being that lazy. I updated the svn snapshots on our download
page. We provide additional source balls for toolchain build, but
those aren't svn snapshots.

You can find two different versions of source snapshots. One is our
current trunk version and the second is the snapshot of our v1.0
release branch.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] __attribute__((format(printf,....)) issue

[Kai Tietz]

2009/12/22 Alon Bar-Lev alon.bar...@gmail.com:
 #define _POSIX
 #include stdio.h

 int my_printf(char *format, ...) __attribute__((format(printf,1,2)));

 int main(void) {
        return 0;
 }

 $ x86_64-w64-mingw32-gcc -pedantic a.c
 a.c:4: warning: ‘__mingw_printf’ is an unrecognized format function type

This is reasoned by the definition of _POSIX. In this case printf gets
redefined to __mingw_printf, which is used later in your formatter
 ((format (printf, 1,2))) ...
Use instead of printf in formatter the __printf__ keyword, this fixes
your problem.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Compiling win32 compiler fails

[Kai Tietz]

2009/12/22 Alon Bar-Lev alon.bar...@gmail.com:
 On Tue, Dec 22, 2009 at 9:53 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2009/12/22 Alon Bar-Lev alon.bar...@gmail.com:
 Hi,

 I think that i686-w64-mingw32 should be supported, right?
 At least it would be great if it is as this project is much more
 maintained and complete than mingw32.

 While trying to do so, I get the following... And indeed the
 declaration is duplicated.
 I tested both v1.0 and trunk snapshots, gcc is 4.4.2.

 x86_64-w64-mingw32 compiles OK.

 /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
 error: conflicting types for ‘_mm_shuffle_ps’
 /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note:
 previous definition of ‘_mm_shuffle_ps’ was here
 make[1]: *** [intrincs/lib32_libmingwex_a-readfsword.o] Error 1
 make[1]: *** Waiting for unfinished jobs
 In file included from intrincs/readfsbyte.c:1:
 /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
 error: conflicting types for ‘_mm_shuffle_ps’
 /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note:
 previous definition of ‘_mm_shuffle_ps’ was here
 make[1]: *** [intrincs/lib32_libmingwex_a-readfsbyte.o] Error 1
 In file included from intrincs/readfsdword.c:1:
 /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585:
 error: conflicting types for ‘_mm_shuffle_ps’
 /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note:
 previous definition of ‘_mm_shuffle_ps’ was here
 make[1]: *** [intrincs/lib32_libmingwex_a-readfsdword.o] Error 1
 make[1]: Leaving directory
 `/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/trunk/mingw-w64-crt'
 make: *** [all] Error 2

 --
 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


 Yes, i686 should be supported and I am curious about this warning, but
 well, you are using 4.4.2 gcc.
 I'll try to find out where this issue comes from and then prepare a
 fix for this.

 Cheers,
 Kai

 Which gcc should I use?


Well, 4.4.2 isn't bad. But the upcoming 4.4.3 has some bug-fixes maybe
worth to have.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Compiling win32 compiler fails

[Kai Tietz]

2009/12/23 Alon Bar-Lev alon.bar...@gmail.com:
 OK.
 Thanks.

 I had to fixup the gendef...

 1. You check for gnu compliant malloc but not define the rpl_malloc,
 so I removed this check.
 2. You treat warnings as errors and do not eliminate unused parameters.

Thanks for reporting this warning. I committed an altered version
(some additional parameter checks, which don't hurt here).

The change about malloc isn't used AFAICS, but well I want to keep it,
as we plan to improve the conditional header includes in future.
Does this line leads to an build error for you?

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] problems with dllimport / dllexport

[Kai Tietz]

2009/12/23 Chris Sutcliffe ir0nh...@gmail.com:
 Hi Kai,

 I didn't noticed this change in behavior. Could you provide to me some
 small testcase by which I can reproduce this?

 I'll create a simple test case over the holidays.  As it stands today,
 I see it with my Emerge Desktop application, but it by no means is a
 simple test case.

 The only thing you should be aware is, that by using shared C++ you
 get linker warnings about autoimports, when you didn't specified
 --enable-autoimports for linker. Did it helps if you specify option
 -static?

 I see the C++ import warnings, and as you mentioned I addressed them
 by adding -Wl,--enable-auto-import but it did not help the problem of
 undefined references that I'm seeing.  The issue is actually the
 classes being export by Emerge Desktop's shared libraries, for
 example:

 ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0xef):
 undefined reference to `_imp___ZN16BasePositionPageD1Ev'
 ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x11f):
 undefined reference to `_imp___ZN12SchemeEditorD1Ev'
 ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x882):
 undefined reference to
 `_imp___ZN16BasePositionPageC1ENSt3tr110shared_ptrI12BaseSettingsEEj'
 ../.objs64/Release/emergeTasks/Config.o:Config.cpp:(.text+0x90b):
 undefined reference to `_imp___ZN12SchemeEditorC1EP6HWND__'

 Where BasePositionPage, SchemeEditor and BaseSettings are exported
 classes from Emerge Desktop's shared libraries.

 Hrm  interestingly enough, all the undefined references I'm seeing
 are from exported classes, exported functions seem to be fine.
 Perhaps this is an issue with dllexport / dllimport and C++ classes?

 Cheers!

 Chris

 --
 Chris Sutcliffe
 http://emergedesktop.org

 --
 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


Ah, as you describe this, I am remembering, that there is a patch for
C++ FE pending (it is a bug), that the namespace should be able to
contain the dllexport/dllimport here.
So this issue is most likely related to this. Maybe generate your
import-library by using export-all? Does this help?

Cheers,
Kai

PS: Somehow it looks like that mingw.org has no real interest in
fixing the mingwm10.dll issue. But well, I tried to help.


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Compiling win32 compiler fails

[Kai Tietz]

2009/12/23 Alon Bar-Lev alon.bar...@gmail.com:
 Great!
 It works.

Thanks for testing. I will apply it to v1.0 branch and trunk.

 But... Why there is a huge difference between lib64 and lib32 libraries?
 I see that lib32 contains only 142 libraries while lib64 contains 2042.

 For example libpdh is missing in lib32.

Well, for 64-bit we generated those import libraries by gendef tool.
For 32-bit we took as initial set the .def files from mingw.org (we
extended already some of them). So if you want to have specific import
libraries generated, feel free to use our gendef tool on this DLL and
review if the imports described are matching. If you want to provide
your generated .def file(s) and that it becomes part of default crt
build, be welcome to post the .def file for x86.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Compiling win32 compiler fails

[Kai Tietz]

2009/12/23 Alon Bar-Lev alon.bar...@gmail.com:
 On Wed, Dec 23, 2009 at 3:03 PM, Kai Tietz ktiet...@googlemail.com wrote:
 The change about malloc isn't used AFAICS, but well I want to keep it,
 as we plan to improve the conditional header includes in future.
 Does this line leads to an build error for you?

 Yes... It is needed.
 Once the autoconf detects that gnu malloc is not available, it place
 #define malloc rpl_malloc in config.h.
 You do not have rpl_malloc in sources so linkage fail.

 Alon.


Ok fixed. Thanks for the explaination.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Compiling win32 compiler fails

[Kai Tietz]

2009/12/24 Alon Bar-Lev alon.bar...@gmail.com:
 On Thu, Dec 24, 2009 at 9:22 AM, Kai Tietz ktiet...@googlemail.com wrote:
 Ok, I see. I added to the comment that this just happens on
 cross-compile. Btw gendef should work as native build on linux, too.
 There shouldn't be any dependencies to Windows specific runtime.

 Almost true... :)
 Attached a patch.


Hello Alon,

thanks for the patch. I've applied it at revision 1683 with ChangeLog entry

2009-12-24  Alon Bar-Lev  alon.bar...@gmail.com

* Makefile.am (gendef_SOURCES): Add src/compat_string.c file.
* configure.ac (AC_CHECK_FUNCS): Check for strlwr.
* src/compat-string.h: New header.
* sre/compat_string.c: New source-file.
* Makefile.in: Regenerated.
* config.h.in: Likewise.
* configure: Likewise.

Is this ok for you?

Cheers,
Kai



-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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

[Kai Tietz]

2010/1/8 Chris Sutcliffe ir0nh...@gmail.com:
 Hi Kai,

 yes this bug I encounter some time ago, too. It is related to DLL files
 not having any debugging information but are shown in backtrace. Here it
 warns once about psymtab != symtab and code in gdb fix it afterwards. IMHO
 this warning is simply pretty bogus here, or the DLL loader should
 generate for pe-coff the symtab, too.

 Do you mind if I share your findings on the GDB mailing list so as to
 help Tristan Gingold track down what's causing these spurious warnings
 to pop-up?

 Chris

Of course. You can quote me on gdb's ML.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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?

[Kai Tietz]

JonY jo...@users.sourceforge.net wrote on 19.01.2010 12:16:50:

 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.

Correct, at least for 64-bit (and also for 32-bit as long as crt-headers 
and runtime aren't exchanged, too) there is no chance to use w32api 
headers at their current state.

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

For 32-bit you can use mingw.org build libraries and DLL binaries with 
mingw-w32, too. But you have to be aware that at some points (TLS handling 
for example) you will loose some features.

Regards,
Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.


--
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] Are win64 headers the same as win32 headers?

[Kai Tietz]

2010/1/20 Zuxy Meng zuxy.m...@gmail.com:
 Hi,

 Kai Tietz kai.ti...@onevision.com 写入消息
 news:ofc6e14420.44e4a37d-onc12576b0.003eae4c-c12576b0.003ee...@onevision.de...
 JonY jo...@users.sourceforge.net wrote on
 19.01.2010 12:16:50:

 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.

 Correct, at least for 64-bit (and also for 32-bit as long as crt-headers
 and runtime aren't exchanged, too) there is no chance to use w32api
 headers at their current state.

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

 For 32-bit you can use mingw.org build libraries and DLL binaries with
 mingw-w32, too. But you have to be aware that at some points (TLS handling
 for example) you will loose some features.


 Thanks to everybody for your prompt responses! So I'd better regard mingw64
 as a replacement of instead of a complement to mingw32. But what about MSYS?
 Can I use 32 bit MSYS binaries with mingw64? My major interest is to port
 GNU programs to Win64 so a shell that supports configure etc is needed.

Zuxy,

you can use MSYS as build-environment. This works pretty well for some
doing this. In fact you can use also linux, cygwin, etc as
cross-compiling host for win64/win32 developlement. The advantage of
msys/cygwin is, that you can directly execute and test your
applications on a 64-bit host. For cygwin you are even able to run
testsuite for 64-bit windows. The later point is the reason why I
stick to cygwin as developement environment.

Kai



-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] gcc-4.4 branch svn failed to compile

[Kai Tietz]

2010/1/25 Ozkan Sezer seze...@gmail.com:
 On Mon, Jan 25, 2010 at 9:55 AM, t66...@gmail.com t66...@gmail.com wrote:
 Hello:

 Anyone have build issues with current gcc-4.4 branch ?
 x86_64-w64-mingw32/include/wincrypt.h:1512: error: expected
 specifier-qualifier-list before 'CERT_DATA_BLOB'
 make[4]: *** [_muldi3.o] Error 1


 it doesn't know CERT_DATA_BLOB. Nightstrike's
 revision 1784 is to blame.

 --
 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


Problem was fixed on trunk by Mook some hours ago. Thanks for reporting.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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()

[Kai Tietz]

2010/1/26 Chris Spencer spence...@googlemail.com:
 -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 ws2tcpip.h
 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?

Well, the symbol is part of the import-libary libws2_32.a. For me it
works to link, but I assume you are using an older version of our
runtime headers and crt, which could be the underlying issue. In our
trunk version we moved those function out exactly for this reason as
the inline versions can make troubles.
For fixing you issue, I would suggest to update mingw-w64 headers/crt,
or to take function gai_strerrorA and put it directly into your source
(of course without the WS2TCPIP_INLINE).

Regards,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] cross compiler uses 32 bits long type and cannot be changed into 64 bits

[Kai Tietz]

2010/2/25 Simon de Graaf s.degr...@tudelft.nl:
 Hello,

 I am working under opensuse and cross compiling for 64 bits Windows.
 I cannot compile the gmp library because mp_limb_t is 32 bits, because of
 the 32 bit long type.  I have tried to use the -m64 option but it does
 not work.
the variant provide in our source packages if for building of gcc only
(along with mpfrr and mpc). We use in-tree build here.
 Why can a long integer not be set to 64 bits?
 I have used the binary package from source froge.
 Must i maybe download the source package and compile to cross-compiler
 myself
 to get this behaviour?

Well, the size of type 'long' we can change here. It is part of MS
decission of ABI. For native win32 world, the type 'long' is 32-bit
wide. Therefore for 64-bit Windows, you have to use 'long long' type
to have the scalar width of a pointer. But in general it is better to
use intptr_t/uintptr_t types for any platform you are programming for,
as those types abstract this issue in a standarized way.

Regards,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Download Intel#174; 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] __int64 issue of compatibility with MSVC

[Kai Tietz]

2010/3/7 Doug Semler dougsem...@gmail.com:
 On Thu, 04 Mar 2010 17:20:07 Jim Michaels wrote:
 in MSVC,
 __int64 x=12345678901234567i64;

 point 1: this type __int64 doesn't require me to #include windows to
 define it.  in mingw and mingw-w64, one must #include basetsd.h. why?

 point 2: there are also __int32 __int16 and __int8 types.

 If I remember correctly, anything that starts with two underscores is
 implementation defined, which means that __int64 is MS compiler specific, so
 including a separate header would make sense to pick it up in mingw

 Since this is a compiler specific (not really mingw but gcc), it makes sense 
 to
 me, in fact IIRC, MSDN specifically states Microsoft Visual C Specific for
 those types.  If you need to be able to compile under multiple compilers, I
 would say grab a MS version of stdint.h (since MSVC doesn't have that) and
 #include that, and use the types from there (such as int64_t, int32_t, etc).
 If you just need a type that is at least 64 bits I believe MSVC from 6.0 on
 supports long long and unsigned long long (at least 64 but could be
 longer)

Right, keywords/symbols with two leading underscores are extensions.
The support of '__int8, __int16, __int32, __int64, and __int128' are
builtin types. As the are combinable by 'signed/unsigned' they can be
handled by typedefs. So we use for them at the moment defines in our
headers, but of course this is just a work-a-round. The type __int128
will be added to gcc's version 4.6 (a patch for it is already posted
but needs review). I would like to have those other extension types
supported by VC, too, but well, as those types aren't part of any
C-specification, it is a bit hard to put them into gcc.

The digit post-fixes 'i32,i64,i128, etc' are alse MS specific
extensions (AFAIR long long type was introduced by MS beginning from
VC 2005). It would be possible to add these to gcc (in fact it is
mainly preprocessor feature), but again here is again the question, if
this fits into any specific standards gcc wants to support.


 point 3: mingw does not utilize the i64 constant thingy (whatever it's
 called) that tells the compiler that this number is of __int64 type.  I do
 not know if there is an i32 or i16 or i8 definition.

 That's another GCC, not mingw thing.  GCC supports the suffix of LL and ULL 
 for
 64 bit wide numbers.  MSVC from at least visual studio 2003 (maybe, but don't
 quote me, VC6) also supports these...



 BTW, 128-bit number type is in the C9X standard.  the new integral data
 types in C++ will be something like int64, int32, int128, int16, int8.

 http://www.open-std.org/JTC1/sc22/wg14/www/docs/n615.htm


 C9X support in MSVC is flaky at best and nonexistent in several spots (see:
 stdint.h).  I mean the standard has been ratified since what, 2004?  even VS
 2008 doesn't have it!)

 --
 Download Intel#174; 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



Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Download Intel#174; 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

[Kai Tietz]

2010/3/21 Ozkan Sezer seze...@gmail.com:
 On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote:
 Well, this is a problem, yes.  It only affects the multilib builds,
 though, which don't really work anyway without a lot of effort.  And
 this will all be fixed for 4.6, o we won't need to worry about it.

 If users really want it, though, I can rework things to exclude 32-bit
 entirely.  It's just a little messy in Makefile.am.

 On Sun, Mar 21, 2010 at 12:24 PM, Doug Semler dougsem...@gmail.com wrote:
 Quick question:

 Are you sure you want to disable the leading underscore on the 32bit side 
 with
 the --disable-leading-underscore and multilib?  Looking at it (without 
 testing
 it, that is), it doesn't seem to me that it is appropriate...

 I think the flag really should be added to the lib64
 versions in the makefiles. Otherwise things would
 go far messier the may think of.

I agree, that it maybe gets for x86 much messier. And if possible, it
would be better to have this underscoring just active for x64.

 Besides that, there really is no way to tell the user
 as to how the crt was actually compiled. If there
 were a config header installed from within the crt
 build, maybe..

Hmm, for what this header should be? I see the issue that an user
can't see directly by which option for underscoring the crt was built,
but for this a header makes also no sense. To detect this a call of nm
reveals, if underscoring was active or not.
I don't think that we should introduce for this something in
configure. The header itself aren't affected, as they are checking the
underscoring mode of gcc directly.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Download Intel#174; 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

[Kai Tietz]

2010/3/21 Doug Semler dougsem...@gmail.com:
 On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote:
 2010/3/21 Ozkan Sezer seze...@gmail.com:
  On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com
 wrote:
  Well, this is a problem, yes.  It only affects the multilib builds,
  though, which don't really work anyway without a lot of effort.  And
  this will all be fixed for 4.6, o we won't need to worry about it.
 
  If users really want it, though, I can rework things to exclude 32-bit
  entirely.  It's just a little messy in Makefile.am.
 
  On Sun, Mar 21, 2010 at 12:24 PM, Doug Semler dougsem...@gmail.com
 wrote:
  Quick question:
 
  Are you sure you want to disable the leading underscore on the 32bit
  side with the --disable-leading-underscore and multilib?  Looking at
  it (without testing it, that is), it doesn't seem to me that it is
  appropriate...
 
  I think the flag really should be added to the lib64
  versions in the makefiles. Otherwise things would
  go far messier the may think of.

 I agree, that it maybe gets for x86 much messier. And if possible, it
 would be better to have this underscoring just active for x64.

  Besides that, there really is no way to tell the user
  as to how the crt was actually compiled. If there
  were a config header installed from within the crt
  build, maybe..

 Hmm, for what this header should be? I see the issue that an user
 can't see directly by which option for underscoring the crt was built,
 but for this a header makes also no sense. To detect this a call of nm
 reveals, if underscoring was active or not.
 I don't think that we should introduce for this something in
 configure. The header itself aren't affected, as they are checking the
 underscoring mode of gcc directly.

 It actually gets even messier.  Currently, the ld in binutils assumes that x64
 should always have underscores, which means that import and export symbols
 libraries are generated incorrectly from there.  There's no way currently to
 configure at compile time or pass at runtime this flag to ld (unlike dlltool
 which at least has this).  Nor is there a way to pass the flag from the gcc
 driver to the linker.

Yes, ld is at the moment the app not supporting options for overriding
underscore mode. The sad thing about ld is that is uses hardcoded
values in script-templates instead of using the target default. By
this issue in design it is much work to allow such an option. The last
patches I did for this were stopped at the point (but patch is now in
bfd) to have an bfd API to query undescoring mode by internal
bfd-name. I didn't continued on this reasoned by lack of time.

 I have patched ld (and the binutils configury) to accept a configure time
 parameter for default behavior, as well as adding a parameter to override the
 behavior from ld (which is more important).  I am still waiting for copyright
 assignment paperwork from the FSF before I submit it for comment to the
 binutils list (not sure that this patch would be accepted though).

I think there is in general a good chance for this. And the necessary
change for gcc 4.6 (which is pretty small one) I'll approve as soon as
issue in binutils are solved.

 This is in addition to the other two patches I have in my own pipeline with
 respect to the library long names (NULL terminated in PE-COFF) and the
 parameter to make ld import libraries generate the same archive member file
 name so that they can be picked up by the native linker (and I probably should
 figure a good way to patch dlltool to do this as well, but it uses a different
 method of generating import libraries...)

Yeah, dlltool uses here gas to generate the import-library. IMHO it
should support the same generation mechanism without gas (like ld),
too. And this should get default. By this the initial idea is to move
the import-library generation code into bfd's coff code. So we could
avoid double implementation.
Additionally it would allow to support in future the ANON-object file
format version 0 (new import descriptor), too.

Kai



-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Download Intel#174; 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] Include paths, float.h

[Kai Tietz]

2010/3/22 Doug Semler dougsem...@gmail.com:
 On Sun, Mar 21, 2010 at 8:51 PM, NightStrike nightstr...@gmail.com wrote:
 On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler dougsem...@gmail.com wrote:
 On Sun, 21 Mar 2010 19:22:48 NightStrike wrote:
 On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer seze...@gmail.com wrote:
  For some reason yet unknown to me, the gcc-provided headers
  have priority over the system provided headers and float.h is
  especially problematic: Not installing or deleting it is the solution,
  at least for now.

 If gcc headers didn't take priority, then fixincludes wouldn't work.

 The real question is why gcc forces changes to system headers instead
 of working with system headers.


 Does gcc even necessarily have the system headers available to it on a clean
 system during a build?   I don't think so...which means that gcc may not 
 know
 about the system headers when it runs through the stage of installation...

 In other words, for it to even work with the system headers, the system
 headers have to be installed correctly before you do the first make 
 install-gcc
 during a bootstrap...

 (and I know the one howto build doc says install the headers first, but
 unfortunately building the toolchain does not fail if you do NOT do this...)


 Building the toolchain does in fact fail.  Just, not at the all-gcc
 stage (the bootstrapping stage).  Do a make all-gcc.  When it
 finishes, do make all.  It'll die immediately asking for a valid
 sysroot.


 No, what I meant is that you don't have to go in the order specified
 in the how-to-build if you don't build a sysroot configuration (you do
 if you build a sysroot configuration).  In other words, the system
 includes do not (strictly) have to be available until the target
 library phase when building non sysrooted...which means that even *IF*
 fixincludes were to be run on the mingw target (which it doesn't look
 like it is, by the way) and told to pick up the system headers during
 the build-gcc phase, it may not necessarily do so.  It's how I (used
 to) build the toolchain in tree with no mulitilib and a couple other
 tweaks (yes, it is possible).  I don't personally like the sysroot
 option myself, especially because it insists that it wants to be in
 sysroot/mingw/include (why?!?!)...But that still doesn't fix this
 little issue

 The whole sysroot/build-sysroot/fixincludes logic is, in the words of
 the Unfrozen Caveman Lawyer, Frightening and Confusing :)

 Oh, by the way, stdarg.h suffers the same problem in that it uses
 gcc's version and doesn't pick up mingw's version...

Yeah, float.h, stdarg.h, and stddef.h having the same issue. And btw
mm_malloc.h is badly incompatible to VC's definition. Additionally
there are some (horrible) issues about *intrin.h of gcc and it is
therefore strictly recommented to use our intrin.h to fix those
issues.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Download Intel#174; 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] static vs dynamic loading of libgfortran/libstdc++ etc

[Kai Tietz]

Hello Brian,

2010/3/23 Prof Brian Ripley rip...@stats.ox.ac.uk:
 The R project (http://www.r-project.org) has been building under
 MinGW-w64 since mid-January. We have ca 2500 extension packages, ca
 800 of which contain DLLs in C/C++/Fortran/more-than-one-of-those.

 In those couple of months the snapshots (at least the i686-mingw ones)
 have gone from dynamic loading of libgfortran/libstdc++ to static
 loading and back again.  Was this intentional?  We can cope with
 either (but prefer static) but with several hundred DLLs to check and
 an automated build process we could use some consistency -- we have
 already tens and soon to be hundreds of developers who will download a
 snapshot and work on their own extension package.

This switching in behavior is most likely reasoned by seeing the v1.0
builds and our automated 4.5 gcc builds as the same. Shared libstdc++
(and gfortran) are new features of 4.5 gcc, and v1.0 based builds are
using 4.4.x gcc version.
To prevent using shared version you can specify option '-static'.

 We do realize MinGW-w64 is a 'work in progress' project based on
 unreleased versions of GCC.  But as we are about to commit to
 production use on a quite large scale, it would be helpful at least to
 know the plans so we can write future-proof documentation for the
 would-be users (where 'future' means 6 months until the next
 documentation release).

Our intention is to support for toolchain the latest three versions.
That means, current head version (bleeding edge), and the latest
releases of the two prior gcc version. We use in general binutils head
for all of our builds.
We have at the moment two branches. The v1.0 branch, which is our
release branch, and trunk/.
At the moment we plan to switch to MS-ABI in name decoration, which is
a long outstanding - but very necessary - step to provide some
inter-operability to VC generated static libraries.
Additional we plan to replace complex math part of crt by our own
version (we are using at the moment the implementation mingw.org
originated by Danny Smith), which has some problems in respect to
ISO-C99 expected results reasoned signness.

Regards,
Kai Tietz

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Download Intel#174; 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] Include paths, float.h

[Kai Tietz]

2010/3/23 Ozkan Sezer seze...@gmail.com:
 On Tue, Mar 23, 2010 at 2:17 PM, NightStrike nightstr...@gmail.com wrote:
 On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/3/23 NightStrike nightstr...@gmail.com:
 On Tue, Mar 23, 2010 at 12:57 AM, Mook
 mookgcc+sf.mingw-w64-pub...@gmail.com wrote:
 On Sun, Mar 21, 2010 at 4:22 PM, NightStrike nightstr...@gmail.com 
 wrote:
 On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer seze...@gmail.com wrote:
 For some reason yet unknown to me, the gcc-provided headers
 have priority over the system provided headers and float.h is
 especially problematic: Not installing or deleting it is the solution,
 at least for now.

 If gcc headers didn't take priority, then fixincludes wouldn't work.

 The real question is why gcc forces changes to system headers instead
 of working with system headers.

 FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't
 been able to come up with a patch that I don't hate yet.  If something
 can be done, it would probably involve defining INCLUDE_DEFAULTS in
 config/i386/mingw-w64.h somehow, but the temporary workaround I have
 (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot
 prefix builds, so that's not useful.

 Mostly sending this just so the mailing list archive can help remember
 this for me ;)

 [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44

 --
 Mook


 The real fix is to sync what gcc wants with what we have, with
 appropriate changes on both sides.

 --
 Download Intel#174; 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


 We (Ozkan and I) already tried to push necessary changes to gcc. But
 well, people love their POSIX stuff and dislike even an include next
 here. Problem is also that mingw.org don't provide those headers in
 their CRT at all, so a change here as to be runtime-specific, which
 messes things a bit (include of _mingw.h and checking for runtime).
 Best solution is (as work-around) to remove those headers from gcc's
 /lib/gcc/target/version/include directory

 That's hardly best.  We need to try again, and get GCC to listen.

 I don't care about mingw.org... we can do something vendor-specific
 for that.  But I do care about having GCC do a fixincludes on our

 My first suggestion *was* vendor specific which disabled
 those three headers' installation by gcc:
 http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html
 The thread went some time and then get lost, feel free
 to revive it if you want. The solution in that initial post above
 is what I already use in my personal builds and it works.

 headers, that we then revert.  That's just plain stupid.

 Who's the GCC maintainer that we need to hit over the head?

 --
 Ozkan


It is the use of USER, right? This is fine at the moment, but I
dislike it as we then have to maintain changes of gcc within our
headers. What's about using fixinclude here? See gcc's bug-tracker
40722 item, where HJ uses this to fix _rotl/_rolr issue.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Download Intel#174; 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] Include paths, float.h

[Kai Tietz]

2010/3/23 Ozkan Sezer seze...@gmail.com:
 On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/3/23 Ozkan Sezer seze...@gmail.com:
 On Tue, Mar 23, 2010 at 2:17 PM, NightStrike nightstr...@gmail.com wrote:
 On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/3/23 NightStrike nightstr...@gmail.com:
 On Tue, Mar 23, 2010 at 12:57 AM, Mook
 mookgcc+sf.mingw-w64-pub...@gmail.com wrote:
 On Sun, Mar 21, 2010 at 4:22 PM, NightStrike nightstr...@gmail.com 
 wrote:
 On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer seze...@gmail.com wrote:
 For some reason yet unknown to me, the gcc-provided headers
 have priority over the system provided headers and float.h is
 especially problematic: Not installing or deleting it is the solution,
 at least for now.

 If gcc headers didn't take priority, then fixincludes wouldn't work.

 The real question is why gcc forces changes to system headers instead
 of working with system headers.

 FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't
 been able to come up with a patch that I don't hate yet.  If something
 can be done, it would probably involve defining INCLUDE_DEFAULTS in
 config/i386/mingw-w64.h somehow, but the temporary workaround I have
 (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot
 prefix builds, so that's not useful.

 Mostly sending this just so the mailing list archive can help remember
 this for me ;)

 [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44

 --
 Mook


 The real fix is to sync what gcc wants with what we have, with
 appropriate changes on both sides.


 We (Ozkan and I) already tried to push necessary changes to gcc. But
 well, people love their POSIX stuff and dislike even an include next
 here. Problem is also that mingw.org don't provide those headers in
 their CRT at all, so a change here as to be runtime-specific, which
 messes things a bit (include of _mingw.h and checking for runtime).
 Best solution is (as work-around) to remove those headers from gcc's
 /lib/gcc/target/version/include directory

 That's hardly best.  We need to try again, and get GCC to listen.

 I don't care about mingw.org... we can do something vendor-specific
 for that.  But I do care about having GCC do a fixincludes on our

 My first suggestion *was* vendor specific which disabled
 those three headers' installation by gcc:
 http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html
 The thread went some time and then get lost, feel free
 to revive it if you want. The solution in that initial post above
 is what I already use in my personal builds and it works.

 headers, that we then revert.  That's just plain stupid.

 Who's the GCC maintainer that we need to hit over the head?

 --
 Ozkan


 It is the use of USER, right? This is fine at the moment, but I

 Yes, the USER_H mechanism.

 dislike it as we then have to maintain changes of gcc within our
 headers. What's about using fixinclude here? See gcc's bug-tracker
 40722 item, where HJ uses this to fix _rotl/_rolr issue.

 I can't understand, how can a fixinclude fix this thing??

It could add the include pattern to those headers. Did I got here
something wrong?
(a fix-include can be target-specific as shown in HJ's code).

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Download Intel#174; 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] ld: skipping incompatible build/root/mingw/lib/libmingw32.a

[Kai Tietz]

2010/4/25 Mario Emmenlauer ma...@emmenlauer.de:

 Hi all,

 I fail to build a canadian cross with mingw Revision: 2263 (current
 trunk).

 The error happens during make all-target-libgcc, message is:
  [cut]/build/root/x86_64-w64-mingw32/bin/ld: skipping incompatible \
  [cut]/build/root/mingw/lib/libmingw32.a when searching for -lmingw32

 There are more identical errors for other libs like kernel32 and msvcrt.


 objdump lists the correct format:
  [cut]/build/root/bin/x86_64-w64-mingw32-objdump --archive-headers \
  [cut]/build/root/x86_64-w64-mingw32/lib/libmingw32.a
    [...]
    lib64_libmingw32_a-tlsmcrt.o:     file format pe-x86-64

 Also, ld seems to be valid:
  [cut]/build/root/bin/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 srec symbolsrec verilog tekhex binary ihex


 Here is what I tried:
  - makefile: experimental/buildsystem/makebuildroot-test.mk
  - makefile: experimental/buildsystem/makebuildroot.mk
  - compile instructions from mingw64 sourceforge wiki

 Compiled with various combinations of
  - binutils-2.20.1, binutils-2.20.51 and binutils-trunk
  - gcc-4.4.3, gcc-4.5.0 and gcc-4.5.1-trunk

 Operating system:
  - Ubuntu 9.10 x86_64
  - Debian testing x86_64
  - Ubuntu 8.10 x86_64

 All result in the identical error message about 'skipping incompatible'
 when searching for mingw libs.


 Thanks a lot for any help,

   Mario

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


Well, for me it is looking like that either your binutils version
isn't a x64 defaulted one, or the libraries are build for 32-bit and
not for 64-bit. Did you used for crt build '--enable-lib32' or
'--enable-lib64'?

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

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

Re: [Mingw-w64-public] DW2 support on the 4.5 branch

[Kai Tietz]

2010/5/2 t66...@gmail.com t66...@gmail.com:
 Hello:
 I have question. I have been running gcc 4.4 branch with dw2 support why
 can't 4.5 branch have such support?
 4.4-dw2 gcc target mingw-w64 platform it runs well .. I see no reason
 why 4.5 fail target dw2 mingw-w64 platform.
 Since 4.5 have been released and development switched to 4.6, I'd have
 some courage to build gcc-4.5 with dw2 support but was stopped cause it
 was hard-coded disable.
 I am aware of that 4.5 could still be very buggy in fact I have not been
 using 4.5 since half a year ago... all because of the disable code and
 it been buggy.
 I saw that mingw.org released gcc-4.5 almost instantly with official
 release. And I am wondering if they use dw2 or the old sjlj code.
 Is there any plan at all for implementing it for inclusion in 4.5 branch ??

 t66...


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


Sorry to tell you this, but dw2 unwinding feature never ran for x64.
The current implementation of it is x86 specific and can't be used for
x64. So this #error message is in fact a hint that you are using for
x64 a broken feature. For x86 it remains available.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
___
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 + mkl

[Kai Tietz]

2010/5/14 Mario Rodríguez shi...@gmail.com:
 Kai Tietz wrote:

 2010/5/14 Tony Theodore to...@logyst.com:


 2010/5/15 Mario Rodríguez shi...@gmail.com:


 Hi,

 I want to use *MKL*`s lapack  BLAS in my *mingw* project.

 I use this libraries for 32 bits linking: mkl_intel_c_dll.lib,
 mkl_intel_thread_dll.lib, mkl_core_dll.lib. In 32b arquitecture, it´s
 enought adding this files names at the end of the g++ linking line.

 But in 64 bits (using mingw-w64 project), it show me undefined
 references in all blas/lapack calls. I use:

 -mkl_intel_lp64_dll.lib
 -mkl_intel_thread_dll.lib
 -mkl_core-dll.lib

 It is possible to do? Maybe using dlltool/reimp or some tool similar?

 Thanks in advance!


 Well, you need this DLL and the import-library (you can use gendef and
 dlltool for import-library generation). You can't combine 32-bit and
 64-bit binaries. No way.



 Try the link advisor [1], selecting Linux to see the gcc options, to
 get some hints - and see the common errors [2] . Note also, you
 probably want ilp64 not lp64.

 Cheers,

 Tony

 [1] http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/
 [2]
 http://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-for-linux-common-linking-errors/


 What is ilp64 (sizeof (int) == sizeof (long) == sizeof (void *) == 8)
 ??!? x64 is llp64 (sizeof (long long) == sizeof (void *) == 8).

 Cheers,
 Kai


 All this 3 files are x64 binaries. Intel provides you:

 -mkl_intel_lp64_dll.lib and mkl_intel_lp64.lib
 -mkl_intel_thread_dll.lib and mkl_intel_thread.lib (64 bit version)
 -mkl_core_dll.lib and mkl_core.lib (64 bit version)

 and they ask you to link against the _dll ones.
 I have not right here the exactly error, but it`s only an undefined
 reference to each lapack or blas call. I`m using gcc 4.5 (experimental)
 version



Ok, so it is most likely the underscoring issue here. You will need an
updated version of the toolchain (at least 4.5.x branch based). The
issue was recently corrected for binutils trunk and gcc 4.6 and then
backported to 4.5.x branch.
Maybe you can take Sezero's toolchain, but you should wait for new
version as we just detected for current an regression.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--

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

[Mingw-w64-public] Fw: Mingw-w64-public post from fractal.patt...@yahoo.com

[Kai Tietz]

As this message was sent without subscribing to our ML, I post it as quote 
to ML. Please do subscribe to ML before posting to it.

Regards,
Kai

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.

mingw-w64-public-ow...@lists.sourceforge.net wrote on 18.05.2010 05:11:07:

 List:Mingw-w64-public@lists.sourceforge.net
 From:fractal.patt...@yahoo.com
 Subject: GSL compile successful
 Reason:  Post by non-member to a members-only list
 
 - Message from Rajdeep fractal.patt...@yahoo.com on Mon, 17 
 May 2010 22:11:00 -0500 -
 
 To:
 
 mingw-w64-public@lists.sourceforge.net
 
 Subject:
 
 GSL compile successful
 
 Just wanted to report that I am able to compile Gnu Scientific Library 
v.
 1.13 and 1.14 with Msys 1.011 and mingw-w32-bin_i686-mingw_20100412.zip. 
I
 use WinXP SP3 as my Windows OS.
 
 http://www.gnu.org/software/gsl/
 
 Compiling the package was easy - I simply ran ./configure and then 
make
 all at the msys command prompt.
 
 My goal is to eventually try to use cygwin to run the configure script 
using
 ./configure --build=i686-w64-mingw32 --target=i686-w64-mingw32
 --host=i686-w64-mingw32. Has anyone tried this for when building other
 packages that can be compiled with msys??
 
 Thanks.
 FP


--

___
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 for ktietz's comutil assignment

[Kai Tietz]

2010/5/27 Ozkan Sezer seze...@gmail.com:
 On Thu, May 27, 2010 at 10:34 PM, NightStrike nightstr...@gmail.com wrote:
 On Sat, May 22, 2010 at 3:36 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Hi Jarrod,

 2010/5/22 Jarrod Chesney jarrod.ches...@gmail.com:
 Hi All
        This is my patch for the mingw-w64-headers for the comutil issues 
 (for uuid support ???)




 The changes to crt/_mingw.h are only for testing the patch and shouldn't 
 be applied.

 Test unit :
 bash-3.2$ cat test.cc
 #include windows.h
 #include comdef.h

 int main()
 {
        return 0;
 }

 Compile command :
 x86_64-w64-mingw32-gcc -isystem  
 ~/src/mingw-w64/trunk/mingw-w64-headers/crt -isystem 
 ~/src/mingw-w64/trunk/mingw-w64-headers/include  -isystem 
 ~/src/mingw-w64/trunk/mingw-w64-headers/defaults/include/ -c test.cc

 Regards, Jar (256fx)

 The patch looks fine to me on a first glance. I'll look into it
 tomorrow in more detail.

 Thanks for your work,
 Kai

 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination

 --

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


 Ping, or is this thread continued elsewhere?

 IIRC, the patch was applied to the trunk, except for the
 parts touching _mingw.h, of course, but can't remember
 which revision it was.

 I wonder how it turned out, though (don't know anything
 about com stuff)? Is it eligible for the 1.0 branch or is
 it too experimental?

 --
 Ozkan


It is for trunk and shouldn't go into 1.0. This feature is a
preparation for future __uuidof-feature.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--

___
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 for ktietz's comutil assignment

[Kai Tietz]

2010/5/27 NightStrike nightstr...@gmail.com:
 On Sat, May 22, 2010 at 3:36 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Hi Jarrod,

 2010/5/22 Jarrod Chesney jarrod.ches...@gmail.com:
 Hi All
        This is my patch for the mingw-w64-headers for the comutil issues 
 (for uuid support ???)




 The changes to crt/_mingw.h are only for testing the patch and shouldn't be 
 applied.

 Test unit :
 bash-3.2$ cat test.cc
 #include windows.h
 #include comdef.h

 int main()
 {
        return 0;
 }

 Compile command :
 x86_64-w64-mingw32-gcc -isystem  
 ~/src/mingw-w64/trunk/mingw-w64-headers/crt -isystem 
 ~/src/mingw-w64/trunk/mingw-w64-headers/include  -isystem 
 ~/src/mingw-w64/trunk/mingw-w64-headers/defaults/include/ -c test.cc

 Regards, Jar (256fx)

 The patch looks fine to me on a first glance. I'll look into it
 tomorrow in more detail.

 Thanks for your work,
 Kai

 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination

 --

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


 Ping, or is this thread continued elsewhere?


Patch was approved on IRC and is already committed to trunk.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--

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

Re: [Mingw-w64-public] Multiple definitions of __do_global_ctors, __do_global_dtors and __main

[Kai Tietz]

Sisyphus sisyph...@optusnet.com.au wrote on 31.05.2010 11:40:36:

 Hi,
 
 I'm on Windows Vista64, using the x64 crosscompiler.
 
 The command being run (it's part of a build of a perl extension named 
PDL) :
 
 ###
 x86_64-w64-mingw32-g++ -o
 ..\..\blib\arch\auto\PDL\Minuit\Minuit.dll -Wl,--base-file -Wl,dll.base 
-mdll
  -s -Lc:\_64\perl512_M\lib\CORE -LC:\_64\mingw64\mingw\lib Minuit.o
 minuitlib/futils.o  minuitlib/minuit.o
  minuitlib/intracfalse.o -Wl,--image-base,0x241d
 C:\_64\perl512_M\lib\CORE\libperl512.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libgfortran.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libm.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\libgcc.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libmoldname.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libkernel32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libuser32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libgdi32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libwinspool.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libcomdlg32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libadvapi32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libshell32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libole32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\liboleaut32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libnetapi32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libuuid.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libws2_32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libmpr.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libwinmm.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libversion.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libodbc32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libodbccp32.a
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\..\..\..\..
 \x86_64-w64-mingw32\lib\libcomctl32.a
 dll.exp
 ###
 
 The '.o' files in the above command are compiled using gfortran at an 
 earlier stage of the same build process.
 
 I've tried using both 'gcc version 4.4.4 20100208 (prerelease) (GCC)' 
(which 
 is the compiler that built perl) and 'gcc version 4.6.0 20100414 
 (experimental) (GCC)'. In both cases the same errors occur.
 
 The errors generated by the above command:
 
 ###
 C:\_64\mingw64\mingw\lib/libmingw32.a(lib64_libmingw32_a-gccmain.o): In
 function `_do_global_ctors':
 g:\buildbot\vista64-mingw32\mingw-x86-
 x86_64\build\build\mingw\obj/../../../build/mingw/mingw-w64-
 crt/crt/gccmain.c:46:
 multiple definition of `__do_global_ctors'
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\libgcc.
 a(__main.o):g:\buildbot\vista64-mingw32\mingw-x86-
 x86_64\build\build\gcc\obj\x86_64-w64-mingw32\libgcc/../../../../..
 /build/gcc/gcc/libgcc/../gcc/libgcc2.c:2160:
 first defined here
 C:\_64\mingw64\mingw\lib/libmingw32.a(lib64_libmingw32_a-gccmain.o): In
 function `_main':
 g:\buildbot\vista64-mingw32\mingw-x86-
 x86_64\build\build\mingw\obj/../../../build/mingw/mingw-w64-
 crt/crt/gccmain.c:80:
 multiple definition of `__main'
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\libgcc.
 a(__main.o):g:\buildbot\vista64-mingw32\mingw-x86-
 x86_64\build\build\gcc\obj\x86_64-w64-mingw32\libgcc/../../../../..
 /build/gcc/gcc/libgcc/../gcc/libgcc2.c:2184:
 first defined here
 C:\_64\mingw64\mingw\lib/libmingw32.a(lib64_libmingw32_a-gccmain.o): In
 function `_do_global_dtors':
 g:\buildbot\vista64-mingw32\mingw-x86-
 x86_64\build\build\mingw\obj/../../../build/mingw/mingw-w64-
 crt/crt/gccmain.c:28:
 multiple definition of `__do_global_dtors'
 c:\_64\mingw64\bin\..\lib\gcc\x86_64-w64-mingw32\4.4.4\libgcc.
 a(__main.o):g:\buildbot\vista64-mingw32\mingw-x86-
 x86_64\build\build\gcc\obj\x86_64-w64-mingw32\libgcc/../../../../..
 /build/gcc/gcc/libgcc/../gcc/libgcc2.c:2131:
 first defined here
 C:\_64\mingw64\mingw\lib/libmingw32.a(lib64_libmingw32_a-gccmain.o):
 gccmain.c:(.text+0x7a):
 undefined reference to `_imp__GetModuleHandleA'
 collect2: ld returned 1 

Re: [Mingw-w64-public] Where has ddk/usbiodef.h gone?

[Kai Tietz]

2010/6/7 Ozkan Sezer seze...@gmail.com:
 On Mon, Jun 7, 2010 at 12:09 AM, Dmitrijs Ledkovs
 dmitrij.led...@ubuntu.com wrote:
 On 6 June 2010 12:00, Ozkan Sezer seze...@gmail.com wrote:
 On Sun, Jun 6, 2010 at 1:37 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
 Hi all,

  I'm using GUID_DEVINTERFACE_USB_DEVICE in my windows code, which uses
 setupapi.dll. This declaration has been in ddk/usbiodef.h as of 
 mingw-w64-gcc-4.4.1

  However this header seems to be gone in erecnt versions (I'm currently on
 sezero gcc-4.4.5-20100527). Morevover I can't find 
 GUID_DEVINTERFACE_USB_DEVICE
 in any other header.

  Does anybody have deper insights into this issue?

  Ragards and TIA, Wolfgang

 This is a problem in our way of providing ddk headers: We
 do a svn-link to reactos headers, specifically to their

 Is the svn-link pinned to a particular revision on the 1.0 branch?

 It is not.

 (Stability  reproducibility is important for packagers ;-) )


 --
 Ozkan

 --
 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


I am on to discuss a solution for this issue between
Reactos-Mingw-w64. Possibly we are in need to for this directory
instead of svn-link to it. So at least we have controll, which files
are present and about dependencies.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Where has ddk/usbiodef.h gone?

[Kai Tietz]

2010/6/7 Henry N. henrynmail-mi...@yahoo.de:
  On 07.06.2010 09:20, Ozkan Sezer wrote:
 On Mon, Jun 7, 2010 at 10:17 AM, Wolfgang Glaswolfgang.g...@ev-i.at  wrote:
 On 2010-06-07 08:52, Ozkan Sezer wrote:
 On Mon, Jun 7, 2010 at 12:09 AM, Dmitrijs Ledkovs
 dmitrij.led...@ubuntu.com  wrote:
 On 6 June 2010 12:00, Ozkan Sezerseze...@gmail.com  wrote:
 On Sun, Jun 6, 2010 at 1:37 PM, Wolfgang Glaswolfgang.g...@ev-i.at  
 wrote:
 Hi all,

   I'm using GUID_DEVINTERFACE_USB_DEVICE in my windows code, which uses
 setupapi.dll. This declaration has been in ddk/usbiodef.h as of 
 mingw-w64-gcc-4.4.1

   However this header seems to be gone in erecnt versions (I'm 
 currently on
 sezero gcc-4.4.5-20100527). Morevover I can't find 
 GUID_DEVINTERFACE_USB_DEVICE
 in any other header.

   Does anybody have deper insights into this issue?

   Ragards and TIA, Wolfgang
 This is a problem in our way of providing ddk headers: We
 do a svn-link to reactos headers, specifically to their
 Is the svn-link pinned to a particular revision on the 1.0 branch?
 It is not.

 (Stability  reproducibility is important for packagers ;-) )
 I'd like to double the request for reproducability. From the packagers 
 viewpoint
 it would be better to stick to a hand-selected (and tested) snapshot of 
 upstream
 sources.

 Ozkan, will you provide us with a new snapshot once the missing header 
 problem
 is sorted out?

   Best regards, Wolfgang

 Well when things get sorted out, we can make a ddk snapshot
 release. Would that be appropriate?

  From user side this would be very welcome. It is very difficult to find
 the right ddk headers for a snapshot of mingw build.
 For such snapshot this test case should please produce no errors and no
 warnings:

      PREFIX=.../W64_160271
      TARGET=x86_64-w64-mingw32
      GCC=$PREFIX/bin/$TARGET-gcc

      echo #includentddk.hcheck.c
      $GCC -I$PREFIX/$TARGET/include/ddk -Wall -c -o check.o check.c

 --
 Henry N.


 --
 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


Well, the only solution I see here for the ddk-optional SDK is, that
we do a fork of it and have to maintain it by ourself. The only need
we would have here is a volunteer doing the manual merge and which
signs responsible to build up an testsuite for it.
We should keep in experimental branch the link to reactos-svn, but
replace the links in branches. When we found a volunteer for it, we
can proceed on this.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Where has ddk/usbiodef.h gone?

[Kai Tietz]

2010/6/7 Ozkan Sezer seze...@gmail.com:


 Well, the only solution I see here for the ddk-optional SDK is, that
 we do a fork of it and have to maintain it by ourself. The only need
 we would have here is a volunteer doing the manual merge and which
 signs responsible to build up an testsuite for it.
 We should keep in experimental branch the link to reactos-svn, but
 replace the links in branches. When we found a volunteer for it, we
 can proceed on this.

 Kai

 What I do for direct-x, I can do for ddk, too.

 --
 Ozkan


Well, if you commit for this task, I am fine. Major thing here is,
don't load too much burden on your shoulders.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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?

[Kai Tietz]

Hello Aaron,

2010/6/11 Aaron Giles aa...@aarongiles.com:
  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.

 Actually, no, I'm not confusing them, as I stated above: 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.

 Regardless, after further investigation, it appears that the dwarf-2 
 debugging is the default after all, but interestingly for our case -gstabs 
 produces much smaller binaries (132MB versus 280MB). Which is contradictory 
 to information I've read in other areas where dwarf is supposed to be much 
 more efficient.

 I still believe there is a significant size discrepancy between mingw and 
 linux here. I will gather more information to understand what is going on.

 Aaron


 --
 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


It is true that dwarf debugging information is much bigger in size.
But in general you have here different possiblities to solve this.
First of course by the debugging-level switch -gn. Additionally you
can use object-copy tool to split debugging information into an
separate file.
The gstabs information isn't possible for x64, so I would recomment
that you stick to the dwarf-2 information. In 4.4.x and 4.5.x series
there are some tweak about debugging information and inlined code. To
avoid this don't use debugging information (or strip them out into
separate debugging file) for optimization levels = 1.

Regards,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Using mingw-w32-bin_i686-cygwin packages

[Kai Tietz]

2010/7/9 Angelo Graziosi angelo.grazi...@alice.it:
 It is some time I am using these mingw-w32-bin_i686-cygwin packages on
 Cygwin, but recently it seems that there are some problems.

 The last useful package wich works for me is:
 mingw-w32-bin_i686-cygwin-1.7.5-1_20100617.tar.bz2. All packages
 released after (...20100704, 20100708) do not work: I can build
 executables but they do not produce any output. For example:

 $ tar -xvof mingw-w32-bin_i686-cygwin-1.7.5-1_20100708.tar.bz2 -C
 /usr/local/mingw-w64

 $ cd /usr/local/bin

 $ ln -sf /usr/local/mingw-w64/bin/i686-w64-mingw32-g++.exe mingw32-g++

 $ export PATH=/usr/local/mingw-w64/bin:$PATH

 $ cat /tmp/hello.cpp
 /* hello.c */
 #include iostream

 using namespace std;

 int main()
 {
    cout  Hello World  endl;
    return 0;
 }

 $ mingw32-g++ hello.cpp

 $ ./a.exe 
 [1] 3504

 $
 [1]+  Exit 127                ./a.exe


 If I remember correctly, 'Exit 127' means 'missing DLL'. What? Why then

 mingw-w32-bin_i686-cygwin-1.7.5-1_20100615.tar.bz2
 mingw-w32-bin_i686-cygwin-1.7.5-1_20100617.tar.bz2

 work just fine?

 I have also tried this:

 $ cygcheck ./a.exe
 C:\cygwin-2\tmp\a.exe
   C:\WINDOWS\system32\KERNEL32.dll
     C:\WINDOWS\system32\ntdll.dll
   C:\WINDOWS\system32\msvcrt.dll
   C:\cygwin-2\usr\local\mingw-w64\bin\libstdc++-6.dll
     C:\cygwin-2\usr\local\mingw-w64\bin\libgcc_s_sjlj-1.dll
     C:\WINDOWS\system32\USER32.dll
       C:\WINDOWS\system32\GDI32.dll

 $ ldd ./a.exe
         ntdll.dll = /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c91)
         kernel32.dll = /cygdrive/c/WINDOWS/system32/kernel32.dll
 (0x7c80)
         msvcrt.dll = /cygdrive/c/WINDOWS/system32/msvcrt.dll (0x77be)
         libstdc++-6.dll = /usr/local/mingw-w64/bin/libstdc++-6.dll
 (0x6fc4)
         libgcc_s_sjlj-1.dll =
 /usr/local/mingw-w64/bin/libgcc_s_sjlj-1.dll (0x6cec)
         USER32.dll = /cygdrive/c/WINDOWS/system32/USER32.dll (0x7e39)
         GDI32.dll = /cygdrive/c/WINDOWS/system32/GDI32.dll (0x77e4)


 which, apparently, do not flag any missed DLL

 Any idea?

 Thanks,
 Angelo.

 (NightStrike, JonY, sorry if I have added you... I am not subscribed to
 mingw-w64-public list... :()

Hello Angelo,

First, please subscribe to list before posting to it. Otherwise it can
be likely that a message gets unnecessary delayed or even deleted by
accident.

To your issue. Yes indeed the the failure-code seems to be a missing
DLL, or a wrong DLL with missing exports. I assume that not all
gcc-related DLL files are in your search path. You can try to use here
option '-static' to see, if it works without DLL files.

I hope I could help,
Kai

PS: Please subscribe to this list before replying, thanks.

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Header conflicts between cstdlib and process.h in recent builds of '1.0'

[Kai Tietz]

2010/7/15 Prof Brian Ripley rip...@stats.ox.ac.uk:
 Meanwhile (because I am working with 1.0) I have done a local svn merge and
 tested my example problems, which now compile.

 Thanks to all, especially Kai.

 On Thu, 15 Jul 2010, Ozkan Sezer wrote:

 On Thu, Jul 15, 2010 at 4:09 PM, Kai Tietz ktiet...@googlemail.com
 wrote:

 2010/7/15 Ozkan Sezer seze...@gmail.com:

 On Thu, Jul 15, 2010 at 3:11 PM, t66...@gmail.com t66...@gmail.com
 wrote:

 Hi,
 On 15/07/2010 9:50 PM, Kai Tietz wrote:

 2010/7/15 Kai Tietzktiet...@googlemail.com:

 2010/7/15 t66...@gmail.comt66...@gmail.com:

 Hi
 On 15/07/2010 8:47 PM, Prof Brian Ripley wrote:

 We're working towards switching over to post-April snapshots, but
 we
 have 1000s of R packages to recompile.  A couple of those (so far)
 have thrown up header conflicts.

 Specifically for this report I used
 mingw-w64-1.0-bin_i686-mingw_20100702.zip but I first found the
 problem with a Linux cross-compiler snapshot. This is a
 distillation
 of a very much more complex issue involving BOOST headers.

 If I compile the two-line C++ file test.cpp

 #includeprocess.h
 #includecstdlib

 with x86_64-w64-mingw32-g++ -c test.cpp I get

 In file included from test.cpp:2:0:

 e:/r/w64/gcc-4.5.1/lib/gcc/../../x86_64-w64-mingw32/include/c++/4.5.1/cstdlib:166:11:
 error: '::_Exit' has not been declared

 e:/r/w64/gcc-4.5.1/lib/gcc/../../x86_64-w64-mingw32/include/c++/4.5.1/cstdlib:204:22:
 error: '__gnu_cxx::_Exit' has not been declared

 This code works in the 20100405 snapshot (of 4.4.4).  I have a
 simple
 workaround (#includecstdlib    at the top of the affected files),
 but
 the code concerned is not mine and I don't believe that should be
 necessary.  The conflict is caused by this block of code

 #ifndef _CRT_TERMINATE_DEFINED
 #define _CRT_TERMINATE_DEFINED
      void __cdecl __MINGW_NOTHROW exit(int _Code)
 __MINGW_ATTRIB_NORETURN;
      _CRTIMP void __cdecl __MINGW_NOTHROW _exit(int _Code)
 __MINGW_ATTRIB_NORETURN;

 #pragma push_macro(abort)
 #undef abort
      void __cdecl __declspec(noreturn) abort(void);
 #pragma pop_macro(abort)

 #endif

 I'd welcome advice about the correct fix here.

 Brian Ripley


 I think if you build your own compiler and then you do --disable-c99
 this problem will go away but the issue probably isn't there just
 because of c99 enabled.
 I have encountered this issue on another level of software where
 this
 can be a header inclusion order problem or C99 get enabled problem.
 I was investigating such compile problem and found that
 incompatibilities when c99 enabled when you include C headers in
 mixed
 fashion with C++ headers this problem tends to occur.
 However, it can be simply work-around problem, or alternatively you
 can
 disable-c99.
 But it seems you're using the compiler by the buildbot...
 Maybe someone else can shed more light on this issue.


 --
 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


 The issue is in libstdc++ headers. Here the _Exit doesn't get (as
 other runtime functions of stdlib.h) no put into std:: namespace. So
 this is an issue to be address to gcc bugzilla. AFAIR there is
 already
 a report for it, but I am not sure.
 I don't see here a good solution for this to fix this in our headers,
 but maybe someone of you have an idea how to solve it on our site.

 Regards,
 Kai

 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination


 I see the issue in our headers. I prepare a fix for it soon. It would
 be nice if you could test the patch, if it fixes your problem
 (Committed at revision 2837 to trunk).

 Thanks for reporting it,
 Kai


 Kai:
 Thanks for the hot patch at revision 2837
 I tried the patched headers and tried to compile the affected software
 library again! This time it compiles successfully!
 Great! Now no more need to work around it.

 Best Regards

 Kai, can you apply the fix to 1.0 branch, too? (Or sholud I do it?)

 --
 Ozkan


 Feel free to merge it into 1.0. Sorry, I am at office at the moment
 and pretty busy. I can do this not before evening.

 Cheers,
 Kai

 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination


 Merged back to v1.0 branch at rev. 2839.

 --
 Ozkan


 --
 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

Re: [Mingw-w64-public] Why decimal floating point not supported for this target ?

[Kai Tietz]

Hello,

2010/7/16 Dongsheng Song dongsheng.s...@gmail.com:
 Hi,

 When I compile the following simple C program:

 int main()
 {
   _Decimal32 d1;
   _Decimal64 d2;
   _Decimal128 d3;

   return 0;
 }

 gcc 4.4 linux target is OK, but mingw32 or mingw64 target failed:

 C:\var\tmp\mingw32\bingcc testDecimal.c
 testDecimal.c: In function 'main':
 testDecimal.c:3: error: decimal floating point not supported for this target
 testDecimal.c:4: error: decimal floating point not supported for this target
 testDecimal.c:5: error: decimal floating point not supported for this target

 C:\var\tmp\mingw64\binx86_64-w64-mingw32-gcc testDecimal.c
 testDecimal.c: In function 'main':
 testDecimal.c:3: error: decimal floating point not supported for this target
 testDecimal.c:4: error: decimal floating point not supported for this target
 testDecimal.c:5: error: decimal floating point not supported for this target

 But I can found libdecnumber is compiled when build gcc !

 gcc/libdecnumber/decimal128.o
 gcc/libdecnumber/decimal32.o
 gcc/libdecnumber/decimal64.o

 sezero's gcc build give same errors too.

 Thanks for some help,
 Dongsheng Song

-- 

The feature of decimal-floating-point isn't enabled in gcc for
cygwin/mingw targets. Question for those targets are, which
decimal-floating-point variant should be used, is there any support by
runtime, which ISO-Spec it the Decimal128 type in #c following? etc.
As long as those points aren't clarified I don't want to enable this
feature for win32.

Regards,
Kai

|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] What library has strcpy_s and friends?

[Kai Tietz]

Hello Greg,

2010/7/16 Greg Peele aerovec...@hotmail.com:
 I've been taking MinGW-w64 TDM-GCC 4.5 for a spin on my company's code and I
 ran into a problem compiling a third party dependency: CppUnit 1.12.  Looks
 like MinGW defines __STDC_SECURE_LIB__ which causes CppUnit to use sprintf_s
 instead of sprintf (and similar functions).  However, prototypes for these
 functions aren't visible unless I explicitly define MINGW_HAS_SECURE_API.
 Once that's done, CppUnit compiles but doesn't link due to unresolved
 symbols for sprintf_s and friends.  After having some fun with nm and grep I
 gave up because I couldn't figure out which library contained these guys.
 Am I missing something or should I just modify CppUnit to only use these
 functions for MSVC?  Personally I don't ever use them but I try to avoid
 changes to third party code if possible.
 Greg Peele

Yes, the secured API isn't provided in msvcrt's import, as it is not
necessarily part of it. So you need to use msvcr80.dll or higher. We
don't provide the .def files for it at the moment, but you can use the
'gendef' tool to generate such an import library for it (see our crt
Makefile to see how DLL import libraries can be generated by a .def
file).

Regards,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Issues compiling Info-zip's zip 3.1c

[Kai Tietz]

Hello Chris,

2010/7/16 Chris Sutcliffe ir0nh...@gmail.com:
 Hi All,

 I'm trying to compile Info-zip's zip 3.1c during the linking stage of
 the 'dll' target.  The command I use to build the dll is:

 make -f win32/makefile.gcc CC=x86_64-w64-mingw32-gcc
 RC=x86_64-w64-mingw32-windres NOASM=1 dll

 which compiles the object files fine, however, when linking:

 dllwrap --driver-name x86_64-w64-mingw32-gcc -Wl,--enable-stdcall-fixup \
         --def windll/windll32.def  -ozip32z64.dll -s 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
 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/bin/ld.exe:
 warning: cannot find entry symbol _dllmaincrtstar...@12; defaulting to
 69fc1000

 The warning I think is OK, however, I also see:

 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

 which confuses me, given that mb_cur_max is exported by many libraries:

 $ grep -ri mb_cur_max *
 Binary file libcrtdll.a matches
 Binary file libmingwex.a matches
 Binary file libmsvcr80.a matches
 Binary file libmsvcrt.a matches
 Binary file libwcrtdll.a matches
 Binary file libwmsvcrt.a matches
 Binary file libwmsvcrt20.a matches
 Binary file libwmsvcrt40.a matches

 Any help on this would be greatly appreciated, thank you.

 Chris

 --
 Chris Sutcliffe
 http://emergedesktop.org
 http://www.google.com/profiles/ir0nh34d

 --
 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


This issue is caused by a recent fixed bug in binutils' dllwrap tool.
Please use a new binutils version (head) version. Then your problem
should be solved.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Kai Tietz break build on r2962 due to missing commit pow.def.h

[Kai Tietz]

2010/7/26 Kai Tietz ktiet...@googlemail.com:
 2010/7/26 Dongsheng Song dongsheng.s...@gmail.com:
 Here is the commit information:

 2010-07-25  Kai Tietz  kai.ti...@onevision.com

     * math/pow.c: Replaced by new implementation.
     * math/powl.c: Likewise.
     * math/pow.def.h: New pow implementation as template.



 ---
 M : /trunk/mingw-w64-crt/ChangeLog
 M : /trunk/mingw-w64-crt/math/pow.c
 M : /trunk/mingw-w64-crt/math/powl.c


 --
 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



 Sorry, I missed to add a file to repository. Sorry for the troubles.
 Issue will be fixed today by me.

As the current version with EDOM and ERANGE checks is at home and I'll
be now for about 8 hours at office, I attach to this e-mail the
content of pow.def.h so that people can play by it. The attached
version isn't providing EDOM/ERANGE check, so it is more as
intermediate solution.

Sorry for the troubles,

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

math/pow.def.h:
/*
 This Software is provided under the Zope Public License (ZPL) Version 2.1.

 Copyright (c) 2009, 2010 by the mingw-w64 project

 See the AUTHORS file for the list of contributors to the mingw-w64 project.

 This license has been certified as open source. It has also been designated
 as GPL compatible by the Free Software Foundation (FSF).

 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are met:

   1. Redistributions in source code must retain the accompanying copyright
  notice, this list of conditions, and the following disclaimer.
   2. Redistributions in binary form must reproduce the accompanying
  copyright notice, this list of conditions, and the following disclaimer
  in the documentation and/or other materials provided with the
  distribution.
   3. Names of the copyright holders must not be used to endorse or promote
  products derived from this software without prior written permission
  from the copyright holders.
   4. The right to distribute this software or to use it for any purpose does
  not give you the right to use Servicemarks (sm) or Trademarks (tm) of
  the copyright holders.  Use of them is covered by separate agreement
  with the copyright holders.
   5. If any files are modified, you must cause the modified files to carry
  prominent notices stating that you changed the files and the date of
  any change.

 Disclaimer

 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY EXPRESSED
 OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
 EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY DIRECT, INDIRECT,
 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
 OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
 LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
 NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

/* IEEE 754 - Elementary Functions - Special Cases
 * pow(+/-0, oo) is +0
 * pow(+/-0, -oo) is +oo
 * pow (x, ±0) is 1 for any x (even a zero, quiet NaN, or infinity)
 * pow (+1, y) is 1 for any y (even a quiet NaN)
 * pow (±0, y) is ±oo and signals the divideByZero exception for y an
odd integer  0
 * pow (±0, y) is +oo and signals the divideByZero exception for
finite y  0 and not an odd integer
 * pow (±0, y) is ±0 for finite y  0 an odd integer
 * pow (±0, y) is +0 for finite y  0 and not an odd integer
 * pow (-1, ±oo) is 1 with no exception
 pow( -inf, y) = +0 for y0 and not an odd integer
 pow( -inf, y) = -inf for y an odd integer  0
 pow( -inf, y) = +inf for y0 and not an odd integer
 pow (±inf, y) is ±0 with no exception for y an odd integer  0
 pow (±inf, -inf) is +0 with no exception
 pow (±inf, +inf) is +inf with no exception
 pow (±inf, y) is +0 with no exception for finite y  0 and not an odd integer
 pow (±inf, y) is ±inf with no exception for finite y  0 an odd integer
 pow (±inf, y) is +inf with no exception for finite y  0 and not an odd integer
 pow (x, y) signals the invalid operation exception for finite

Re: [Mingw-w64-public] Kai Tietz break build on r2962 due to missing commit pow.def.h

[Kai Tietz]

Sorry for the breakage. Fixed at revision 2967.

Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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

[Kai Tietz]

2010/7/27 Sisyphus sisyph...@optusnet.com.au:
 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
 --
 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



Well, this issue is reasoned by wrong order of windows.h and
winsock2.h includes. In general it is better to include first
winsock2.h and then the windows.h (or other platform headers
(Side-note winsock2.h includes itself windows.h). I thought we solved
this issue for allowing redefinition of winsock.h up to winsock2.h,
but well, for me it worked.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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

[Kai Tietz]

2010/7/28 Dongsheng Song dongsheng.s...@gmail.com:
 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

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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

[Kai Tietz]

2010/7/28 Ozkan Sezer seze...@gmail.com:
 On Wed, Jul 28, 2010 at 10:54 AM, Dongsheng Song
 dongsheng.s...@gmail.com wrote:
 于 2010-7-28 15:43, Kai Tietz 写道:
 2010/7/28 Dongsheng Song dongsheng.s...@gmail.com:
 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.


 You cannot build 4.4/4.5 based compilers against the mingw-w64-headers
 from the trunk unless you patch your gcc according to gcc PR/41943

 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


 --
 Ozkan


The problematic thing here is, that for cross-compiler and native
different include dependencies are there. So it is absolutely
unpredicatable (for now), if toolchain's header are used in native (so
the float.h/stddef.h etc are seen first from system-headers), or if it
is by a cross-toolchain, which has in front the gcc-internal header
versions of those files.
All in all it is simply a mess.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] sigset_t and w32pth

[Kai Tietz]

2010/7/29 Dongsheng Song dongsheng.s...@gmail.com:
 Thanks, when I build libassuan, I found ENOFILE not defined yet (within 
 errno.h)

 #define ENOFILE         2       /* No such file or directory */
 #define ENOENT          2

 When I add ENOFILE definition, I can build GnuPG 2 success.

 I don't know whether ENOFILE should defined.

 On Thu, Jul 29, 2010 at 21:52, Kai Tietz ktiet...@googlemail.com wrote:
 2010/7/29 Dongsheng Song dongsheng.s...@gmail.com:
 Hi,

 When I compile GnuPG 2, I found w32pth[1] use data type sigset_t which
 mingw-w64 not supported,
 Is there any plan to support sigset_t in sys/types.h ?

 #ifndef _SIGSET_T_
 #define _SIGSET_T_
 typedef int     _sigset_t;

 #ifndef _NO_OLDNAMES
 typedef _sigset_t       sigset_t;
 #endif
 #endif  /* Not _SIGSET_T_ */

 [1] svn://cvs.gnupg.org/w32pth

 Regards,
 Dongsheng

 Thanks for the point. Committed at revision 3020 to trunk.

 Regards,
 Kai

 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination



Well, this is one of those questions. As it is more an alias of ENOENT
we can add it.
Maybe someone else wants to comment on this addition?

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] sigset_t and w32pth

[Kai Tietz]

2010/7/30 Ozkan Sezer seze...@gmail.com:
 On Fri, Jul 30, 2010 at 4:45 AM, Dongsheng Song
 dongsheng.s...@gmail.com wrote:
 It seems that Borland C++ defined ENOFILE, and MinGW add the alias of ENOENT.



 Well, ENOENT is actually a standart errno.  I learnt ENOFILE just now,
 but since it seems to be in use, I say that we should define it.

 --
 Ozkan


 On Thu, Jul 29, 2010 at 23:43, Ozkan Sezer seze...@gmail.com wrote:
 On Thu, Jul 29, 2010 at 6:28 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/7/29 Dongsheng Song dongsheng.s...@gmail.com:
 Thanks, when I build libassuan, I found ENOFILE not defined yet (within 
 errno.h)

 #define ENOFILE         2       /* No such file or directory */
 #define ENOENT          2

 When I add ENOFILE definition, I can build GnuPG 2 success.

 I don't know whether ENOFILE should defined.

 On Thu, Jul 29, 2010 at 21:52, Kai Tietz ktiet...@googlemail.com wrote:
 2010/7/29 Dongsheng Song dongsheng.s...@gmail.com:
 Hi,

 When I compile GnuPG 2, I found w32pth[1] use data type sigset_t which
 mingw-w64 not supported,
 Is there any plan to support sigset_t in sys/types.h ?

 #ifndef _SIGSET_T_
 #define _SIGSET_T_
 typedef int     _sigset_t;

 #ifndef _NO_OLDNAMES
 typedef _sigset_t       sigset_t;
 #endif
 #endif  /* Not _SIGSET_T_ */

 [1] svn://cvs.gnupg.org/w32pth

 Regards,
 Dongsheng

 Thanks for the point. Committed at revision 3020 to trunk.

 Regards,
 Kai

 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination



 Well, this is one of those questions. As it is more an alias of ENOENT
 we can add it.
 Maybe someone else wants to comment on this addition?

 Cheers,
 Kai

 The man page for errno(3) on my linux doesn't list ENOFILE.
 Is it a deprecated errno? (I have no objections for its addition, BTW.)

 --
 Ozkan




Ok, let use add ENOFILE as '#define ENOFILE ENOENT'

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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

[Kai Tietz]

2010/7/31 Chris Sutcliffe ir0nh...@gmail.com:
  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


 --
 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


On x64 you can use here -lwmsvcrt to get this symbol. For 32-bit this
symbol is exported, so you shouldn't have here any troubles.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)

[Kai Tietz]

2010/8/17 Pete Batard pbat...@gmail.com:
 For 32 bit, the current MinGW-w64 winbase has:

   LONG InterlockedIncrement(LONG volatile *lpAddend);
   LONG InterlockedDecrement(LONG volatile *lpAddend);
   LONG InterlockedExchange(LONG volatile *Target,LONG Value);

 However, MinGW32 uses:

   LONG WINAPI InterlockedDecrement(LONG volatile *);
   LONG WINAPI InterlockedExchange(LONG volatile *,LONG);
   LONG WINAPI InterlockedIncrement(LONG volatile *);

 The lack of WINAPI qualifier in MinGW-w64 results in MinGW-w64 32 bit
 objects lacking the __stdcall decoration (eg. '_interlockedexcha...@8'),
 which means that a 32 bit MinGW-w64 generated library using any of the
 Interlocked calls above cannot be used with MinGW32 environment.

 You might also want to note the following from the MinGW32 header
 regarding the Interlocked API section:

 /* CAREFUL: These are exported from ntoskrnl.exe and declared in
 winddk.h as __fastcall functions, but are exported from kernel32.dll as
 __stdcall */

 Regards,

 /Pete

Thank you Pete for noticing that. We are aware of this and we solved
things here a bit different, but maybe we could add here the stdcall
decoration, too. Our Interlocked API is treated in our libmingwex and
has here (as intrinsic) the __cdecl decoration. Therefore it shouldn't
produce for you in general issues.
Do you have here found issues while building?

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)

[Kai Tietz]

2010/8/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Aug 17, 2010 at 2:24 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/8/17 Pete Batard pbat...@gmail.com:
 For 32 bit, the current MinGW-w64 winbase has:

   LONG InterlockedIncrement(LONG volatile *lpAddend);
   LONG InterlockedDecrement(LONG volatile *lpAddend);
   LONG InterlockedExchange(LONG volatile *Target,LONG Value);

 However, MinGW32 uses:

   LONG WINAPI InterlockedDecrement(LONG volatile *);
   LONG WINAPI InterlockedExchange(LONG volatile *,LONG);
   LONG WINAPI InterlockedIncrement(LONG volatile *);

 The lack of WINAPI qualifier in MinGW-w64 results in MinGW-w64 32 bit
 objects lacking the __stdcall decoration (eg. '_interlockedexcha...@8'),
 which means that a 32 bit MinGW-w64 generated library using any of the
 Interlocked calls above cannot be used with MinGW32 environment.

 You might also want to note the following from the MinGW32 header
 regarding the Interlocked API section:

 /* CAREFUL: These are exported from ntoskrnl.exe and declared in
 winddk.h as __fastcall functions, but are exported from kernel32.dll as
 __stdcall */

 Regards,

 /Pete

 Thank you Pete for noticing that. We are aware of this and we solved
 things here a bit different, but

 AFAIR, they aren't specifically marked as WINAPI in ms headers
 (well, maybe their mistake?..)

This isn't a mistake AFAIK. It is caused by the fact that the
Interlocked-API is for VC an intrinsic and in general intrinsics have
__decl calling convention (or special like __chkstk).
That kernel32 exports it as WINAPI is here caused by that fact that
all functions exported by kernel32 (and other OS platform DLLs) are
using __stdcall for 32-bit.

   maybe we could add here the stdcall
 decoration, too. Our Interlocked API is treated in our libmingwex and
 has here (as intrinsic) the __cdecl decoration.

 If we change into __stdcall we will be doing an api change within
 ourselves. This needs careful adjustments

Right, I am not sure if this is really the right way to go here.

  Therefore it shouldn't
 produce for you in general issues.
 Do you have here found issues while building?

 Regards,
 Kai


 --
 Ozkan


Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)

[Kai Tietz]

2010/8/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Aug 17, 2010 at 2:44 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/8/17 Pete Batard pbat...@gmail.com:
 On 2010.08.17 12:29, Ozkan Sezer wrote:
 Thank you Pete for noticing that. We are aware of this and we solved
 things here a bit different, but

 AFAIR, they aren't specifically marked as WINAPI in ms headers
 (well, maybe their mistake?..)

 Well, the thing is that the MSDN documentation has __cdecl [1], but
 looking at WinBase.h from a Visual Studio 2008 installation, there's a
 definite WINAPI qualifier on 32 bit. So there's some conflicting data
 there...

 I would think that if both MinGW32 and VS's WinBase.h use WINAPI on 32
 bit, MinGW-w64 probably wants to follow suit

    maybe we could add here the stdcall
 decoration, too. Our Interlocked API is treated in our libmingwex and
 has here (as intrinsic) the __cdecl decoration.
   Therefore it shouldn't
 produce for you in general issues.
 Do you have here found issues while building?

 I'm afraid we have. When compiling libusb 1.0 in a multilib MinGW-w64
 environment, we found that the resulting 32 bit library was unusable in
 MinGW32 [2].

 Looking at it more closely, we found that the pure MinGW32 binary had
 '_interlockedexcha...@8' (= __stdcall decoration) whereas the -m32
 MinGW-w64 had '_InterlockedExchange' (= __cdecl decoration). [3]

 Regards,

 /Pete

 [1] http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx
 [2]
 http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-td2262878.html#a2262878
 [3]
 http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-tp2262878p2473397.html


 Ok, thanks for explaination. We will adjust this soon. Ozkan do you
 want to take care here?


 I can. However I'd like to have a strict definition of what to do here:
 in winbase.h, I can change the Interlocked* api to __stdcall, but as I
 said that may cause problems with software compiled using older
 versions of mingw-w64.  Are we OK with this?

I think we are here. As we provide in general all of those intrinsic
in our libmingex, the users shouldn't notice it. Those symbols aren't
treated here in general as imported.

 Kai

 PS: For 64-bit this is a non-issue as x64 always uses a fastcall
 convention and the stdcall/thiscall/cdecl are all in fact fastcall,
 too.


 s / __fastcall / __cdecl /  ???

No, fastcall is the default calling-convention. Register are used for
argument passing for the first 4 arguments.  But don't come to the
idea that they would be freely-exchangable, as compiler makes here
still differences about used calling-convention and will warning if
you are mixing things up here.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)

[Kai Tietz]

2010/8/17 Kai Tietz ktiet...@googlemail.com:
 2010/8/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Aug 17, 2010 at 2:44 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/8/17 Pete Batard pbat...@gmail.com:
 On 2010.08.17 12:29, Ozkan Sezer wrote:
 Thank you Pete for noticing that. We are aware of this and we solved
 things here a bit different, but

 AFAIR, they aren't specifically marked as WINAPI in ms headers
 (well, maybe their mistake?..)

 Well, the thing is that the MSDN documentation has __cdecl [1], but
 looking at WinBase.h from a Visual Studio 2008 installation, there's a
 definite WINAPI qualifier on 32 bit. So there's some conflicting data
 there...

 I would think that if both MinGW32 and VS's WinBase.h use WINAPI on 32
 bit, MinGW-w64 probably wants to follow suit

    maybe we could add here the stdcall
 decoration, too. Our Interlocked API is treated in our libmingwex and
 has here (as intrinsic) the __cdecl decoration.
   Therefore it shouldn't
 produce for you in general issues.
 Do you have here found issues while building?

 I'm afraid we have. When compiling libusb 1.0 in a multilib MinGW-w64
 environment, we found that the resulting 32 bit library was unusable in
 MinGW32 [2].

 Looking at it more closely, we found that the pure MinGW32 binary had
 '_interlockedexcha...@8' (= __stdcall decoration) whereas the -m32
 MinGW-w64 had '_InterlockedExchange' (= __cdecl decoration). [3]

 Regards,

 /Pete

 [1] http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx
 [2]
 http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-td2262878.html#a2262878
 [3]
 http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-tp2262878p2473397.html


 Ok, thanks for explaination. We will adjust this soon. Ozkan do you
 want to take care here?


 I can. However I'd like to have a strict definition of what to do here:
 in winbase.h, I can change the Interlocked* api to __stdcall, but as I
 said that may cause problems with software compiled using older
 versions of mingw-w64.  Are we OK with this?

 I think we are here. As we provide in general all of those intrinsic
 in our libmingex, the users shouldn't notice it. Those symbols aren't
 treated here in general as imported.

 Kai

 PS: For 64-bit this is a non-issue as x64 always uses a fastcall
 convention and the stdcall/thiscall/cdecl are all in fact fastcall,
 too.


 s / __fastcall / __cdecl /  ???

 No, fastcall is the default calling-convention. Register are used for
 argument passing for the first 4 arguments.  But don't come to the
 idea that they would be freely-exchangable, as compiler makes here
 still differences about used calling-convention and will warning if
 you are mixing things up here.

 Kai

 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination


Pete,

could you provide us a list of the Interlock* API, which has stdcall
calling convention by our findings? Please just list names of those
functions and don't copy from VC's header-set. So we can adjust things
for win32 more easily without violating EULA.

Thanks,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)

[Kai Tietz]

2010/8/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Aug 17, 2010 at 2:52 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/8/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Aug 17, 2010 at 2:44 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/8/17 Pete Batard pbat...@gmail.com:
 On 2010.08.17 12:29, Ozkan Sezer wrote:
 Thank you Pete for noticing that. We are aware of this and we solved
 things here a bit different, but

 AFAIR, they aren't specifically marked as WINAPI in ms headers
 (well, maybe their mistake?..)

 Well, the thing is that the MSDN documentation has __cdecl [1], but
 looking at WinBase.h from a Visual Studio 2008 installation, there's a
 definite WINAPI qualifier on 32 bit. So there's some conflicting data
 there...

 I would think that if both MinGW32 and VS's WinBase.h use WINAPI on 32
 bit, MinGW-w64 probably wants to follow suit

    maybe we could add here the stdcall
 decoration, too. Our Interlocked API is treated in our libmingwex and
 has here (as intrinsic) the __cdecl decoration.
   Therefore it shouldn't
 produce for you in general issues.
 Do you have here found issues while building?

 I'm afraid we have. When compiling libusb 1.0 in a multilib MinGW-w64
 environment, we found that the resulting 32 bit library was unusable in
 MinGW32 [2].

 Looking at it more closely, we found that the pure MinGW32 binary had
 '_interlockedexcha...@8' (= __stdcall decoration) whereas the -m32
 MinGW-w64 had '_InterlockedExchange' (= __cdecl decoration). [3]

 Regards,

 /Pete

 [1] http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx
 [2]
 http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-td2262878.html#a2262878
 [3]
 http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-tp2262878p2473397.html


 Ok, thanks for explaination. We will adjust this soon. Ozkan do you
 want to take care here?


 I can. However I'd like to have a strict definition of what to do here:
 in winbase.h, I can change the Interlocked* api to __stdcall, but as I
 said that may cause problems with software compiled using older
 versions of mingw-w64.  Are we OK with this?

 I think we are here. As we provide in general all of those intrinsic
 in our libmingex, the users shouldn't notice it. Those symbols aren't
 treated here in general as imported.


 Hmm, thinking a little more, this need not be as much of an issue:
 we have __cdecl versions in libmingwex,  if we change into __stdcall
 then old software can still succeed linking to libmingwex but new ones
 will link to kernel32, so all we have to do is not change the local
 implementations and keep them as __cdecl.  Am I correct?

No, we need to change local implementation, too. Otherwise call stack
gets broken. If we do this change, we have to change them all or none.

Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)

[Kai Tietz]

2010/8/17 Pete Batard pbat...@gmail.com:
 On 2010.08.17 12:55, Kai Tietz wrote:
 Pete,

 could you provide us a list of the Interlock* API, which has stdcall
 calling convention by our findings? Please just list names of those
 functions and don't copy from VC's header-set. So we can adjust things
 for win32 more easily without violating EULA.

 Thanks for the speedy replies.

 As far as we are concerned, we only had InterlockedExchange and
 InterlockedIncrement being a problem, as these are the only 2 call from
 Interlocked API we use.

 The following is copied from MinGW32's winbase.h [1] which should work
 with your EULA. It looks like you might need to add some #ifdefs as well:

 #if !(__USE_NTOSKRNL__)
 /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h
    as __fastcall functions, but are  exported from kernel32.dll as
 __stdcall */
 #if (_WIN32_WINNT = 0x0501)
 WINBASEAPI VOID WINAPI InitializeSListHead(PSLIST_HEADER);
 #endif
 #ifndef __INTERLOCKED_DECLARED
 #define __INTERLOCKED_DECLARED
 LONG WINAPI InterlockedCompareExchange(LONG volatile *,LONG,LONG);
 /* PVOID WINAPI InterlockedCompareExchangePointer(PVOID*,PVOID,PVOID); */
 #define InterlockedCompareExchangePointer(d,e,c) \
     (PVOID)InterlockedCompareExchange((LONG volatile
 *)(d),(LONG)(e),(LONG)(c))
 LONG WINAPI InterlockedDecrement(LONG volatile *);
 LONG WINAPI InterlockedExchange(LONG volatile *,LONG);
 /* PVOID WINAPI InterlockedExchangePointer(PVOID*,PVOID); */
 #define InterlockedExchangePointer(t,v) \
     (PVOID)InterlockedExchange((LONG volatile *)(t),(LONG)(v))
 LONG WINAPI InterlockedExchangeAdd(LONG volatile *,LONG);
 #if (_WIN32_WINNT = 0x0501)
 PSLIST_ENTRY WINAPI InterlockedFlushSList(PSLIST_HEADER);
 #endif
 LONG WINAPI InterlockedIncrement(LONG volatile *);
 #if (_WIN32_WINNT = 0x0501)
 PSLIST_ENTRY WINAPI InterlockedPopEntrySList(PSLIST_HEADER);
 PSLIST_ENTRY WINAPI InterlockedPushEntrySList(PSLIST_HEADER,PSLIST_ENTRY);
 #endif
 #endif /* __INTERLOCKED_DECLARED */
 #endif /*  __USE_NTOSKRNL__ */

 Regards,

 /Pete

 [1]
 http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h?rev=1.98content-type=text/x-cvsweb-markupcvsroot=src

Ozkan,

do you remember the issue we had about _Interlocked and the
Interlocked... API? As more as I think about it as more it seems to me
that the leading underscore variant has cdecl, and the none-underscore
variant has stdcall convention.
Fridrich: Could you try to enlight us here?

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)

[Kai Tietz]

2010/8/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Aug 17, 2010 at 3:50 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/8/17 Pete Batard pbat...@gmail.com:
 On 2010.08.17 12:55, Kai Tietz wrote:
 Pete,

 could you provide us a list of the Interlock* API, which has stdcall
 calling convention by our findings? Please just list names of those
 functions and don't copy from VC's header-set. So we can adjust things
 for win32 more easily without violating EULA.

 Thanks for the speedy replies.

 As far as we are concerned, we only had InterlockedExchange and
 InterlockedIncrement being a problem, as these are the only 2 call from
 Interlocked API we use.

 The following is copied from MinGW32's winbase.h [1] which should work
 with your EULA. It looks like you might need to add some #ifdefs as well:

 #if !(__USE_NTOSKRNL__)
 /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h
    as __fastcall functions, but are  exported from kernel32.dll as
 __stdcall */
 #if (_WIN32_WINNT = 0x0501)
 WINBASEAPI VOID WINAPI InitializeSListHead(PSLIST_HEADER);
 #endif
 #ifndef __INTERLOCKED_DECLARED
 #define __INTERLOCKED_DECLARED
 LONG WINAPI InterlockedCompareExchange(LONG volatile *,LONG,LONG);
 /* PVOID WINAPI InterlockedCompareExchangePointer(PVOID*,PVOID,PVOID); */
 #define InterlockedCompareExchangePointer(d,e,c) \
     (PVOID)InterlockedCompareExchange((LONG volatile
 *)(d),(LONG)(e),(LONG)(c))
 LONG WINAPI InterlockedDecrement(LONG volatile *);
 LONG WINAPI InterlockedExchange(LONG volatile *,LONG);
 /* PVOID WINAPI InterlockedExchangePointer(PVOID*,PVOID); */
 #define InterlockedExchangePointer(t,v) \
     (PVOID)InterlockedExchange((LONG volatile *)(t),(LONG)(v))
 LONG WINAPI InterlockedExchangeAdd(LONG volatile *,LONG);
 #if (_WIN32_WINNT = 0x0501)
 PSLIST_ENTRY WINAPI InterlockedFlushSList(PSLIST_HEADER);
 #endif
 LONG WINAPI InterlockedIncrement(LONG volatile *);
 #if (_WIN32_WINNT = 0x0501)
 PSLIST_ENTRY WINAPI InterlockedPopEntrySList(PSLIST_HEADER);
 PSLIST_ENTRY WINAPI InterlockedPushEntrySList(PSLIST_HEADER,PSLIST_ENTRY);
 #endif
 #endif /* __INTERLOCKED_DECLARED */
 #endif /*  __USE_NTOSKRNL__ */

 Regards,

 /Pete

 [1]
 http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h?rev=1.98content-type=text/x-cvsweb-markupcvsroot=src

 Ozkan,

 do you remember the issue we had about _Interlocked and the
 Interlocked... API? As more as I think about it as more it seems to me
 that the leading underscore variant has cdecl, and the none-underscore
 variant has stdcall convention.

 Can't remember. Let me try and dig old stuff and see if I can find anything

 Fridrich: Could you try to enlight us here?

 Kai


Yeah, this could make sense that Interlocked... is for x86 stdcall,
and _Interlocked... is cdecl. As you can see in winbase.h that for
ia64 and x64 the Interlocked... API is treated like the
_Interlocked... API (as here no calling convention differences are
used). But for x86 this doesn't happen.

So I am pretty sure that this is the jumping point we misinterpreted here.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)

[Kai Tietz]

2010/8/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Aug 17, 2010 at 4:08 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/8/17 Ozkan Sezer seze...@gmail.com:
 On Tue, Aug 17, 2010 at 3:50 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/8/17 Pete Batard pbat...@gmail.com:
 On 2010.08.17 12:55, Kai Tietz wrote:
 Pete,

 could you provide us a list of the Interlock* API, which has stdcall
 calling convention by our findings? Please just list names of those
 functions and don't copy from VC's header-set. So we can adjust things
 for win32 more easily without violating EULA.

 Thanks for the speedy replies.

 As far as we are concerned, we only had InterlockedExchange and
 InterlockedIncrement being a problem, as these are the only 2 call from
 Interlocked API we use.

 The following is copied from MinGW32's winbase.h [1] which should work
 with your EULA. It looks like you might need to add some #ifdefs as well:

 #if !(__USE_NTOSKRNL__)
 /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h
    as __fastcall functions, but are  exported from kernel32.dll as
 __stdcall */
 #if (_WIN32_WINNT = 0x0501)
 WINBASEAPI VOID WINAPI InitializeSListHead(PSLIST_HEADER);
 #endif
 #ifndef __INTERLOCKED_DECLARED
 #define __INTERLOCKED_DECLARED
 LONG WINAPI InterlockedCompareExchange(LONG volatile *,LONG,LONG);
 /* PVOID WINAPI InterlockedCompareExchangePointer(PVOID*,PVOID,PVOID); */
 #define InterlockedCompareExchangePointer(d,e,c) \
     (PVOID)InterlockedCompareExchange((LONG volatile
 *)(d),(LONG)(e),(LONG)(c))
 LONG WINAPI InterlockedDecrement(LONG volatile *);
 LONG WINAPI InterlockedExchange(LONG volatile *,LONG);
 /* PVOID WINAPI InterlockedExchangePointer(PVOID*,PVOID); */
 #define InterlockedExchangePointer(t,v) \
     (PVOID)InterlockedExchange((LONG volatile *)(t),(LONG)(v))
 LONG WINAPI InterlockedExchangeAdd(LONG volatile *,LONG);
 #if (_WIN32_WINNT = 0x0501)
 PSLIST_ENTRY WINAPI InterlockedFlushSList(PSLIST_HEADER);
 #endif
 LONG WINAPI InterlockedIncrement(LONG volatile *);
 #if (_WIN32_WINNT = 0x0501)
 PSLIST_ENTRY WINAPI InterlockedPopEntrySList(PSLIST_HEADER);
 PSLIST_ENTRY WINAPI InterlockedPushEntrySList(PSLIST_HEADER,PSLIST_ENTRY);
 #endif
 #endif /* __INTERLOCKED_DECLARED */
 #endif /*  __USE_NTOSKRNL__ */

 Regards,

 /Pete

 [1]
 http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h?rev=1.98content-type=text/x-cvsweb-markupcvsroot=src

 Ozkan,

 do you remember the issue we had about _Interlocked and the
 Interlocked... API? As more as I think about it as more it seems to me
 that the leading underscore variant has cdecl, and the none-underscore
 variant has stdcall convention.

 Can't remember. Let me try and dig old stuff and see if I can find anything

 Fridrich: Could you try to enlight us here?

 Kai


 Yeah, this could make sense that Interlocked... is for x86 stdcall,
 and _Interlocked... is cdecl. As you can see in winbase.h that for
 ia64 and x64 the Interlocked... API is treated like the
 _Interlocked... API (as here no calling convention differences are
 used). But for x86 this doesn't happen.

 So I am pretty sure that this is the jumping point we misinterpreted here.

 Kai

 --
 |  (\_/) This is Bunny. Copy and paste
 | (='.'=) Bunny into your signature to help
 | ()_() him gain world domination


 These are the ones that are exported from kernel32.dll
 acc. to trunk's kernel32.def:

 interlockedcompareexchang...@20
 interlockedcompareexcha...@12
 interlockeddecrem...@4
 interlockedexcha...@8
 interlockedexchange...@8
 interlockedflushsl...@4
 interlockedincrem...@4

 These are the ones that are exported from ntoskrnl.exe
 acc.to trunk's ntoskrnl.def:
 @interlockedcompareexcha...@12
 @interlockeddecrem...@4
 @interlockedexcha...@8
 @interlockedexchange...@8
 @interlockedincrem...@4

 So there are no _Interlocked* here, which means that
 all those _Interlocked* are ms intrinsics *and* they must
 always be inlines, ie. not just _CRT_INLINE but FORCEINLINE
 for us.  When they are inlines, I guess __cdecl or __stdcall
 doesn't matter.  that must be where we started to err.
 This is uglier that it looks...


See intrin.h and the definitions of those intrinsic. They have here
cdecl convention. So _Interlocked... is cdecl and Interlocked... is
for x86 stdcall.

This change affects winnt.h and winbase.h. And of course we need to do
here special casing for stdcall variant for 32-bit (the aliasing) in
our crt libmingwex.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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 C++0x thread

[Kai Tietz]

2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com:
 I guess this mailing list is as good a place as any to start this
 discussion.

 Eventually it will boil down to someone writing the hard code (as I am not
 near capable enough). I can, though, get some info and gather docs for a
 willing party.

 The thing is: GCC 4.4+ has provided std::thread for POSIX platforms, making
 for a very easy way of using multithreading in c++, using the upcoming
 standard (which is now falsely named C++0x, like it's not 2010 yet ;) ).
 Mingw is falling behind, because this low-level thing needs a
 platform-dependent implementation. As John E. already mentioned, using
 pthread-w32 is not a good choice. Easy, but sloppy.

 Therefore I hope a person with enough c++ and win32 threading knowledge will
 implement it through native win32 threads. I have already gotten some info
 and docs ready:

 1. boost::thread is probably quite like std::thread, as is almost 40% of the
 new standard:
 http://live.boost.org/doc/libs/1_35_0/boost/thread/win32/thread.hpp
 2. pthread implementation of the GCC gthreads used as a backend for
 std::thread: http://gcc.gnu.org/ml/libstdc++/2008-08/txt00033.txt
 3. MSDN win32 threading API, which I hope isn't to crappy to be wrapped by
 std::thread:
 http://msdn.microsoft.com/en-us/library/ms684254%28v=VS.85%29.aspx
 4. A paid implementation of std::thread, just::thread, which will probably
 not provide anything helpful: http://www.stdthread.co.uk/

 This is an exciting new feature, and I would hate MinGW to get behind.

Yes, I would prefer here a native win32 API variant for threads, as
the dependency to pthread for c++ isn't in all cases the best
solution. Also it seems to me that the abilities of c++0x are limited
and so a native win32 implementation should work.

 Ruben

 PS: in an extension, perhaps OpenMP can be rewritten to also use
 std::thread, once available, to drop even that pthread dependency.


We have patches for OpenMP pending (Doug Semler has here prepared
patches for this). It implements for mingw the threading by win32 API.
He just waits that paper work for FSF gets completed. I hope this will
happen before 4.6 gets released.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] GCC C++0x thread

[Kai Tietz]

2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com:
 Yes, I would prefer here a native win32 API variant for threads, as
 the dependency to pthread for c++ isn't in all cases the best
 solution. Also it seems to me that the abilities of c++0x are limited
 and so a native win32 implementation should work.

 That's good news!


 We have patches for OpenMP pending (Doug Semler has here prepared
 patches for this). It implements for mingw the threading by win32 API.
 He just waits that paper work for FSF gets completed. I hope this will
 happen before 4.6 gets released.

 Perhaps Doug would like to work on this then hopefully looking with the
 most irrestable puppy eyes I can muster?
 Looking at the pthread implementation, there's only 17 functions and a few
 typedefs and defines that need to be implemented, and they don't seem overly
 complicated for someone with intimate knowledge of the underlying threading
 API.

Hope so too. He will be back soon. He has at the moment some sabbatical time.

 About the discussion in my other thread: something everyone is seemingly
 missing is performance... ffmpeg/vlc has proven that native threads are much
 better than a pthread-w32 implementation. This together with licensing and
 dependency issues pretty much closes the case for pthreads vs win32. But
 that's just my two cents...

Right, performance is here for sure a second issue. The major thing
for me is about pthread-w32 project, that it is slowly maintained
(yes, there are patches pending over two years for review), the
license issue about LGPL (which forces redistributable applications to
use shared version), and the speed impact. Well, latter isn't a such
big thing here IMHO, but well, I admit that native win32 threading API
is faster.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] GCC C++0x thread

[Kai Tietz]

2010/8/25 Ruben Van Boxem vanboxem.ru...@gmail.com:

 Brand new idea: I define
 #define _GLIBCXX_HAS_GTHREADS 1

 This adds thread to std:: and allows me to see what undefined stuff there
 is! Perfect, no? I'll keep you guys informed.

 Ruben

 Sorry for the SPAM...

 Some additional thoughts:

 1. Mingw-w64 compilers define:
 GCC_GTHR_WIN32_H

 but only the 4.6 snapshots contain the actual header and implementation.

 2. The GCC header
 lib\gcc\x86_64-w64-mingw32\4.5.0\include\c++\x86_64-w64-mingw32\bits\gthr.h
 will have to have a win32 threads case (around line 153, 4.6 snapshot) and
 include the gthr-win32.h header.

 3. missing types and functions:
 __gthread_time_t will have to be defined to time.h's (actually
 sys/timeb.h's) struct timespec (as in gthr-posix.h).
 __gthread_cond_t is harder than the previous, see for example:
 http://www.cs.wustl.edu/~schmidt/win32-cv-1.html)
 ... (many more, but can't say for sure if the two above aren't the problem)

 4. The defines above should be set by the compiler automatically (once
 everything works of course).

 Now I'm stuck :(

 Ruben


Ruben,

for this we need a posix emulation library, or have to implement in
gthr-win32.h such a beast. For details when __GTHREAD_CXX0X should be
set to 1, see in gcc/gthr.h

   If the following are also defined, you should
 #define __GTHREADS_CXX0X 1
   to enable the c++0x thread library.

Types:
  __gthread_t
  __gthread_time_t

Interface:
int __gthread_create (__gthread_t *thread, void *(*func) (void*), void *args);
int __gthread_join (__gthread_t thread, void **value_ptr);
int __gthread_detach (__gthread_t thread);
int __gthread_equal (__gthread_t t1, __gthread_t t2);
__gthread_t __gthread_self (void);
int __gthread_yield (void);
int __gthread_mutex_timedlock (__gthread_mutex_t *m, const
__gthread_time_t *abs_timeout);
int __gthread_recursive_mutex_timedlock (__gthread_recursive_mutex_t
*m, const __gthread_time_t *abs_time);
int __gthread_recursive_mutex_timedlock (__gthread_recursive_mutex_t
*m, const __gthread_time_t *abs_time);
int __gthread_cond_signal (__gthread_cond_t *cond);
int __gthread_cond_timedwait (__gthread_cond_t *cond,
__gthread_mutex_t *mutex, const __gthread_time_t *abs_timeout);
int __gthread_cond_timedwait_recursive (__gthread_cond_t *cond,
__gthread_recursive_mutex_t *mutex, const __gthread_time_t *abs_time)

If this API is implemented for win32 native, then we can have c++0x
standard conformancy.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] GCC C++0x thread

[Kai Tietz]

2010/8/26 Ruben Van Boxem vanboxem.ru...@gmail.com:


 but poking around, I do not find a thread file (the include file
 for std::thread).

 it should be in:
 gcc-src/libstdc++-v3/include/std


 My mingw gcc installation does have a thread file.  (I realize that
 it may be out of date, but it's all I have.)  I see, as Ruben pointed
 out, that it references (either directly or indirectly)

   __gthread_cond_t
   __gthread_time_t

 (and related), and that these are not defined in gthr-win32.h.

 As I said, *time_t is easy, but *cond_t seems like a big problem, because
 the whole concept of threading is different and there's far from a 1-on-1
 mapping of *cond_t to win32 API. Once we have that struct though, it should
 be quite straightforward to get the functions implemented. The gthr-win32.h
 header is located in

 gcc trunk/4.6 snapshot:
 gcc/gthr-win32.h
 gcc/config/i386/gthr-win32.c

 This last one will either need


 Do I take it correctly that the windows version of gthreads does
 not implement all of the features in the linux/posix version, and
 that some of these features are needed by the gcc implementation
 of std::thread?

 And that our discussion here is basically about sticking with the
 existing gcc implementation of std::thread and getting it to work
 on windows by adding the missing features to the windows
 version of gthreads?

 Correct.

As I said before, if those functions are implemented in
gcc/gthr-win32.h and gcc/config/i386/gthr-win32-c, then we can define
in gthr-win32.h the define to support CXX0X.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Problem with mingw32-make

[Kai Tietz]

2010/8/27 Chris Sutcliffe ir0nh...@gmail.com:
 On 26 August 2010 11:52, Chris Sutcliffe wrote:
 On 26 August 2010 11:10, Ozkan Sezer wrote:
 On Thu, Aug 26, 2010 at 6:04 PM, Chris Sutcliffe wrote:
 Given the assumption that PATH_SEPARATOR_CHAR *is* redundant for VMS
 and HAVE_DOS_PATHS.  Once we have something that we both think would
 work, I'll bring this up on the make-w32 mailing list and see if we
 can get it in the upstream sources.

 That looks OK too.  Would you take it to the make mailing lists?

 Will do.

 I've made some progress with the patch.  Just waiting final approval:

 http://lists.gnu.org/archive/html/make-w32/2010-08/msg00039.html

 Cheers!

 Chris

Thanks for your hard work.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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

[Kai Tietz]

2010/8/30 Chris Sutcliffe ir0nh...@gmail.com:
 On 30 August 2010 09:27, JonY wrote:
 On 8/30/2010 21:00, Chris Sutcliffe wrote:
 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?

 Based on what I did with w32api:

 2010-08-21  Chris Sutcliffe  ir0nh...@users.sourceforge.net

        * lib/kernel32.def (CopyLZFile, GetExpandedNameA,
 GetExpandedNameW, LZClose,
        LZCopy, LZInit, LZOpenFileA, LZOpenFileW, LZRead, LZSeek,
 OpenProcessToken,
        OpenThreadToken, RegCloseKey, RegCreateKeyExA, RegCreateKeyExW,
        RegDeleteKeyExA, RegDeleteKeyExW, RegDeleteValueA, RegDeleteValueW,
        RegEnumKeyExA, RegEnumKeyExW, RegEnumValueA, RegEnumValueW, 
 RegFlushKey,
        RegGetKeySecurity, RegLoadKeyA, RegLoadKeyW, RegNotifyChangeKeyValue,
        RegOpenCurrentUser, RegOpenKeyExA, RegOpenKeyExW,
 RegOpenUserClassesRoot,
        RegQueryInfoKeyA, RegQueryInfoKeyW, RegQueryValueExA, RegQueryValueExW,
        RegRestoreKeyA, RegRestoreKeyW, RegSetKeySecurity, RegSetValueExA,
        RegSetValueW, RegUnLoadKeyA, RegUnLoadKeyW, RtlCaptureStackBackTrace,
        RtlFillMemory, RtlMoveMemory, RtlZeroMemory, SetThreadToken): Remove
        conflicting definition.
        * lib/th32.def: Remove.
        * lib/ntdll.def (RtlUnwind): Remove conflicting definition.
        * lib/version.def (VerLanguageNameA, VerLanguageNameW): Remove
 conflicting
        definition.

 However, I did not regenerate all def files, so there may be others as well.

 Chris

 --
 Chris Sutcliffe
 http://emergedesktop.org
 http://www.google.com/profiles/ir0nh34d

The issue you see here is related to the default import library order
given by gcc. It uses -luser32 -lkernel32 -ladvapi32 -lshell32 which
leads here to the issue. IMHO kernel32 should come last here.
Something like this is more correct -lshell32 -ladvapi32 -luser32
-lkernel32

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Problem with math.h?

[Kai Tietz]

2010/8/30 Vasilakis fithis2...@gmail.com:
  I have a problem compiling an application under windows XPSP3 x86 with

 mingw-w32-bin_i686-mingw_20100711_sezero.zip +
 sezero_20100711_w32_runtime_update_3441.zip

 The exact error reads.

 e:\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/math.h:384:
 error: expected unqualified-id before 'float'

 What does it mean?

 Thanks

Hmm, the line you show is 'extern float __cdecl sinf(float _X);'. Now
is the question which float gcc is warning here about. If it is the
first, then you have possibly a define of extern (which is a bit
unlikely). My bets go for the second one and here the issue could be
that sinf is a define. To check use preprocessed headers (gcc -E) and
check what this line gets expanded to.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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

[Kai Tietz]

2010/8/30 Chris Sutcliffe ir0nh...@gmail.com:
 On 30 August 2010 10:42, Kai Tietz wrote:
 2010/8/30 Chris Sutcliffe ir0nh...@gmail.com:
 Is it possible to override / change the default link order (i.e. is it
 in a config file somewhere), or is it hard coded at compile time?

 Well, this is a suggested default by gcc (IMHO we should change here
 order, or teach ld to know dependencies odering of import-libraries).
 But of course by using 'gcc -o myapp.exe my-object-files -ladvapi32'
 forces that advapi32 library gets linked before the default one.

 One other thought I had was specifying '-nodefaultlibs', but I think
 that may be a little extreme, given:

 -nodefaultlibs
    Do not use the standard system libraries when linking. Only the
 libraries you specify will be passed to the linker, options specifying
 linkage of the system libraries, such as -static-libgcc or
 -shared-libgcc, will be ignored. The standard startup files are used
 normally, unless -nostartfiles is used. The compiler may generate
 calls to memcmp, memset, memcpy and memmove. These entries are usually
 resolved by entries in libc. These entry points should be supplied
 through some other mechanism when this option is specified.

 from the desciption, I would need to add -lgcc_s, etc.  Is there a
 less extreme option to only override kernel32, advapi, etc.?

 Thank you,

 Chris

 --
 Chris Sutcliffe
 http://emergedesktop.org
 http://www.google.com/profiles/ir0nh34d


Well, this is a bit too much. Just make sure you specify on command
line (at end, or before -lkernel32 - if you specify it - the option
-ladvapi32. You can file a bug report for gcc, so I don't miss to
modify it for 4.6.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Canadian cross still broken?

[Kai Tietz]

2010/9/5 İsmail Dönmez ism...@namtrac.org:
 Hi all;

 Today I was trying to do a canadian cross build of mingw-w64 on Snow
 Leopard. I am using the instructions in the wiki but the gcc failed to
 compiled with an error, that was already reported here [0].

 I didn't try a non-multilib build (yet) but I wonder if multilib is
 broken or canadian cross is still broken in the trunk.

 Used gcc 4.5 from the stable branch and mingw-w64 from trunk.

 [0] http://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg00839.html

 Regards,
 ismail

Hmm, as I see in this report has binutils not being configure to
support pe-i386 targets (see here our Wiki page about multilib - it
needs additional arguments for doing this).
By fixing this, you should be able to build a multilib cross-compiler.

Regards,
Kai
-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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?

[Kai Tietz]

2010/9/5 İsmail Dönmez ism...@namtrac.org:
 Hi,

 On Sun, Sep 5, 2010 at 11:26 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Well, as you see in your dump of ld i386pep which means that ld
 supports x86_64 output. In ld (and some other tools of binutils) the
 naming of target is different.

 So you should have a binutils version which is capable to build 32-bit
 and 64-bit code.

 Ok, then it shouldn't fail right?

 See 
 http://sourceforge.net/apps/trac/mingw-w64/wiki/Answer%20Multilib%20Toolchain
 for some FAQ about this subject.

 Do I need --enable-multilib --enable-version-specific-runtime-libs,
 because 
 http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler
 does not mention it. Also --sysroot is mandatory for multilib?

Well, for multilib you get two different sets of runtime-libraries
installed (by gcc and by our crt). Therefore to avoid conflicts
between those two sets we recomment to use
--enable-version-specific-runtime-libs. The --enable-multilib isn't
absolutely necessary as it is on by default for gcc (at least for
4.5.1 and higher), but for completeness I would always specify it on
configure line.
It has some advantages to use sysroot (and this option we describe in
single targeted cross-compiler howto, too), as it leads in combination
with --prefix to a relocatable toolchain. This means, you can copy the
sysroot-folder (the past folder specified - eg
--with-sysroot=/opt/mingww64, then mingww64 is the sysroot-folder) to
any location without the need of rebuilding it.

Kai



-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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?

[Kai Tietz]

2010/9/5 İsmail Dönmez ism...@namtrac.org:
 Hi there;

 On Sun, Sep 5, 2010 at 11:45 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/9/5 İsmail Dönmez ism...@namtrac.org:
 Hi,

 On Sun, Sep 5, 2010 at 11:26 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Well, as you see in your dump of ld i386pep which means that ld
 supports x86_64 output. In ld (and some other tools of binutils) the
 naming of target is different.

 So you should have a binutils version which is capable to build 32-bit
 and 64-bit code.

 Ok, then it shouldn't fail right?

 See 
 http://sourceforge.net/apps/trac/mingw-w64/wiki/Answer%20Multilib%20Toolchain
 for some FAQ about this subject.

 Do I need --enable-multilib --enable-version-specific-runtime-libs,
 because 
 http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler
 does not mention it. Also --sysroot is mandatory for multilib?

 Well, for multilib you get two different sets of runtime-libraries
 installed (by gcc and by our crt). Therefore to avoid conflicts
 between those two sets we recomment to use
 --enable-version-specific-runtime-libs. The --enable-multilib isn't
 absolutely necessary as it is on by default for gcc (at least for
 4.5.1 and higher), but for completeness I would always specify it on
 configure line.
 It has some advantages to use sysroot (and this option we describe in
 single targeted cross-compiler howto, too), as it leads in combination
 with --prefix to a relocatable toolchain. This means, you can copy the
 sysroot-folder (the past folder specified - eg
 --with-sysroot=/opt/mingww64, then mingww64 is the sysroot-folder) to
 any location without the need of rebuilding it.

 I tried --enable-multilib too; but here is the same error :

 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: skipping incompatible
 /usr/local/mingw64/x86_64-w64-mingw32/lib/libmingw32.a when searching
 for -lmingw32
 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: skipping incompatible
 /usr/local/mingw64/x86_64-w64-mingw32/lib/libmingw32.a when searching
 for -lmingw32
 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: skipping incompatible
 /usr/local/mingw64/mingw/lib/libmingw32.a when searching for -lmingw32
 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: skipping incompatible
 /usr/local/mingw64/mingw/lib/libmingw32.a when searching for -lmingw32
 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: skipping incompatible
 /usr/local/mingw64/x86_64-w64-mingw32/lib/libmingw32.a when searching
 for -lmingw32
 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: skipping incompatible
 /usr/local/mingw64/x86_64-w64-mingw32/lib/libmingw32.a when searching
 for -lmingw32
 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: skipping incompatible
 /usr/local/mingw64/x86_64-w64-mingw32/lib/libmingw32.a when searching
 for -lmingw32
 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: skipping incompatible
 /usr/local/mingw64/mingw/lib/libmingw32.a when searching for -lmingw32
 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: skipping incompatible
 /usr/local/mingw64/x86_64-w64-mingw32/lib/libmingw32.a when searching
 for -lmingw32
 /usr/local/mingw64/x86_64-w64-mingw32/bin/ld: cannot find -lmingw32

 So ld does not find;

 /usr/local/mingw64/x86_64-w64-mingw32/lib32/libmingw32.a

 which is supposed to be the 32bit one.

 Regards,
 ismail


Well, have you build and installed headers and crt after initial gcc
bootstrap? Have you added new sys-root/bin folder to you path before
building crt?

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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?

[Kai Tietz]

2010/9/5 İsmail Dönmez ism...@namtrac.org:
 Hi;

 On Sun, Sep 5, 2010 at 11:56 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Well, have you build and installed headers and crt after initial gcc
 bootstrap? Have you added new sys-root/bin folder to you path before
 building crt?

 Yes, I did actually. The gcc fails in the second time which I do after
 installing crt.

 Regards,
 ismail


Could you please show me your configure line you used for crt.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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?

[Kai Tietz]

2010/9/5 İsmail Dönmez ism...@namtrac.org:
 Hi;

 On Mon, Sep 6, 2010 at 12:08 AM, Kai Tietz ktiet...@googlemail.com wrote:
 Could you please show me your configure line you used for crt.

 ../configure --host=x86_64-w64-mingw32 --enable-lib32
 --prefix=/usr/local/mingw64

 Thanks,
 ismail


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.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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?

[Kai Tietz]

Hi,

just for getting you right. Does initial cross-compiler fails, or then
the build of the canadian cross based on this cross-compiler?

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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 configuringwxWidgets-2.9.1 withTDM64-GCC 4.5.1

[Kai Tietz]

2010/9/6 Bidski bid...@bigpond.net.au:
 Is there a reason why strnlen has been excluded thusly?

 Regards
 Bidski



Hmm, not sure. I think it was due an issue in building bootstrap, but
I can't recall it.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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 configuringwxWidgets-2.9.1 withTDM64-GCC 4.5.1

[Kai Tietz]

2010/9/6 Ozkan Sezer seze...@gmail.com:
 On Mon, Sep 6, 2010 at 6:35 PM, John E. / TDM tdra...@tdragon.net wrote:
  On 9/6/2010 6:14 AM, Ozkan Sezer wrote:

 strnlen doesn't exist in msvcrt.dll from x86-winxp

 we can implement it roughly like:

 size_t __cdecl strnlen (const char *s, size_t maxlen)
 {
   size_t siz = __builtin_strlen(s);
   if (siz  maxlen) siz = maxlen;
   return siz;
 }

 This is not a good implementation of strnlen. The purpose of using strnlen
 is to avoid reading past the end of a buffer of known size --

 Quote from
 http://msdn.microsoft.com/en-us/library/z50ty2zh%28VS.80%29.aspx:
 *

 *strnlen* is not a replacement for *strlen*; *strnlen* is only intended to
 be used to calculate the size of incoming untrusted data in a buffer of
 known size (such as a network packet). *strnlen* will calculate the length
 but not walk past the end of your buffer if the string is unterminated.

 *
 Here is a correct (albeit slightly less performant than assembly) strnlen
 implementation:

 size_t strnlen(const char* s, size_t maxlen)
 {
  const char* s2 = s;
  while (s2 - s  maxlen  *s2)
    ++s2;
  return s2 - s;
 }

 Note that this is in accordance with MS' implementation:

 However, *strnlen* and *strnlen_l* interpret the string as a single-byte
 character string, so its return value is always equal to the number of
 bytes, even if the string contains multibyte characters.

 -John E. / TDM


 Kai, OK I guess?


Yep, is ok. Maybe we can do here later an assembly implementation for
this, but well first comes correct behavior before speed.

Thanks,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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] Fails to build....

[Kai Tietz]

2010/9/8 Dmitrijs Ledkovs dmitrij.led...@ubuntu.com:
 x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. 
 -I/build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt  -m64 
 -D_SYSCRT=1 -DCRTDLL=1 
 -I/build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/include
  -D_CRTBLD 
 -I/build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/x86_64-w64-mingw32/include
    -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow 
 -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn 
 -Wmissing-prototypes 
 -I/build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/x86_64-w64-mingw32/include
  -MT crt/lib64_libmingw32_a-gs_support.o -MD -MP -MF 
 crt/.deps/lib64_libmingw32_a-gs_support.Tpo -c -o 
 crt/lib64_libmingw32_a-gs_support.o `test -f 'crt/gs_support.c' || echo 
 '/build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/'`crt/gs_support.c
 /build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/crt/gs_support.c:27:
  error: conflicting types for 'RtlLookupFunctionEntry'
 /build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/include/winnt.h:2375:
  note: previous declaration of 'RtlLookupFunctionEntry' was here
 /build/buildd/w64-toolchain-1.0b+201009080043/upstream/mingw-w64-crt/crt/gs_support.c:28:
  error: conflicting types for 'RtlVirtualUnwind'
 /build/buildd/w64-toolchain-1.0b+201009080043/x86_64-w64-mingw32/root/usr/lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/include/winnt.h:2413:
  note: previous declaration of 'RtlVirtualUnwind' was here


 Full log at
 http://launchpadlibrarian.net/55185586/buildlog_ubuntu-lucid-amd64.w64-toolchain_1.0b%2B201009080043-0w2176g93802b21973p11~lucid1_FAILEDTOBUILD.txt.gz

 Time 201009080043
 Mingw-w64 trunk bzr 2176 = svn trunk 3526
 Gcc 4.4 branch @ commit from ibolton (daily dump 20100908)
 Binutils daily dump @ 2010908


 --
 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


Issue fixed at revision 3529.

Sorry,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
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