mingw-users

[Mingw-users] Help - App works under gdb but fails when directly executing it

[Chander M A. <cha...@sa...>]

Hi,

Help! I am seeing a strange problem using MinGW (first project with
mingw) and maybe someone can easily recognize what i have / haven't done
right. I am moving an app from MSVC to MinGW...

Problem:

 After compilation & linking in IDE --> in a DOS window, i can use gdb
to load and run (or step thru) the program as expected (Program exits
normally).

However if i directly start the program at the prompt it immediately
quits with a windows Application error popup and the message "the
instruction at 0x7c911404 referenced memory at 0xfffffff8. the memory
cannot be "read".

Environment:   I installed the MinGWStudio full IDE package and am
building using that. The various versions of mingw included by this
package install were:
  gcc 3.3.1
  binutils  2.14.90
  mingw-runtime  3.2
  w32api 2.4
  gdb 6.0
  gnu make 3.80.0

The link line is:

gcc -o <list of object.o files> -L. -lbgd -lxml2

bgd.dll  is in the same directory as executable when running app and
   i created the libbgd.a import lib and def file etc. using info on the
   web
xml i got came as libxml2.a already and seems to satisfy the linker

The linked application (0 errors) runs from within the IDE or within gdb
from the command line, but fails when executed directly. I was expecting
mingw to produce "native" Win32 apps that could execute off cmd line ?
true ?? Is this possibly something due to the MinGWStudio IDE ??

My application doesn't use any Windows API (slated as a web CGI
eventually).

[
As a side-note:
 - I also had problems putting all the object code into a "Static
library" (project type per MingGWStudio) as there were interlibrary
"undefined references" generated altho the libs were in correct order on
the command line (caller first). -  anyhow, currently all the objects
are listed on the link command line itself s given above.
I want to compile & link it statically (as far as possible), but right
now i cannot even get it working standalone.

 - the IDE's exported Makefile does not run as-is but i think thats
probably because i do not have MSYS installed on my system (the
/ and \  in filenames is the first issue...) - and i haven't got
to change it and use it for compiling without IDE yet (linking works).

end-sidenote]

Any ideas, suggestions and "u newbie - you forgot to ....." comments are
all welcome (...i am a newbie with mingw, but been using gcc on *nix for
years)


Thanks in advance for responding.

-chander
PS>> Is anyone using / supporting MinGWStudio (no mailing list) ? Anyone
recommend another IDE thats easy to setup and provide a better fit to
mingw and is actively used by community...and most importantly produce
an executable that will execute natively with no dll's etc to accompany
the exe.

Re: [Mingw-users] Help - App works under gdb but fails when directly executing it

[Greg C. <chi...@co...>]

On 2007-08-11 04:49Z, Chander M Ahuja wrote:
> 
>  After compilation & linking in IDE --> in a DOS window, i can use gdb
> to load and run (or step thru) the program as expected (Program exits
> normally).
> 
> However if i directly start the program at the prompt it immediately
> quits with a windows Application error popup and the message "the
> instruction at 0x7c911404 referenced memory at 0xfffffff8. the memory
> cannot be "read".

Program seems to run fine under gdb, but crashes when run
outside the debugger--see:
  http://lists-archives.org/mingw-users/06091-baadf00d.html
for ways to track down the problem.

> Environment:   I installed the MinGWStudio full IDE package and am
> building using that. The various versions of mingw included by this
> package install were:
>   gcc 3.3.1
>   binutils  2.14.90

That would seem to be several years old. I believe there's
a problem either in your program or in one of the third-
party libraries you're using, and updating the toolchain
isn't the answer to that problem, but it is a good idea for
other reasons.

> The linked application (0 errors) runs from within the IDE or within gdb
> from the command line, but fails when executed directly. I was expecting
> mingw to produce "native" Win32 apps that could execute off cmd line ?

If you built it with MinGW tools, then it's a native msw app.
It does run from the command line; it just doesn't run as
expected, presumably because of some defect that's masked
by running it under gdb.

[snip "MinGWStudio" issues]

> PS>> Is anyone using / supporting MinGWStudio (no mailing list) ? Anyone

Searching my local archives (which I think are complete)
for "MinGWStudio", I find:
  1 message in 2007 (yours)
  0 messages in 2006
  2 messages in 2005

> recommend another IDE thats easy to setup and provide a better fit to
> mingw and is actively used by community...

My impression is that most people here aren't using any IDE.

> and most importantly produce
> an executable that will execute natively with no dll's etc to accompany
> the exe.

There are two different concepts here. If you were using
Cygwin gcc, you'd produce programs that require the Cygwin
dll, which includes a C runtime different from the one
provided "natively" by msw. Using MinGW gcc, you produce
programs that use the C runtime provided as part of msw,
and we might say that a MinGW app runs "natively" in that
sense. That's what this page
  http://mingw.org/
means when it says MinGW produces "native Windows programs
that do not rely on any 3rd-party C runtime DLLs."

But a "native" program can require other dlls, some of which
may not be part of the OS. You say you're using 'bgd.dll',
so that has to accompany your program. "Native" doesn't
mean that no dlls are required.

Re: [Mingw-users] Help - App works under gdb but fails when directly executing it

[Chander M A. <cha...@sa...>]

Thanks for the response.

 I tried to update the compiler & tools by pointing the IDE at the
separately installed MinGW ("Candidate" using 5.1.3 installer)

 Now, it immediately fails under gdb as well with another
message that doesn't help me - but maybe someone has seen it before.

=============
C:\Dev4\libs>gdb equipoisedbg.exe
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
...[snip]....
This GDB was configured as "i686-pc-mingw32"...

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

============

Greg Chicares wrote:
see:
>   http://lists-archives.org/mingw-users/06091-baadf00d.html
> for ways to track down the problem.

...thanks - i'm reading through this thread and there are some things i
will try...

> 
> That would seem to be several years old. I believe there's
> a problem either in your program or in one of the third-
> party libraries you're using, and updating the toolchain
> isn't the answer to that problem, but it is a good idea for
> other reasons.
> 
Tried updating to the "candidate" version of MinGW but it stopped
working completely See above.
> 
> If you built it with MinGW tools, then it's a native msw app.
> It does run from the command line; it just doesn't run as
> expected, presumably because of some defect that's masked
> by running it under gdb.

fair enough. I was using the phrase "native..." in some vague manner. My
apologies.

>>PS>> Is anyone using / supporting MinGWStudio (no mailing list) ? Anyone
> 
> 
> Searching my local archives (which I think are complete)
> for "MinGWStudio", I find:
>   1 message in 2007 (yours)
>   0 messages in 2006
>   2 messages in 2005
The Linux version of studio was updated summer/06 however the Windows
version is 05 or earlier...

>>and most importantly produce
>>an executable that will execute natively with no dll's etc to accompany
>>the exe.
> 
> 
> There are two different concepts here. If you were using
> Cygwin gcc, you'd produce programs that require the Cygwin
> dll, which includes a C runtime different from the one
> provided "natively" by msw. Using MinGW gcc, you produce
> programs that use the C runtime provided as part of msw,
> and we might say that a MinGW app runs "natively" in that
> sense. That's what this page
>   http://mingw.org/
> means when it says MinGW produces "native Windows programs
> that do not rely on any 3rd-party C runtime DLLs."
> 
> But a "native" program can require other dlls, some of which
> may not be part of the OS. You say you're using 'bgd.dll',
> so that has to accompany your program. "Native" doesn't
> mean that no dlls are required.

You are right.
My intent is to look for a solution that minimizes the number of
additional files/libraries that have to get deployed to make the program
work for a client (- somewhat in the same sense as compiling a ".pl"
into a ".exe" makes it easier to deploy a perl program vs. requiring the
remote machine to be installed with Perl) - "native" is not the right term.

btw, "bgd" may/will disappear at some point in the programs port...

Thanks for the help. I'll try the dr mingw and also work on building it
directly without an IDE

-chander