Re: [Mingw-w64-public] Debugging broken executable that does not even start

2014-04-03 17:53 GMT+02:00 LRN : > No. > crtexe.c:332 is the call to main(). What happens if you put a > breakpoint on main()? > > Is dot.exe (at least) built with -g? -O0? Obviously, -g -O0 is much > easier to debug. > > The main was not being called but thanks to your insights I have disabled th

Re: [Mingw-w64-public] clang and mingw

G M 2014-04-04 02:15: > Hi Everyone Hi, > I thought someone here might want to know about that. I am using a > mingw > 4.8.2 ruben build from 2013 (I think). Firstly, please provide the link to used build. -- Regards, niXman ___ Dual-target(32 &

Re: [Mingw-w64-public] Mass rebuild report for April 03 2014 (using gcc 4.9)

d: 3 minutes, 25 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20140403/mingw-cairo-1.12.16-1 > undefined ref to cairo_*, bad update? > mingw-gstreamer-plugins-base-0.10.36-4 > ** Package failed to build while it succeeded during the previous mass &

[Mingw-w64-public] clang and mingw

Hi Everyone A recent change to clang has begun considering a header in mingw as defective. The header appears to be re-declaring functions with different attributes. I thought someone here might want to know about that. I am using a mingw 4.8.2 ruben build from 2013 (I think). Sorry if the situ

[Mingw-w64-public] Mass rebuild report for April 03 2014 (using gcc 4.9)

This is a report for the 20140403 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. In this iteration of the mass rebuild the latest gcc 4.9 snapshot was used. As the previous mass rebuild was

Re: [Mingw-w64-public] Debugging broken executable that does not even start

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.04.2014 19:41, Damian Kaczmarek wrote: > 2014-04-03 17:21 GMT+02:00 LRN : > >> What's the exit code of the program? Create a batch file (on >> Windows) with these two lines: >> > The exit code was invalid -257332231 or something. > > >> Or ju

Re: [Mingw-w64-public] Debugging broken executable that does not even start

2014-04-03 17:21 GMT+02:00 LRN : > What's the exit code of the program? Create a batch file (on Windows) > with these two lines: > The exit code was invalid -257332231 or something. > Or just run under gdb. > $ gdb dot.exe GNU gdb (GDB) 7.6.1 Copyright (C) 2013 Free Software Foundation, Inc. Li

Re: [Mingw-w64-public] Determining whether mingw dll is a debug build based on PE structure?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.04.2014 18:23, Koehne Kai wrote: > On 03.04.2014 LRN wrote: >> On 03.04.2014 14:42, Koehne Kai wrote: >>> Hi, >>> >>> Anyone knows by heart what to check for in a PE header to >>> decide whether a dll is a debug build, or not? >>> >>> Backgroun

Re: [Mingw-w64-public] Debugging broken executable that does not even start

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.04.2014 18:04, Damian Kaczmarek wrote: > Dear MinGW users, I am struggling to compile Graphviz using > Mingw-64 (built using the MXE toolchain compiler, under Linux) with > a 32-bit variant. When I have finally managed to compile all > libraries

Re: [Mingw-w64-public] Determining whether mingw dll is a debug build based on PE structure?

> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03.04.2014 14:42, Koehne Kai wrote: > > Hi, > > > > Anyone knows by heart what to check for in a PE header to decide > > whether a dll is a debug build, or not? > > > > Background: Qt has a neat tool to package all of the Qt/non qt > > depen

Re: [Mingw-w64-public] Determining whether mingw dll is a debug build based on PE structure?

> -Original Message- > From: TOCK [mailto:tock.c...@gmail.com] > Sent: Thursday, April 03, 2014 12:59 PM > To: mingw-w64-public@lists.sourceforge.net > Subject: Re: [Mingw-w64-public] Determining whether mingw dll is a debug > build based on PE structure? > > I think you can use objdump

[Mingw-w64-public] Debugging broken executable that does not even start

Dear MinGW users, I am struggling to compile Graphviz using Mingw-64 (built using the MXE toolchain compiler, under Linux) with a 32-bit variant. When I have finally managed to compile all libraries and linked to the final executable I find that the executable simply does not run when started with

Re: [Mingw-w64-public] Determining whether mingw dll is a debug build based on PE structure?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.04.2014 14:42, Koehne Kai wrote: > Hi, > > Anyone knows by heart what to check for in a PE header to decide > whether a dll is a debug build, or not? > > Background: Qt has a neat tool to package all of the Qt/non qt > dependencies together for

Re: [Mingw-w64-public] Determining whether mingw dll is a debug build based on PE structure?

I think you can use objdump to determine it. For example on my PC: C:\Users\TOCK>objdump -f foo.dll foo.dll: file format pei-x86-64 architecture: i386:x86-64, flags 0x013b: HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED start address 0x6ae81400 2014-04-03 18:42 GMT

[Mingw-w64-public] Determining whether mingw dll is a debug build based on PE structure?

Hi, Anyone knows by heart what to check for in a PE header to decide whether a dll is a debug build, or not? Background: Qt has a neat tool to package all of the Qt/non qt dependencies together for deployment: windeployqt. To function properly, it has to decide whether an executable/dll is a d