Re: [Mingw-w64-public] mingw/gcc stralign.h

2013-08-10 Thread Alexey Pavlov 
2013/8/10 JonY 

> On 8/10/2013 11:47, G M wrote:
> > Hi
> >
> > Just to correct my previous message, the alternative stralign.h I
> > found doesn't work for me after all when building Ninja, I made a mistake
> > building it before to think it did work.
> >
> > So the diff I provided for further info in my previous message may not be
> > that useful
> >
> > So to recap, I'm using stralign.h from here:
> >
> http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/64-bit/threads-win32/seh/
> > that fails on stralign.h:
> >
> > #ifndef __CRT__NO_INLINE
> >   __CRT_INLINE PUWSTR_C ua_wcschr(PCUWSTR String,WCHAR Character) {
> > if(WSTR_ALIGNED(String)) return ::wcschr((PCWSTR)String,Character);
> > return (PUWSTR_C)uaw_wcschr(String,Character);
> >   }
> >   __CRT_INLINE PUWSTR_C ua_wcsrchr(PCUWSTR String,WCHAR Character) {
> > if(WSTR_ALIGNED(String)) return ::wcsrchr((PCWSTR)String,Character);
> > return (PUWSTR_C)uaw_wcsrchr(String,Character);
> >   }
> >
> > I added the :: characters above to make Ninja compile, but I doubt that
> is
> > the right fix even it works or appears to.
> >
> > If there exists a "latest" release of these files, please give me a full
> > link to where and I'll try them and report back.
> >
>
> As suggested earlier, it is on SVN, if you bothered to ask google:
> <
> http://svn.code.sf.net/p/mingw-w64/code/trunk/mingw-w64-headers/include/stralign.h
> >
>

Our (mingw-builds) toolchains use mingw-w64 runtime from trunk already.
GCC-4.8.1-rev3 has runtime from 5973 revision.


>
> > Alternatively, if anyone else want's to try to build Ninja on github with
> > libcxx and clang++ using the same mingw's C headers I am using,
> > then they should see the same conflict I am seeing with libcxx's headers
> > and mingw's stralign.h that I'd like to fix.
> >
> > note: candidate function
> >   _CONST_RETURN wchar_t *__cdecl wcschr(const wchar_t *_Str,wchar_t _Ch);
> >  ^
> > /libcxx/include\cwchar:180:49: note: candidate function
> > inline _LIBCPP_INLINE_VISIBILITY const wchar_t* wcschr(const wchar_t*
> __s,
> > wchar_t __c) {return ::wcschr(__s, __c);}
> > ^
> > In file included from src\build.cc:33:
> > In file included from src/subprocess.h:25:
> > In file included from
> >
> c:\mingw\bin\..\lib\clang\3.4\../../../x86_64-w64-mingw32/include\windows.h:114:
> >
> c:\mingw\bin\..\lib\clang\3.4\../../../x86_64-w64-mingw32/include\stralign.h:120:37:
> > error: call to 'wcsrchr' is ambiguous
> > if(WSTR_ALIGNED(String)) return wcsrchr((PCWSTR)String,Character);
> > ^~~
> >
> c:\mingw\bin\..\lib\clang\3.4\../../../x86_64-w64-mingw32/include\wchar.h:851:34:
> > note: candidate function
> >   _CONST_RETURN wchar_t *__cdecl wcsrchr(const wchar_t *_Str,wchar_t
> _Ch);
> >  ^
>
> Likely a conflict with libcxx, libgcxx cwchar too has cwchar defined.
>
> I cannot reproduce the error with GCC, please write a minimalist test
> case to demonstrate the error.
>
> GCC test:
> #include 
> #include 
> #include 
>
> int f(){
>   ua_wcsrchr(0,0);
>   ua_wcsrchr((const wchar_t *)0,0);
>   ua_wcsrchr((const wchar_t __unaligned *)0,0);
>   return 0;
> }
>
>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Usability improvement: add debug breaks to abort() calls

2013-08-10 Thread Erik van Pienbroek 
LRN schreef op do 08-08-2013 om 12:23 [+0400]:
> This is mostly a usability change. I, personally, really don't like when
> a program i'm debugging suddenly dies for no reason.
> 
> Opinions?

I would really welcome such a change. In the past we've already stumbled
across this issue with Qt5 (and was reported to this list [1]). Some
days ago also a GTK3 crash was reported to us Fedora maintainers which
can't be caught with gdb [2].

[1]: http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/6739
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=995059

Regards,

Erik van Pienbroek



--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] linking issue with postgresql and curl

2013-08-10 Thread Erik van Pienbroek 
Kai Tietz schreef op do 08-08-2013 om 15:49 [+0200]:
> Hmm, not necessarily a gcc bug.  It might be simply that the dll
> itself has dependencies to other dll-files.
> Try to check by dependency-walker tool, or via the objdump tool, what
> other DLL-files might be referenced.
> 
> Most likely it is an issue about libgcc.dll file.

Hey Kai,

I've reproduced the issue Michael is talking about. When the testcase is
opened in dependency walker it indicates that it has direct dependencies
on libcurl-4.dll and libpq.dll (as expected). Initially everything looks
as expected. However, when I try to execute the testcase using
dependency walker then it shows that an additional dependency is
introduced for a library named ''. The dependency walker
console shows this output:

==

Error: At least one module has an unresolved import due to a missing
export function in an implicitly dependent module.


Starting profile on 8/10/2013 at 3:10:43 PM

Operating System: Microsoft Windows XP Professional (64-bit), version
5.01.2600 Service Pack 3
Program Executable: z:\home\erik\LIBPQTEST.EXE
Program Arguments: 
Starting Directory: Z:\home\erik\
Search Path: C:\windows\system32;C:\windows;C:\windows\system32\wbem

Options Selected:
 Simulate ShellExecute by inserting any App Paths directories into
the PATH environment variable.
 Log DllMain calls for process attach and process detach messages.
 Hook the process to gather more detailed dependency information.
 Log LoadLibrary function calls.
 Log GetProcAddress function calls.
 Log debug output messages.
 Automatically open and profile child processes.


Started "LIBPQTEST.EXE" (process 0x25) at address 0x0040.  Cannot
hook module.
Error writing a breakpoint at the entrypoint return of "KERNEL32.DLL".
Entrypoint cannot be hooked. Access denied (5).
Error reading KERNEL32.DLL's export table.  Function call tracking may
not work properly. Access denied (5).
Loaded "KERNEL32.DLL" at address 0x7B81.  Cannot hook module.
Error reading the DOS header of "NTDLL.DLL".  Virtual size of module
cannot be determined. Access denied (5).
Error reading the PE headers of "NTDLL.DLL".  Entrypoint address cannot
be determined. Access denied (5).
Loaded "NTDLL.DLL" at address 0x7BC1.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x7ECD.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x7EC3.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x6CEC.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x7EB1.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x7EFF.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x7E9C.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x7E98.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x6508.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x6300.  Cannot hook module.
Error reading the DOS header of "".  Virtual size of module cannot be
determined. Access denied (5).
Error reading the PE headers of "".  Entrypoint address cannot be
determined. Access denied (5).
Loaded "" at address 0x6394.  Cannot hook module.
Error reading the DOS head

Re: [Mingw-w64-public] Usability improvement: add debug breaks to abort() calls

2013-08-10 Thread Martin Mitáš 
>
> The difference between using abort() and using a debug break is that
> debug break, if it goes unhandled, won't print the usual "requrested to
> terminate blahblahblah" stuff, and the exception code that WER shows
> will change from 0x4015 to 0x8003.

That would mean that when not under debugger, user would have no idea 
what has happened and why his process just disappeared. I recommend to 
use __debugbreak()/DebugBreak() only when being debugged. Fortunately, 
Win32API has a function for detecting that:

if(IsDebuggerPresent())
   __debugbreak();
else
   abort();

(I use similar construction in my assert-like macros for my projects and 
I can confirm it really makes my debugging experience much easier.)

Morous

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Usability improvement: add debug breaks to abort() calls

2013-08-10 Thread LRN 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10.08.2013 17:25, Martin Mitáš wrote:
>>
>> The difference between using abort() and using a debug break is that
>> debug break, if it goes unhandled, won't print the usual "requrested to
>> terminate blahblahblah" stuff, and the exception code that WER shows
>> will change from 0x4015 to 0x8003.
> 
> That would mean that when not under debugger, user would have no idea 
> what has happened and why his process just disappeared. I recommend to 
> use __debugbreak()/DebugBreak() only when being debugged. Fortunately, 
> Win32API has a function for detecting that:
> 
> if(IsDebuggerPresent())
>__debugbreak();
> else
>abort();
> 
> (I use similar construction in my assert-like macros for my projects and 
> I can confirm it really makes my debugging experience much easier.)

1) abort() is not very informative either (no stack trace, no nothing).
2) Reproducing the output that abort() produces is not a problem (just
print some text - how hard could it be?)
3) One could even add useful data (replace plain abort() call with
printf-with-explicit-reason-for-aborting + abort(); or add backtraces,
or both, although backtraces might require support code that's too big -
getting backtraces outside of gdb on W32 proved to be unusually difficult).

IsDebuggerPresent() is used by glib that way in some places.

Dunno, it's probably ok to do the IsDebuggerPresent().

That said, ktietz pointed out that all of that might be problematic when
developing for restricted W32 API subsets.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJSBkXIAAoJEOs4Jb6SI2CwC8kH/1jkMkyzSMkoVSV/ZuVzM6bI
J1mVgALIhmHRjjiCTubIB5Qyctth2LySv0sMb3iXNKe7E6yhhMAhhaLhAewaozBE
mBXxmsJ7Rg09QJ+d2kQFirMQVJbwvtf5CEJoS+hG4qlTHUdK0aGO7TAqc00ePql6
sjXlecVa8aMb8nKBi7QX4QgBDYLrg2cbzKYucVA4Is82Yx0JitS8M57k0GwlIcei
H6eZinrpu61Q6Ep/B2V6jd4IrhDzeCQiw4IIyO5qs6SpFHSNBg1dAEFSNvvLSoXT
7EEQo5dP/kCu9wl7n2Dymm4MiXMVvU9Dx4v1tDOqcI5Ak8U3v/6WEuG+OPkbugw=
=NJun
-END PGP SIGNATURE-

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Fwd: ERR_remove_thread_state not found in LIBEAY32.dll with mingw-w64

2013-08-10 Thread K. Frank 
Hi List!

I'm taking the liberty of cross-posting this curl-lib question to
mingw64.  (I believe this post is awaiting moderation over on
curl-lib.)  I do see a fair amount of mingw-w64-specific libcurl
discussion on this list, so maybe somebody can help me out.

-- Forwarded message --
From: K. Frank <>
Date: Fri, Aug 9, 2013 at 8:48 PM
Subject: ERR_remove_thread_state not found in LIBEAY32.dll with mingw-w64
To: curl-library


Hello List!

I am new to libcurl, and am trying to use it with mingw-w64.

I have written an compiled a very simple test program and when I run it
I get a windows pop-up message box that says:

   Entry Point Not Found

   The procedure entry point ERR_remove_thread_state could not
   be located in the dynamic library LIBEAY32.dll

Some details:

My program is technically c++, and contains a single call to
curl_global_init (CURL_GLOBAL_ALL);

It seems to compile and link correctly:

   g++ -g -o libcurl_test libcurl_test.cpp -lcurldll

I am pretty sure that I have the proper include and lib directories set up
for building my test app and have the proper bin directory in my path
when attempting to run it.

It is worth noting that the command line curl.exe (that came with the libcurl
download) does run without error, e.g.,

   curl --version

   curl 7.31.0 (x86_64-pc-win32) libcurl/7.31.0 OpenSSL/1.0.0k
zlib/1.2.8 WinIDN libssh2/1.4.3 librtmp/2.3
   Protocols: dict file ftp ftps gopher http https imap imaps ldap
pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
   Features: AsynchDNS GSS-Negotiate IDN Largefile NTLM SSL SSPI libz

The version I am using I downloaded from http://curl.haxx.se/download.html,
from the Win64 - MinGW64 section.  I downloaded the devel package:

   curl-7.31.0-devel-mingw64.7z

and unzipped it.

I have seen some comments that made it sound like  ERR_remove_thread_state
is new or deprecated or something, and that having a version mismatch between
libcurl and libssl could cause this problem.  But I believe I am using
libcurl and
libssl both from curl-7.31.0-devel-mingw64.7z, so I would imagine that they are
consistent.

Note, I did not build libcurl myself with mingw-w64, so there could be
a mismatch
between the libcurl compiler and the version I am using, but I don't
see how that
kind of thing could cause this specific problem.

I am using mingw-w64 g++ 4.8.1, downloaded as:

   x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb.7z

and running 64-bit windows 7.


Thanks for any advice.


K. Frank

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingwbuilds-users] vsnprintf / snprintf problem with GCC 4.7.2 and 4.7.3 (rubenvb and mingw-builds)

2013-08-10 Thread Derek Buitenhuis 
On 8/1/2013 11:12 AM, Luis Lavena wrote:
> It is not clear for me why mingw.org  (GCC 4.7.2) does 
> works while mingw-w64 (GCC 4.7.2 and 4.7.3) produces the failure.

A hunch: 
 
Have you tried defining __USE_MINGW_ANSI_STDIO?

See, for example: 
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=8bdbabfaa46989b1a0e82d2df0a27df32277294d

- Derek


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ERR_remove_thread_state not found in LIBEAY32.dll with mingw-w64

2013-08-10 Thread K. Frank 
Hi Daniel!

Thank you.  You've jostled me in the right direction.

The short story is that I didn't realize that I have other copies of
libeay32.dll on my system, ahead of libcurl's in my path  More
details appear below.

(I've cross-posted this to mingw64, because I cross-posted my
original message there, and didn't want to leave it hanging open.)

On Sat, Aug 10, 2013 at 2:49 PM, Daniel Stenberg  wrote:
> On Fri, 9 Aug 2013, K. Frank wrote:
>
>> I have written an compiled a very simple test program and when I run it I
>> get a windows pop-up message box that says:
>>
>>   Entry Point Not Found
>>
>>   The procedure entry point ERR_remove_thread_state could not
>>   be located in the dynamic library LIBEAY32.dll
>
> This happens when you've built libcurl against OpenSSL >= 1.0.0 while it
> finds an older version at run-time.

Yes, I am finding the wrong version of libeay32.dll at run-time.
(Although I did not build libcurl myself, but simply used what I
downloaded.)

>> It is worth noting that the command line curl.exe (that came with the
>> libcurl download) does run without error
>
> Then it finds the correct DLL at run-time when you invoke curl!

Yes it does, because the right version of libeay32.dll is in the same
bin directory as curl.exe.

>> I have seen some comments that made it sound like ERR_remove_thread_state
>> is new or deprecated or something, and that having a version mismatch
>> between libcurl and libssl could cause this problem.  But I believe I am
>> using libcurl and libssl
>
> libssl perhaps, but the error message clearly said LIBEAY32.dll...

Thanks for emphasizing that I should be focusing my attention on
libeay32.dll.

The detailed explanation is that I didn't recognize the library
libeay32.dll, and therefore wrongly assumed that is was specific
to curl / libcurl, and therefore it didn't occur to me that I might
have other versions of it on my system.

But I do.  I ran "where libeay32.dll" (the windows version of the unix
"which" command), and, sure enough, I have copies in intel wireless
and openvpn stuff that appear in my path.  I had added the libcurl
bin to the end of my path, so these took precedence (except when
running curl.exe itself, which first finds the correct libeay32.dll in
its own directory before searching the path).

So I re-ran my simple test program after adding libcurl's bin directory
to the front of my path, and now it runs fine (but, as expected, doesn't
do anything).

Now on to a program that actually does something ...

>  / daniel.haxx.se


Thanks again for your help.


K. Frank

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingwbuilds-users] vsnprintf / snprintf problem with GCC 4.7.2 and 4.7.3 (rubenvb and mingw-builds)

2013-08-10 Thread Luis Lavena 
On Sat, Aug 10, 2013 at 4:31 PM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 8/1/2013 11:12 AM, Luis Lavena wrote:
> > It is not clear for me why mingw.org  (GCC 4.7.2)
> does works while mingw-w64 (GCC 4.7.2 and 4.7.3) produces the failure.
>
> A hunch:
>
> Have you tried defining __USE_MINGW_ANSI_STDIO?
>
> See, for example:
> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=8bdbabfaa46989b1a0e82d2df0a27df32277294d
>
>
Thank you Derek, your hunch was correct and the libgit2 guys already
implemented this fix for the MinGW build and using mingw-w64.

What was not clear to me is precisely when this become a required change,
but is clear this is documented in the wiki now.

Thank you.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public