mingw-users Mailing List for MinGW - Minimalist GNU for Windows

In evaluating GCJ under MinGW, I tried the simple
example below.  It compiles and runs under cygwin
but not under MinGW.  See the script, program, and
output from the script below.

I have the following MinGW versions installed:
  gcc-3.2.1-core-20021201-2.tar.gz
  gcc-3_2_1-release_notes.txt
  gcj-3.2-20021210-1.tar.gz
  mingw-runtime-2.3.tar.gz
  w32api-2.1.tar.gz

and get the same results with:
  gcc-3.2-core-20020817-1.tar.gz

Any ideas?

Thanks - Jim

================ doit.sh
#!/bin/bash
set -x

which gcj

gcj test.cpp -o test.exe
./test.exe ; rm -f ./test.exe
gcj -static test.cpp -o test.exe
./test.exe ; rm -f ./test.exe
gcj -static -mno-cygwin -Ic:/mingw/include -Ic:/mingw/include/gnu 
test.cpp -o test.exe

./test.exe ; rm -f ./test.exe

export PATH=/cygdrive/c/mingw/bin:$PATH

which gcj

gcj test.cpp -o test.exe
./test.exe ; rm -f ./test.exe
gcj -static test.cpp -o test.exe
./test.exe ; rm -f ./test.exe
gcj -static -mno-cygwin test.cpp -o test.exe
./test.exe ; rm -f ./test.exe

================ test.cpp
// test.cpp
#include <gcj/cni.h>
#include <java/lang/System.h>
#include <java/io/PrintStream.h>
#include <java/lang/Throwable.h>

int main(int argc, char *argv)
{
    using namespace java::lang;
    
    try
    {
        JvCreateJavaVM(NULL);
        JvAttachCurrentThread(NULL, NULL);
        
        String *message = JvNewStringLatin1("Hello from C++");
        JvInitClass(&System::class$);
        System::out->println(message);
        
        JvDetachCurrentThread();
    }
    catch (Throwable *t)
    {
        System::err->println(JvNewStringLatin1("Unhandled Java 
exception:"));
        t->printStackTrace();
    }
}
 
================ doit.out
+ which gcj
/usr/bin/gcj
+ gcj test.cpp -o test.exe
+ ./test.exe
Hello from C++
+ rm -f ./test.exe
+ gcj -static test.cpp -o test.exe
+ ./test.exe
Hello from C++
+ rm -f ./test.exe
+ gcj -static -mno-cygwin -Ic:/mingw/include -Ic:/mingw/include/gnu 
test.cpp -o test.exe
/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../libgcj.a(prims.o)(.text+0x517): 
undefined reference to `_impure_ptr'
/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../libgcj.a(natSystem.o)(.text+0xc98): 
undefined reference to `uname'
/usr/lib/gcc-lib/i686-pc-mingw32/3.2/../../../libgcj.a(natSystem.o)(.text+0xd7d): 
undefined reference to `getuid'
[snip out many libc symbol references]
+ ./test.exe
./doit: line 12: ./test.exe: No such file or directory
+ rm -f ./test.exe

+ export 
'PATH=/cygdrive/c/mingw/bin:/cygdrive/c/java/j2sdk14/bin://c/java/j2sdk14/jre/bin:.:/usr/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/Jim/bin:/cygdrive/c/Program 
Files/Perforce:/cygdrive/c/WinUnix/bin:'
+ 
PATH=/cygdrive/c/mingw/bin:/cygdrive/c/java/j2sdk14/bin://c/java/j2sdk14/jre/bin:.:/usr/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/cygdrive/c/Jim/bin:/cygdrive/c/Program 
Files/Perforce:/cygdrive/c/WinUnix/bin:

+ which gcj
/cygdrive/c/mingw/bin/gcj
+ gcj test.cpp -o test.exe
+ ./test.exe

abnormal program termination
+ rm -f ./test.exe
+ gcj -static test.cpp -o test.exe
+ ./test.exe

abnormal program termination
+ rm -f ./test.exe
+ gcj -static -mno-cygwin test.cpp -o test.exe
+ ./test.exe

abnormal program termination
+ rm -f ./test.exe

I've just uploaded a snapshot of my port of the newest version of GNU 
Bison to the MinGW project for download.  You can get it at 
http://prdownloads.sf.net/mingw/bison-1.875.0-2003.01.31-1.exe for 
evaluation.

Have Fun,
Earnie.

Dan...@di... wrote:
> Hi,
> 
> is the a way to create binaries that can run on a system without MinGW or
>        MSys installed? If not, which file should I include?
> 

Your end user does not need MinGW nor MSYS installed.

Earnie.

Hi,

is the a way to create binaries that can run on a system without MinGW or
       MSys installed? If not, which file should I include?

Thank you

Daniel
Diehl Munitionssysteme GmbH & Co. KG

English - autocreated E-Mail Appendix:
The content of this E-Mail is not legally binding upon Diehl, even though
       the
certified electronic signature technique may point to the writer of the
       E-Mail.
If this E-Mail was transmitted to you by error, then please inform us
       accordingly
(+49-911-957-2634). In such case you are requested to erase the message.
 Any unauthorized reproduction, disclosure, modification, distribution
       and/or
publication of such E-Mail message is strictly prohibited.

Deutsch - automatisch erzeugter E-Mail Anhang:
In Verbindung mit Kostenuebernahmen, Lieferungen, Angeboten und Vertraegen
ist der Inhalt dieses E-Mails fuer DIEHL rechtlich nicht verbindlich, auch
       wenn die
Anwendung des elektronischen, zertifizierten Signaturverfahrens den
       Ersteller des
E-Mails nachweist.
Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise
       erhalten haben
(+49 -911-957-2723). Bitte loeschen Sie in diesem Fall die Nachricht.
Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung
und/oder Publikation dieser E-Mail ist strengstens verboten.

> Date: Thu, 30 Jan 2003 13:37:03 -0500
> From: Christopher Faylor <cy...@cy...>
> To: Matthew Aldous <Ma...@Al...>
> Cc: dj...@re..., cy...@cy...
> Subject: Re: mingw-runtime-2.3, w32api-2.1, uberbaum
> Message-ID: <200...@re...>
> Reply-To: cy...@cy...
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> 
> Please check out the project web page for links to available information
> and ports:  http://cygwin.com/ .
> 
> If you don't see what you need there, then the cygwin mailing list is
> the best place to make observations or get questions answered.
> Information on the mailing list is available at the project web page.
> 
> For your convenience, I've reset the Reply-To: address to point to the
> cygwin mailing list.  I've also Cc'ed this reply there.
> 

And since this has to do more with MinGW than with Cygwin, it's would be 
better discussed on the min...@li... list.  I likewise have 
redirected this there.

> On Thu, Jan 30, 2003 at 04:51:53PM +0100, Matthew Aldous wrote:
> 
>>Hi,
>>
>>I'm trying to build a cross compiled mingw build under netbsd 1.6 using the
>>uberbaum cvs sources, but am experiencing the errors below with pex-win32.c
>>
>>I'm using mingw-runtime-2.3 and w32api-2.1, and was wondering if there was
>>an obvious "try this" solution when using newlib..
>>

If you're building a MinGW of GCC then why are the newlib headers being 
included for the target binary?  Perhaps 
http://www.mingw.org/mingwfaq.shtml#faq-cross might help.

Earnie.

>>Thanks in advance,
>>
>>Matthew Aldous.
>>
>>gmake[1]: Entering directory 
>>`/home/user/uberbaum/obj.i386-pc-mingw32/i386-pc-mingw32/libiberty'
>>if [ x"" != x ]; then \
>>/home/user/uberbaum/obj.i386-pc-mingw32/gcc/xgcc 
>>-B/home/user/uberbaum/obj.i386-pc-mingw32/gcc/ -nostdinc 
>>-B/home/user/uberbaum/obj.i386-pc-mingw32/i386-pc-mingw32/newlib/ 
>>-isystem 
>>/home/user/uberbaum/obj.i386-pc-mingw32/i386-pc-mingw32/newlib/targ-include 
>>-isystem /home/user/uberbaum/newlib/libc/include 
>>-B/usr/local/i386-pc-mingw32/bin/ -B/usr/local/i386-pc-mingw32/lib/ 
>>-isystem /usr/local/i386-pc-mingw32/include 
>>-L/home/user/uberbaum/obj.i386-pc-mingw32/ld -c -DHAVE_CONFIG_H -O2 -g 
>>-O2 -I. -I../../../libiberty/../include  -W -Wall -Wtraditional 
>>-pedantic  ../../../libiberty/pex-win32.c -o pic/pex-win32.o; \
>>else true; fi
>>/home/user/uberbaum/obj.i386-pc-mingw32/gcc/xgcc 
>>-B/home/user/uberbaum/obj.i386-pc-mingw32/gcc/ -nostdinc 
>>-B/home/user/uberbaum/obj.i386-pc-mingw32/i386-pc-mingw32/newlib/ 
>>-isystem 
>>/home/user/uberbaum/obj.i386-pc-mingw32/i386-pc-mingw32/newlib/targ-include 
>>-isystem /home/user/uberbaum/newlib/libc/include 
>>-B/usr/local/i386-pc-mingw32/bin/ -B/usr/local/i386-pc-mingw32/lib/ 
>>-isystem /usr/local/i386-pc-mingw32/include 
>>-L/home/user/uberbaum/obj.i386-pc-mingw32/ld -c -DHAVE_CONFIG_H -O2 -g 
>>-O2 -I. -I../../../libiberty/../include  -W -Wall -Wtraditional 
>>-pedantic ../../../libiberty/pex-win32.c -o pex-win32.o
>>In file included from ../../../libiberty/pex-win32.c:35:
>>/usr/local/i386-pc-mingw32/include/io.h:144: error: conflicting types 
>>for `getcwd'
>>/home/user/uberbaum/newlib/libc/include/sys/unistd.h:49: error: previous 
>>declaration of `getcwd'
>>In file included from 
>>/home/user/uberbaum/newlib/libc/include/sys/fcntl.h:164,
>>               from /home/user/uberbaum/newlib/libc/include/fcntl.h:1,
>>               from ../../../libiberty/pex-win32.c:36:
>>/home/user/uberbaum/newlib/libc/include/sys/stat.h:125: error: 
>>conflicting types for `mkdir'
>>/usr/local/i386-pc-mingw32/include/io.h:145: error: previous declaration 
>>of `mkdir'
>>../../../libiberty/pex-win32.c: In function `pexecute':
>>../../../libiberty/pex-win32.c:188: error: `_spawnvp' undeclared (first 
>>use in this function)
>>../../../libiberty/pex-win32.c:188: error: (Each undeclared identifier 
>>is reported only once
>>../../../libiberty/pex-win32.c:188: error: for each function it appears in.)
>>../../../libiberty/pex-win32.c:188: error: `_spawnv' undeclared (first 
>>use in this function)
>>../../../libiberty/pex-win32.c:206: warning: assignment discards 
>>qualifiers from pointer target type
>>../../../libiberty/pex-win32.c:141: warning: unused variable `retries'
>>../../../libiberty/pex-win32.c:141: warning: unused variable 
>>`sleep_interval'
>>../../../libiberty/pex-win32.c:133: warning: unused parameter `this_pname'
>>../../../libiberty/pex-win32.c:134: warning: unused parameter `temp_base'
>>../../../libiberty/pex-win32.c: In function `pwait':
>>../../../libiberty/pex-win32.c:228: warning: implicit declaration of 
>>function `_cwait'
>>../../../libiberty/pex-win32.c:224: warning: unused parameter `flags'
>>gmake[1]: *** [pex-win32.o] Error 1
>>gmake[1]: Leaving directory 
>>`/home/user/uberbaum/obj.i386-pc-mingw32/i386-pc-mingw32/libiberty'
>>gmake: *** [all-target-libiberty] Error 2
>>
> 
> At 09:54 PM 1/30/2003, Jim Kleckner wrote:
> 
> 
>>Max Bowsher wrote:
>>
>>
>>>William A. Hoffman wrote:
>>
>>[snip]
>>
>>>>2. Failing that, it would be nice if the setup program had a button that
>>>>set all the values to Keep.   The problem is that if I want a new
>>>>package X, I have to click 20 other packages to Keep, or risk an
>>>>update of everything. There should be a way to update one single
>>>>package.   Is there a way?
>>>
>>>It's in CVS. The next snapshot will have it.
>>>Max.
>>
>>Thanks!  While you have the code in hand, would it be
>>possible to allow the setup window to be resized?
>>I'm constantly wanting to see more lines at once...
> 
> 
> 
> 
> Have you been reading the email archives?  I think I've heard 
> that request before! :-)
> 
> 
> 
> Larry Hall                              lh...@rf...
> RFK Partners, Inc.                      http://www.rfk.com
> 838 Washington Street                   (508) 893-9779 - RFK Office
> Holliston, MA 01746                     (508) 893-9889 - FAX
> 
> <div class="moz-text-flowed" style="font-family: -moz-fixed">
> Larry Hall (RFK Partners, Inc) wrote:
> 
> 
>>At 09:54 PM 1/30/2003, Jim Kleckner wrote:
>>
>>[snip ]
>>
>>>Thanks!  While you have the code in hand, would it be
>>>possible to allow the setup window to be resized?
>>>I'm constantly wanting to see more lines at once...
>>
>>Have you been reading the email archives?  I think I've heard 
>>that request before! :-)
> 
> 
> I see the answer here:
> http://sources.redhat.com/ml/cygwin/2002-11/msg00309.html
> 
> Sorry to duplicate.  I guess every single thing needs to be searched
> before replying...
> 
> Jim
> 
> </div>

jj...@dd... wrote:
> 
> 
> I am using the cygwin bash (not MSYS).
> 
> It works with cmd.exe.
> 

Then you have a couple of choices:

1) use MSYS instead of Cygwin.
2) update your version of Cygwin to current and if you still have 
problems complain on the cy...@cy... list.

Earnie.

I am using the cygwin bash (not MSYS).

It works with cmd.exe.

/Jesper





Greg Chicares <chi...@mi...> on 2003-01-30 17:44:41

Please respond to min...@li...

To:   Jesper J=F8rgensen/DDC-I@DDC-I, min...@li...=

cc:
Subject:  Re: [Mingw-users] can't invoke gcc by full name


=

>From: jj...@dd...
>To: min...@li...
>Subject: [Mingw-users] can't invoke gcc by full name
>Date: Thu, 30 Jan 2003 16:56:50 +0100
>
>
>I apologize if this question is a FAQ, but I could not find any mention of 
>it in
>the mail archive.
>
>I have downloaded and installed MinGW-2.0.0-3 and am trtying to use it on
>Windows NT 4.0. I have cygwin b20 installed and when I invoke gcc from a 
>bash
>prompt with full path name, it has problems locating its specs-file, cc1, 
>crt2.o
>...:
>
>jj@rshpc1(5)> /tools/gcc/mingw/bin/gcc -v -o hello hello.c
>Using built-in specs.
>Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
>--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads 
>--disable-nls
>--enable-languages=f77,c++,objc,ada --disable-win32-registry 
>--disable-shared
>Thread model: win32
>gcc version 3.2 (mingw special 20020817-1)
>  cc1 -lang-c -v -iprefix /tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/3.2/

The above line makes me suspect that this is a problem with Cygwin not 
translating GCC's argv[0] to a Windows path. The reason that this is not a 
known problem may be because you are using a quite old version of Cygwin, so 
if you install the latest version it will probably work. Make sure you 
either remove the old version or install the new version in a separate 
location.

[snip]
>gcc: installation problem, cannot exec `cc1': No such file or directory
>
>
>
>If I invoke it by short name, everything works:
>
>
>jj@rshpc1(4)> gcc -v -o hello hello.c
>Reading specs from 
>t:/score/tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/3.2/specs
[snip]
>
>
>Is this a known problem and do anyone know a cure?
>
>/Jesper Jørgensen
>DDC-I

Luke


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

                            SOLICIT1NG FOR ASISTANCE AND BUSINESS PARTNERSHIP 
                                               INVESTMENT OF US$12.5 MILLION 

  FROM: Prince Johnson Vander
TEL: +31 625-251-889

  Sir,

      I am Prince Johnson Vander. The son of former minister of finance (Vander Makabo) of the Republic of Sierra-Leone West Africa, based on the information I gathered from your chamber of commerce and industry on your credibility, I decide to contact for the assistance.
Regarding my zeal toward foreign investment and security for my life and possession,
I therefore write to you a break down of this proposal.

    My father died when a group of rebel soldier led by Sir Foday Sankoh overthrown Government of sierra-Leone forcing the president out of power and killing many members of the cabinet and ministerincuding my own father. When it become apparently obvious that the country no longer safe for the citizens due to the political war and massive killing and destruction of properties, I decided to move to Holland with a treasure containing the sum of US$12.500.000.00(twelve million five hundred thousand united state dollars) through a diplomatic means, this fund is the last tangible money my father left behind before his death.

   The said amount is presently in Holland (The Netherlands) where I am currently seeking political asylum. While the consignment containing the fund is in the custody of the diplomatic courier company they are not aware of the content as it was deposited as personal effect and artifact. I am seeking for partner who will serve as a the guardian of this fund with whom I could plan the best way to move this money out of Holland for investment which is my main purpose of contacting you.
Thus I decided to offer you 20% of the total money for assisting me to actualize this project while 10% of the money has been set aside to offset any incidental expenses that might incurred during the course of this funds and the balance 70%shall be for me and my family which shall be invested in your country. So if you are willing to assist me contact me on the number above. And are will visit you country soonest in order to inquire areas of possible business investment. I shall be sincerely glad if my request is rendered.
Thank you 
God bless you 
PRINCE JOHNSON.

jj...@dd... wrote:
> 
> I have downloaded and installed MinGW-2.0.0-3 and am trtying to use it on
> Windows NT 4.0. I have cygwin b20 installed and when I invoke gcc from a bash
> prompt with full path name, it has problems locating its specs-file, cc1, crt2.o
[...]
> jj@rshpc1(5)> /tools/gcc/mingw/bin/gcc -v -o hello hello.c
> Using built-in specs.
> Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
> --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
> --enable-languages=f77,c++,objc,ada --disable-win32-registry --disable-shared
[...]
> gcc: installation problem, cannot exec `cc1': No such file or directory
[...]
> If I invoke it by short name, everything works

What shell are you using? Cygwin bash? MSYS bash?

Is any cygwin stuff on the path?

Does it work in a CMD.EXE shell with mingw's bin/
directory on the path, and no cygwin stuff of any
sort on the path?

----- Original Message -----
From: "Oscar Fuentes" <of...@wa...>
To: <min...@li...>; <krz...@ko...>
Sent: Wednesday, January 29, 2003 10:49 PM
Subject: Re: [Mingw-users] gdb doesn't stop on most breakpoints!


> gcc (as the other C/C++ compilers I know) doesn't default to
> "no-optimization". You must give the -O0 flag to produce code which is
> ok for full debug.

I did that, but it didn't help :-(


> Which programming language are you using? C++?
Yes, I'm writing a wxWindows application in C++.

The gerenal question is: does mingw gdb support multiprocessor debugging?

-Krzysztof

I apologize if this question is a FAQ, but I could not find any mention=
 of it in
the mail archive.

I have downloaded and installed MinGW-2.0.0-3 and am trtying to use it =
on
Windows NT 4.0. I have cygwin b20 installed and when I invoke gcc from =
a bash
prompt with full path name, it has problems locating its specs-file, cc=
1, crt2.o
...:

jj@rshpc1(5)> /tools/gcc/mingw/bin/gcc -v -o hello hello.c
Using built-in specs.
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-a=
s
--host=3Dmingw32 --target=3Dmingw32 --prefix=3D/mingw --enable-threads =
--disable-nls
--enable-languages=3Df77,c++,objc,ada --disable-win32-registry --disabl=
e-shared
Thread model: win32
gcc version 3.2 (mingw special 20020817-1)
 cc1 -lang-c -v -iprefix /tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/3.=
2/
-D__GNUC__=3D3 -D__GNUC_MINOR__=3D2 -D__GNUC_PATCHLEVEL__=3D0 -D__GXX_A=
BI_VERSION=3D102
-D_WIN32 -D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -D__MSVCRT__ -DWIN=
NT
-D_X86_=3D1 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ -D=
__MSVCRT__
-D__WINNT__ -D_X86_=3D1 -D__WIN32 -D__WINNT -Asystem=3Dwinnt -D__NO_INL=
INE__
-D__STDC_HOSTED__=3D1 -Acpu=3Di386 -Amachine=3Di386 -Di386 -D__i386 -D_=
_i386__
-D__tune_i586__ -D__tune_pentium__ -D__stdcall=3D__attribute__((__stdca=
ll__))
-D__cdecl=3D__attribute__((__cdecl__)) -D__fastcall=3D__attribute__((__=
fastcall__))
-D_stdcall=3D__attribute__((__stdcall__)) -D_cdecl=3D__attribute__((__c=
decl__))
-D_fastcall=3D__attribute__((__fastcall__)) -D__declspec(x)=3D__attribu=
te__((x))
hello.c -quiet -dumpbase hello.c -version -o C:\TEMP/ccsiaaaa.s
gcc: installation problem, cannot exec `cc1': No such file or directory=




If I invoke it by short name, everything works:


jj@rshpc1(4)> gcc -v -o hello hello.c
Reading specs from t:/score/tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/=
3.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-a=
s
--host=3Dmingw32 --target=3Dmingw32 --prefix=3D/mingw --enable-threads =
--disable-nls
--enable-languages=3Df77,c++,objc,ada --disable-win32-registry --disabl=
e-shared
Thread model: win32
gcc version 3.2 (mingw special 20020817-1)
 t:\score\tools\gcc\mingw\bin\..\lib\gcc-lib\mingw32\3.2\cc1.exe -lang-=
c -v
-iprefix t:\score\tools\gcc\mingw\bin/../lib/gcc-lib/mingw32/3.2/ -D__G=
NUC__=3D3
-D__GNUC_MINOR__=3D2 -D__GNUC_PATCHLEVEL__=3D0 -D__GXX_ABI_VERSION=3D10=
2 -D_WIN32
-D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -D__MSVCRT__ -DWINNT -D_X86=
_=3D1
-D_WIN32 -D__WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ -D__MSVCRT__
-D__WINNT__ -D_X86_=3D1 -D__WIN32 -D__WINNT -Asystem=3Dwinnt -D__NO_INL=
INE__
-D__STDC_HOSTED__=3D1 -Acpu=3Di386 -Amachine=3Di386 -Di386 -D__i386 -D_=
_i386__
-D__tune_i586__ -D__tune_pentium__ -D__stdcall=3D__attribute__((__stdca=
ll__))
-D__cdecl=3D__attribute__((__cdecl__)) -D__fastcall=3D__attribute__((__=
fastcall__))
-D_stdcall=3D__attribute__((__stdcall__)) -D_cdecl=3D__attribute__((__c=
decl__))
-D_fastcall=3D__attribute__((__fastcall__)) -D__declspec(x)=3D__attribu=
te__((x))
hello.c -quiet -dumpbase hello.c -version -o C:\TEMP/cc6eaaaa.s
GNU CPP version 3.2 (mingw special 20020817-1) (cpplib) (80386, BSD syn=
tax)
GNU C version 3.2 (mingw special 20020817-1) (mingw32)
     compiled by GNU C version 3.2.
ignoring nonexistent directory "t:/score/tools/gcc/mingw/mingw32/includ=
e"
ignoring nonexistent directory
"/mingw/lib/gcc-lib/mingw32/3.2/../../../../include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/mingw/lib/gcc-lib/mingw32/3.2/include"=

ignoring nonexistent directory
"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/include"
ignoring nonexistent directory "/usr/local/mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 t:/score/tools/gcc/mingw/include
 t:/score/tools/gcc/mingw/lib/gcc-lib/mingw32/3.2/include
End of search list.

t:\score\tools\gcc\mingw\bin\..\lib\gcc-lib\mingw32\3.2\..\..\..\..\min=
gw32\bin\as.exe

-o C:\TEMP/cc2jaaaa.o C:\TEMP/cc6eaaaa.s

t:\score\tools\gcc\mingw\bin\..\lib\gcc-lib\mingw32\3.2\..\..\..\..\min=
gw32\bin\ld.exe

-Bdynamic -o hello.exe
t:/score/tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/3.2/../../../crt2.o=

t:/score/tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/3.2/crtbegin.o
-Lt:/score/tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/3.2
-Lt:/score/tools/gcc/mingw/bin/../lib/gcc-lib
-Lt:/score/tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/3.2/../../../../m=
ingw32/lib

-Lt:/score/tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/3.2/../../..
C:\TEMP/cc2jaaaa.o -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser=
32
-lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -l=
msvcrt
t:/score/tools/gcc/mingw/bin/../lib/gcc-lib/mingw32/3.2/crtend.o


Is this a known problem and do anyone know a cure?

/Jesper J=F8rgensen
DDC-I
=

Arie,

> Marcel (and others),
>
> as an experiment, I just downloaded and installed the DGJPP package,
> and used the g77 compiler (v3.2) to create a new exe.
>
> What a surprise that this version is some 60% faster in start-up compared
> to the g77 compiler as part of the MinGw package.
>
> Some numbers:           Run-time:
>
> DOS/Lahey fortran 12.14 sec's
>
> Gnu 0.5.25 version      68.33 sec's
> MinGW package     65.31 sec's
> DGJPP package     26.03 sec's
>
> The above in a loop with 27 program-starts.

I hope those are the commulative times for the 27 runs, and not the times
for an individula run!

> It seems to me it could be related to the differences between the MinGW
and
> the DGJPP package. Unfortionally I know nothing about what g77 packages
> all exist and what the differences are between all releases.

g77 itself if part of GCC (the Gnu Compiler Collection) which contain
portable C, C++, Object-C, Ada and Fortran77  compilers that work on many
different processors and platforms. The main homepage for the GCC project is
http://gcc.gnu.org
For DOS and Windows platforms, there are different ports available using the
same core compiler, but completely different runtime libraries and different
ways of interfacing with the OS:

DJGPP: This is a DOS port of GCC using its own 32 bit extender called
GO32.EXE. The runtime libarry in this case is included with the compiler and
is statically linked.
http://www.delorie.com/djgpp/

MinGW: This is a GCC port to Win32 platforms (W95 and above) and uses
Microsoft's MSVCRT.DLL as runtime library. The advantage of this approach is
that there is no need to develop a specific runtime library for GCC for this
platform. Also, this version of GCC is best suited for just using GCC as a
replacement for MS compilers.
http://www.mingw.org

Cygwin: Cygwin consists of a DLL that emulates a Unix like environment on
Win32 platforms and GCC and a lot of other tools have been ported to this
environment. Cygwin has the advantage of making it easy to port Unix
specific programs to Windows, but it may have the disadvantage of adding a
certain overhead compared to using native Win32 APIs. The Cygwin version of
GCC can also be used to create native windows applications and in that case
uses the same runtime library as MinGW
http://www.cygwin.com/


In summary, one can say that the GCC project only supplies the source code
for the compilers, but to actually get a working compiler you need a
development environment and a runtime library which are either included with
the OS or which exist as separate projects.

Marcel

Marcel (and others),

as an experiment, I just downloaded and installed the DGJPP package,
and used the g77 compiler (v3.2) to create a new exe.

What a surprise that this version is some 60% faster in start-up compared
to the g77 compiler as part of the MinGw package.

Some numbers:           Run-time:

DOS/Lahey fortran 12.14 sec's

Gnu 0.5.25 version      68.33 sec's
MinGW package     65.31 sec's
DGJPP package     26.03 sec's

The above in a loop with 27 program-starts.

It seems to me it could be related to the differences between the MinGW and
the DGJPP package. Unfortionally I know nothing about what g77 packages
all exist and what the differences are between all releases.

Just received your reply....

> Maybe the DJGPP version will however really help you in this case as it
will
> allow you to build a statically linked executable.

And it did...
I did not yet figure out how to build a statically linked exe or if this is
the default behavour...

However, I did notice that when using the -O2 option with DGJPP the program
did not work
properly any more. (the MinGW version did work with all -O1 to -O6 options)

As a g77 newbie, I would think, just one release of the g77 compiler would
be enough.
why three or even more different releases ?. Could you (or someone else)
spend a few
words about this. Just to give me some more basic understanding.

Thanks a lot for your DGJPP suggestion,
Arie.
   ----------------
   This E-mail message, including any attached documentation, is
   confidential. Should you have received this message wrongly, you are
   urged to inform the sender at "dis...@IC..." and remove the message
   from your system. Any unauthorised dissemination of the information, in
   whole or in part, is prohibited. E-mail messages can be subject to
   change. ICT Automatisering NV and its subsidiaries cannot be held
   responsible for incorrect, incomplete and/or delayed transfer of
   messages and possible damage caused by this. Although ICT Automatisering
   NV (including its subsidiaries) makes every effort to send messages free
   of viruses by using a viruschecker, ICT Automatisering NV (or its
   subsidiaries) cannot guarantee that the message and any attachments are
   actually completely virus free.

Arie,

When talking about long startup delays, is this still delays in the seconds
range we are talking about?
I guess the "long" delay might indeed be due to the time needed to
initialize the supporting DLLs, abiove all MSVCRT.DLL in this case. This
delay can only be eliminated by using a statically linked runtime library,
but alas, this is not available with the Mingw version of g77.
Maybe the DJGPP version will however really help you in this case as it will
allow you to build a statically linked executable.

http://www.delorie.com/djgpp/

Marcel

What do you mean when you say 'Windows'? If you mean Windows 95, 98 and
ME then I have an explanation See below). If you mean all 32-bit
versions (i.e. 95, 98, ME, NT4, 2000), then I am at a loss to explain it
too.

      Yeas, I meant, windows-95, -NT, -98, -2000 and -Me.

      The DOS mode for windows-XP seems to be more different from
      the 'original' DOS than for the other above listed systems.

      Anybody who know's what has changed concerning the 'DOS-box',
      between XP and NT/2000 ?

      Arie.

Marcel,

first of all thanks for the reply.

- Is your DOS version also G77 based (e.g. using DJGPP)? If yes, you might
get a DOS version working under XP by using a newer version of DJGPP. Check
the following page on a discussion on DJGPP compatibility with W2K/XP:
http://clio.rice.edu/djgpp/win2k/main.htm

      No, the (old) DOS version I was using was based on F77 (L-EM/32) from
      Lahey Computer Systems using a Phar Lap DOS extender (at least that's
      what I get when I am doing a hex-dump) of this exe file.

- Did you compare the sizes of your EXE files both for the DOS and the
Win32
versions of your program? Maybe the slowdown is based on a huge EXE file
size. Mingw includes some debugging information by default, and you can
reduce the size of the EXE file by adding the option -s when compiling, or
by using the STIP.EXE tool on the resulting EXE file.

      Sizes don't differ much 455 (Lahey/DOS version) to 478 kb (g77
version)

- Finally, if code size is the issue, than optimizing more might help. E.g.
instead of -O, use the options -O2 or -Os to do more aggressive
optimizations and favour smaller code size.

      I tried -O and -O1 to -O6.

      This affects only performance (max 30% !!) when doing a fairly large
      run. However when performing a number of short runs the overall
      perfomance is not affected much. Probably because optimization
      only has impact on execuation of the fortran code/calculations
      and not on the initialization/start-up process.

      It might be possible that a number of g77 based library's or DLL's
must
      be loaded each time the g77 based exe is started and that this causes
      the delay, I don't know.....

      Some gcc/g77 expert out there who can say anything about this...



      Furthermore I do not know why the old DOS based executable would not
      run anymore on windows-XP. It does run on all other windows-systems.
      I am not aware of significant DOS differences between XP and the
      others windows systems.

      I detected this severe increase in start-up time between the
      Lahey F77 executable and the g77 executable when running both exe's
      on my windows-Me system.

      If someone is interested to do some further experiments on this
      I would be glad to deliver both the original Lahay/DOS-based
      executable and the original fortran sources to create a g77 based
exe.

      Arie.

"Marcel Cox" <mar...@ho...> wrote in message
news:b1b0dm$oel$1...@ma......
> - Did you compare the sizes of your EXE files both for the DOS and the
Win32
> versions of your program? Maybe the slowdown is based on a huge EXE file
> size. Mingw includes some debugging information by default, and you can
> reduce the size of the EXE file by adding the option -s when compiling, or
> by using the STIP.EXE tool on the resulting EXE file.

That should be STRIP.EXE of course.

Marcel

<html>
<head>
<title>Money Letter</title>
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div align=3D"center">
  <p><b>Is your Investment Advisor doing right for you? Is he/she 
acting in your 
    best interest?</b></p>
  <p><u>We're here to help. </u></p>
  <p>We let you make the choices with our <u>FREE</u> unbiased $ making 
newsletter.</p>
  <p>Our letters show you how to make real-money swiss style. We 
offer:</p>
  <p><font face=3D"Arial, Helvetica, sans-serif">* Daily Stock Market 
Commentary 
    <br>
    * Buy/ Sell Recommendations <br>
    * Option Trading <br>
    * Long term Strategies <br>
    * Day Trading </font></p>
  <p>We hold all information with strict confidence. See what our 
newsletter can 
    do for your wallet &amp; you be the judge. Stop letting someone 
else control 
    the direction &amp; results of your investments! Take charge now 
&amp; see 
    for yourself!</p>
  <p><a 
href=3D"http://www.optinservicesnet.org/equityresearch/newsletter3.htm"><b=
>Click 
    Here for Info on FREE Newsletter</b></a></p>
  <p>* Read our letter &amp; watch the results for yourself, then 
decide if the 
    investment choices are right for you.</p>
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  <p><font size=3D"2">If you wish to unsubscribe to our exclusive opt-in 
service, 
    <a 
href=3D"http://www.optinservicesnet.org/equityresearch/nomore2.htm">click 
    here</a></font><br>
  </p>
</div>
</body>
</html>

Some random thoughts:

- Is your DOS version also G77 based (e.g. using DJGPP)? If yes, you might
get a DOS version working under XP by using a newer version of DJGPP. Check
the following page on a discussion on DJGPP compatibility with W2K/XP:
http://clio.rice.edu/djgpp/win2k/main.htm

- Did you compare the sizes of your EXE files both for the DOS and the Win32
versions of your program? Maybe the slowdown is based on a huge EXE file
size. Mingw includes some debugging information by default, and you can
reduce the size of the EXE file by adding the option -s when compiling, or
by using the STIP.EXE tool on the resulting EXE file.

- Finally, if code size is the issue, than optimizing more might help. E.g.
instead of -O, use the options -O2 or -Os to do more aggressive
optimizations and favour smaller code size.

E.g. based on the last 2 suggestions, try the following to compile your
code:

g77 -Os -s -fno-automatic -Wall nec2d.f -o nec2d.exe


Marcel

<Ari...@ic...> wrote in message
news:OF8...@de......
> For some time now I am using gcc to compile/link specific
> third-party fortan code to do some electro-magnetic modelling.
>
> In the past I used a pre-made DOS-based binary/executable for
> this.
> However due to the use of some kind of DOS-extender within
> this binary it would not run anymore on windows-XP.
> (stack overflow problems)
>
> This forced me to acquire the fortran sources and build my own
> binary using the gcc fortran compiler. All this succeeded very well.
>
> However there is one major problem concerning the great difference
> between startup-speed of the old DOS-based executable and the new
> g77 based executable.
>
> The old DOS-based binary is much faster at start-up (initialization)
> compared to the g77 based executable.
>
> This is especially important because I run a large sequence of short
> calculations resulting in a significant increase in overall time
> due to the large amount of the g77 based executable start-ups.
>
> When performing one large run however the g77 based executable is
> superior in performance.
>
> Used command-line(options):
>
> g77 -O -fno-automatic -Wall nec2d.f -o nec2d.exe
>
> Anybode with suggestions how to speed-up the initialization
> process.
>
> Arie.
>    ----------------
>    This E-mail message, including any attached documentation, is
>    confidential. Should you have received this message wrongly, you are
>    urged to inform the sender at "dis...@IC..." and remove the
message
>    from your system. Any unauthorised dissemination of the information, in
>    whole or in part, is prohibited. E-mail messages can be subject to
>    change. ICT Automatisering NV and its subsidiaries cannot be held
>    responsible for incorrect, incomplete and/or delayed transfer of
>    messages and possible damage caused by this. Although ICT
Automatisering
>    NV (including its subsidiaries) makes every effort to send messages
free
>    of viruses by using a viruschecker, ICT Automatisering NV (or its
>    subsidiaries) cannot guarantee that the message and any attachments are
>    actually completely virus free.
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

<html>

<head>
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<title>·í§A¯à­¸ªº®É­Ô´N¤£­n©ñ±ó­¸</title>
</head>

<body bgcolor="#FFFFCC">

<p align="center">¡@</p>
<div style="width: 700; height: 496">
  <table border="0" cellpadding="3" cellspacing="0" width="100%">
    <tr>
      <td width="10%"></td>
      <td width="190%">
        <p align="center"><b><span style="background-color: #ffff99">
<font face="¼Ð·¢Åé" color="#ff0000" size="6">·í§A¯à­¸ªº®É­Ô´N¤£­n©ñ±ó­¸</font></span> </b></p>
        <p align="center">¡@</td>
    </tr>
  </table>
  <table border="0" cellpadding="3" cellspacing="0" width="100%">
    <tr>
      <td width="10%">
        <p align="center"></td>
      <td width="190%">
  <p style="line-height: 100%" align="center"><font face="¼Ð·¢Åé" size="4">
  ¤Hªº»ù­È¡A¦b¤U¨M©wªº¤@Àþ¶¡³Q½á¤©»ù­È</font> </p>
  <p style="line-height: 100%" align="center"><font face="¼Ð·¢Åé" size="4">
  ¨º»ò¡A§A¨M©w§Aªº»ù­È¤F¶Ü¡H <br>
  <br>
  ¤£½×§A¦b¤°»ò®É­Ô¶}©l¡A­«­nªº¬O¶}©l¤§«á´N¤£­n°±¤î <br>
  <br>
  µo¥ú¨Ã«D¤Ó¶§ªº±M§Q¡A§A¤]¥i¥Hµo¥ú<br>
  <br>
  <font color="#ff0000"><b><span style="background-color: #ffff99">·í§A¯à­¸ªº®É­Ô´N¤£­n©ñ±ó­¸</span>
  <br>
  <br>
  ·í§A¯à¹Úªº®É­Ô´N¤£­n©ñ±ó¹Ú</b></font> <br>
  <br>
  ¥Î³Ì¤Öªº®¬«ë­±¹ï¹L¥h¡A¥Î³Ì¤Öªº®ö¶O­±¹ï²{¦b¡A¥Î³Ì¦hªº¹Ú­±¹ï¥¼¨Ó <br>
  <br>
  §A¤£¯à¥ª¥k¥@¬É¡A¦ý§A¯à§ä¨ì¥X¸ô <br>
  <br>
  <font color="#000080">§êºt¦Û¤vªº¨¤¦â¡A¿ï¾Ü¦Û¤v·Q°µªº¨Æ¡A¬¡¥X§Aªº¥Í©R¡A§@¦Û¤vªº¥D¨¤</font></font>
        <p align="center">¡@</td>
    </tr>
  </table>
  <table border="0" cellpadding="3" cellspacing="0" width="100%">
    <tr>
      <td width="12%">
        <p align="center"></td>
      <td width="188%">
<p align="center"><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ÁܽЧA¨Ó»P¥@¬É±µ­y</b>.....´Á«Ý»P±z·|­±.........&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </p>
<p align="center"><font size="2"><span class="unnamed1">
<a href="http://home.kimo.com.tw/moman992000">
http://home.kimo.com.tw/moman992000</a>&gt;&gt;§¹¾ã²z©À¤¶²Ð&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<a href="http://home.kimo.com.tw/moman992000">
http://home.kimo.com.tw/moman992000</a></span></font> &gt;&gt;<font size="2">½u¤WÁʪ«¾÷¨î<span class="unnamed1">&nbsp;</span></font></p> 
<p align="center"><font color="#ff0000" size="5">&nbsp; <b> 
<a href="http://home.kimo.com.tw/moman992000" target="_blank">§Ú¯àÀ°§U§A§Ö³t¦¨¥\ªº¤H</a></b></font></p> 
<p align="center"><font color="#ffe6ff"><b><font size="5"> 
<a href="http://home.kimo.com.tw/moman992000" target="_blank">»{ÃѧڱN¬O§A¦¨¥\³Ì¨Î«OÃÒ</a></font></b></font> 
</p> 
<p align="center"><b><font color="#cc6666" size="5"> 
<a href="http://home.kimo.com.tw/moman992000">§Q¥Î±ß¤W¦h¤@¥÷¦¬¤J!!</a></font></b></p> 
 
        <p align="center">¡@</td>
    </tr>
  </table>
</div>

</body>

</html>

<html>

<head>
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<title>·í§A¯à­¸ªº®É­Ô´N¤£­n©ñ±ó­¸</title>
</head>

<body bgcolor="#FFFFCC">

<p align="center">¡@</p>
<div style="width: 700; height: 496">
  <table border="0" cellpadding="3" cellspacing="0" width="100%">
    <tr>
      <td width="10%"></td>
      <td width="190%">
        <p align="center"><b><span style="background-color: #ffff99">
<font face="¼Ð·¢Åé" color="#ff0000" size="6">·í§A¯à­¸ªº®É­Ô´N¤£­n©ñ±ó­¸</font></span> </b></p>
        <p align="center">¡@</td>
    </tr>
  </table>
  <table border="0" cellpadding="3" cellspacing="0" width="100%">
    <tr>
      <td width="10%">
        <p align="center"></td>
      <td width="190%">
  <p style="line-height: 100%" align="center"><font face="¼Ð·¢Åé" size="4">
  ¤Hªº»ù­È¡A¦b¤U¨M©wªº¤@Àþ¶¡³Q½á¤©»ù­È</font> </p>
  <p style="line-height: 100%" align="center"><font face="¼Ð·¢Åé" size="4">
  ¨º»ò¡A§A¨M©w§Aªº»ù­È¤F¶Ü¡H <br>
  <br>
  ¤£½×§A¦b¤°»ò®É­Ô¶}©l¡A­«­nªº¬O¶}©l¤§«á´N¤£­n°±¤î <br>
  <br>
  µo¥ú¨Ã«D¤Ó¶§ªº±M§Q¡A§A¤]¥i¥Hµo¥ú<br>
  <br>
  <font color="#ff0000"><b><span style="background-color: #ffff99">·í§A¯à­¸ªº®É­Ô´N¤£­n©ñ±ó­¸</span>
  <br>
  <br>
  ·í§A¯à¹Úªº®É­Ô´N¤£­n©ñ±ó¹Ú</b></font> <br>
  <br>
  ¥Î³Ì¤Öªº®¬«ë­±¹ï¹L¥h¡A¥Î³Ì¤Öªº®ö¶O­±¹ï²{¦b¡A¥Î³Ì¦hªº¹Ú­±¹ï¥¼¨Ó <br>
  <br>
  §A¤£¯à¥ª¥k¥@¬É¡A¦ý§A¯à§ä¨ì¥X¸ô <br>
  <br>
  <font color="#000080">§êºt¦Û¤vªº¨¤¦â¡A¿ï¾Ü¦Û¤v·Q°µªº¨Æ¡A¬¡¥X§Aªº¥Í©R¡A§@¦Û¤vªº¥D¨¤</font></font>
        <p align="center">¡@</td>
    </tr>
  </table>
  <table border="0" cellpadding="3" cellspacing="0" width="100%">
    <tr>
      <td width="12%">
        <p align="center"></td>
      <td width="188%">
<p align="center"><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
ÁܽЧA¨Ó»P¥@¬É±µ­y</b>.....´Á«Ý»P±z·|­±.........&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </p>
<p align="center"><font size="2"><span class="unnamed1">
<a href="http://home.kimo.com.tw/moman992000">
http://home.kimo.com.tw/moman992000</a>&gt;&gt;§¹¾ã²z©À¤¶²Ð&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<a href="http://home.kimo.com.tw/moman992000">
http://home.kimo.com.tw/moman992000</a></span></font> &gt;&gt;<font size="2">½u¤WÁʪ«¾÷¨î<span class="unnamed1">&nbsp;</span></font></p> 
<p align="center"><font color="#ff0000" size="5">&nbsp; <b> 
<a href="http://home.kimo.com.tw/moman992000" target="_blank">§Ú¯àÀ°§U§A§Ö³t¦¨¥\ªº¤H</a></b></font></p> 
<p align="center"><font color="#ffe6ff"><b><font size="5"> 
<a href="http://home.kimo.com.tw/moman992000" target="_blank">»{ÃѧڱN¬O§A¦¨¥\³Ì¨Î«OÃÒ</a></font></b></font> 
</p> 
<p align="center"><b><font color="#cc6666" size="5"> 
<a href="http://home.kimo.com.tw/moman992000">§Q¥Î±ß¤W¦h¤@¥÷¦¬¤J!!</a></font></b></p> 
 
        <p align="center">¡@</td>
    </tr>
  </table>
</div>

</body>

</html>

> 
> ----- Original Message -----
> From: "Paul G." <pga...@at...>
> To: <min...@li...>
> Sent: Wednesday, January 29, 2003 9:12 AM
> Subject: [Mingw-users] gcc/g++ (v3.2) -shared && gdb (RC)
> 
> 
> > Hi folks,
> >
> > Not exactly sure where to begin with this sort of question.
> >
> > I have noticed some difficulties when I have attempted to load .dll
> > debug
> data for
> > dynamic access by Mingw gdb (via implementation/use of "gcc
> > -shared").
> >
> > This problem does not appear if I use "dllwrap".  "gcc -shared", at
> > least
> I would think so,
> > should be capable of generating all of the necessary symbols,
> > whether
> those symbols
> > include debug data or not.
> 
> I don't see how there could be a difference between using dllwrap and
> gcc -shared, unless something else is different (e.g. using an import
> library vs. linking directly to the DLL).

	That was my thought initially as well.  I could not see how there could be any difference, 
and yet, in this case, there is.  I am putting together a test case as quickly as the data makes 
itself available to me...

	In the meantime, pleaes, allow me to try and reply/address the question as posed by 
Luke:

> 
> >
> > The actual problem has to do with gdb (Release Candidate or RC) not
> dynamically
> > loading all of the .dll debug symbols that are particular
> > application is
> requesting.
> >
> > The build itself actually creates debug data and integrates that
> > .dll
> data, in some form,
> > via the use of "gcc -g3 -shared".  "gdb" (RC) does not seem to be
> consistently loading all of
> > the .dll debug data.
> 
> Firstly, why do you talk about "-g3"? Does it behave any different
> than "-g"?

	That is, to me, unknown.  Most especially where gdb is concerned.  I do not know 
enough about gdb to make a definitive statement re: -g vs -g3 output.

	Even so, from the what I can determine, there is the very strong possibility that -g debug 
symbol output and -g3 debug symbol output are different sets of debug symbols.

	It could be easily assumed, then, that the two sets of debug symbols are different by 
nature of the fact that -g3 is recommended, from what I can immediately recall in terms of 
the gcc option descriptions.

	verbatim:

		If the developer has some sort of need or desire for a more comprehensive 
collection, or "set", of debug symbols than the "set" of debug symbols generated when -g is 
used then the developer is "encouraged" to use -g3 instead.

	"gcc -g -shared"  -- generates "bare minimum" (relative term) set of debug symbols
	"gcc -g3 -shared" -- generates the "more complete" (relative term again) set of debug 
symbols.

	Since "-shared" means, in this context, "generate .dlls", ot would seem to follow then that 
you will get a different set of debug symbols depending on which debug switch you use (-g 
or -g3).

	I do not have any definite proof one way or the other where -g and -g3, in terms of debug 
symbol set intersections aside from this:  It is said that -g3 will produce more debug symbols 
than -g does.  Someone who is working on gcc and/or "ld" right now might be better able to 
confirm or deny this.  I can only hope that they will.

> 
> >
> > If this is a known bug, please let me know.  What I know of the
> > so-called
> "bug" is mostly
> > based on "rumor".  However, these rumors are becoming more
> > persistent as
> of late.
> >
> > Is anyone working on this or are there any plans that any of the
> developers have in
> > regards to this?
> >
> > Is it not possible to generate .dll debug data which is useable and
> loadable by gdb RC
> > through the use of "gcc -g/3 -shared"?
> >
> > Thanks,
> >
> > Paul G.
> 
> I just tried compiling a simple test case using "gcc -shared" and
> linking directly to the DLL and I did find one problem. The example
> .exe is:
> 
> int foo(int a);
> 
> int main(void)
> {
>         int x = 3;
>         int y = foo(x);
> 
>         return y + 1;
> }
> 
> The example .dll is:
> 
> int foo(int a)
> {
>         int b = a + 5;
> 
>         return b * 2;
> }

	Interesting.

> 
> If I use GDB and try to step into the call to foo(), it doesn't work
> and just steps over it to the "return". I think the problem is that
> "foo" is just a stub that jumps indirectly using the import table
> (i.e. __imp__foo). However, if I use the GDB command "stepi" a few
> times I can step first into the stub:
> 
> 0x402af0 <foo>: jmp    *0x406158
> 
> Then using "stepi" again steps into the foo() function in the DLL, and
> GDB correctly loads the DLL symbols because I can step through foo(),
> etc. On the other hand, using "b foo" correctly sets a breakpoint in
> the DLL instead of in the stub, so apparently GDB knows that it is a
> stub in this case. I don't know if this is a bug or not.

	I have noticed this as well and I don't know if it is a bug or not myself.  It does appear 
that gdb actually renames the data symbol references.  So, if someone is expecting a 
specific value to have specific equivalent (eg, x = 3) and that value is not seen, when they do 
step through the .dll, then they might "assume" that the value was not ever defined to begin 
with at link time, even though the value is there, only with a different name reference.  This 
could be a bug, but again, I do not know.

> If the
> program is modified to declare foo() as dllimport, this problem does
> not occur because the compiler knows to call *__imp_foo instead of the
> stub.

	Ok.  So, if the value in question (eg. foo())  is not declared as dllimport, it could be 
causing problems when it comes to actually stepping through the .dll during a gdb session 
by nature of the fact that you are not in fact stepping through anything but a stub.  
Hmm...this could be responsible for what appears to be missing debug data that really isn't 
missing at all.  Thanks, Luke, I will add that to my list of possibilities here.

> Of course, this may have nothing to do with your problem, so if
> that is true then can you provide a minimal test case that
> demonstrates the problem?

	I am inclined to believe that it both does and does not have something to do with the 
problem.  I know, my saying that probably does not make much sense.  If it helps at all, I am 
thinking in set dynamics.

	Paul G.
> 
> Luke

"Krzysztof Wasilewski" <krz...@ko...> writes:

> Hello all,
> 
> Has anyone see such a thing? I have gcc 3.2.1, mingw runtime 2.3,
> binutils 2.13.90 and gdb 5.2.1. Gdb stops on some breakpoints, but it
> misses most of them! I'm really confused. I compiled my code with -g3
> and without -O.

gcc (as the other C/C++ compilers I know) doesn't default to
"no-optimization". You must give the -O0 flag to produce code which is
ok for full debug.

Which programming language are you using? C++? 

BTW, gdb 5.2.2 is out (no MinGW version for now)

> I also tried with Cygwin gdb, but it was exactly the
> same. I wonder if this could have anything to do with the fact that I
> have a dual-processor system? Am I the only person who is experiencing
> this problem?

-- 
Oscar

----- Original Message -----
From: "Greg Chicares" <chi...@mi...>
To: <min...@li...>
Cc: "Gisle Vanem" <gv...@br...>
Sent: Wednesday, 29 January 2003 12:48
Subject: Re: [Mingw-users] Building STLport 4.5


> Danny Smith wrote:
> >
> > This seems to be the culprit, in stl_gcc.h
> >
> > #   if (__GNUC__ >= 3)
> > #    define _STLP_HAS_NATIVE_FLOAT_ABS
> > #   endif
> >
> > An
> >
> > #undef _STLP_HAS_NATIVE_FLOAT_ABS
> >
> > lets complex.cpp compile.
> >
> > I know about fabs, but what is NATIVE_FLOAT_ABS?
>
> WAG: maybe it means the compiler (or, actually,
> its C standard library) implements
>   float abs(float); // C++98 26.5/6
> instead of just relying on
>   double abs(double);
>

I found it.  It's the overloaded abs in cmath in libstdc++ headers.
Unlike the C functions, it _is_ initially declared in std and not in
global.  Hence, the change adding
#  define _STLP_VENDOR_GLOBAL_CSTD 1

broke   _STLP_HAS_NATIVE_FLOAT_ABS

I think a better hack than undefining _STLP_HAS_NATIVE_FLOAT_ABS would
be this in stlport's cmath

# ifdef _STLP_HAS_NATIVE_FLOAT_ABS
#   ifdef  __GNUC__
using std::abs;
#   else
using _STLP_VENDOR_CSTD::abs;
#   endif
# endif

but its still pretty ugly.

I'll clean up as much as I can and submit a patch to Boris.

IMO, the real solution is modifying the mingw runtime headers to do the
right thing in C++ so that standard functions are declared in std in
the c headers.  The main problem I'm running into in doing that are the
ginclude'd  files like  stddef.h and stdarg.h which are installed by GCC
and which get included before any mingw version of the headers when
building libstdc++.


Danny