Subject: Re: EGCS 1.1.2 - Mingw32 - wxWindows 2.0
From: "Richard Ashwell" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Fri, 09 Apr 1999 17:22:13 PDT

Mumit Khan,

First, Thank you very much for replying.

Second,  don't worry I don't get frustrated, just stuck sometimes.  
Your expertise is much appreciated.

Third, Something you said sparked my memory, and this is probably the 
key,  after installing EGCS-1.1.2 MingW32 clean without cygwin, I did 
do a modify of the library stuff to make them use MSCVRT instead of 
CRTDLL or something to that effect.  I forget what instructions I was 
following, I was in that More Power Grunt mode and thought hey I 
would get more library functions to call If I did it so I did.  I did 
create the Backup's that the instructions recomended.  So first I 
will include in this message the outputs you requested to look into 
this further, but also on this hunch I will undo the MSCVRT stuff and 
see if the REAL original EGCS-1.1.2 Minw32 stuff gets the same error.

>Interesting .... The symbol __imp__HUGE_dll is a reference to the 
symbol
>HUGE_dll exported by CRTDLL runtime and is in libcrtdll.a. Whenever 
you 
>link using GCC, it automatically links in -lcrtdll, and so it should 
>always find this symbol. 
>
>Please check the following:
>  
>1. none of the variables are defined in the environment (ie., as DOS
>   variables) -- GCC_EXEC_PREFIX, COMPILER_PATH, LIBRARY_PATH, 
>   C_INCLUDE_PATH, CPLUS_INCLUDE_PATH. If these are set, UNSET these 
>   first. I don't like hidden surprises.

Done GCC_EXEC_PREFIX seems to have been set to 
C:\EGCS-1.1.2\lib\gcc-lib\

I unset it though.  And I will remove it from mingw32.bat If you say 
that this should be done, so that it doesn't get set in the future. 
Via My Shell.

>2. Make sure you're linking with the correct libcrtdll.a:
>   
>   $ gcc -print-file-name=libcrtdll.a
>

C:\usr\local>gcc -print-file-name=libcrtdll.a
C:\EGCS-1~1.2\BIN\..\lib\gcc-lib\i386-mingw32\egcs-2.91.66
\..\..\..\..\i386-ming
w32\lib\libcrtdll.a

>   should print `c:\egcs-1.1.2\i386-mingw32\lib\libcrtdll.a'

At this point my setup appears to be possibly incorrect, although I 
don't know if it had to do with the MSCVRT stuff, or something else.  
But if I where to trace the ..\ backwards it looks like the end 
result is the same, so it might be correct.

>3. Add the `-v' option to gcc when linking to see what's going on.
>

At this point I modified the Makefiles for wxWindows to add the -v 
flag to the LDFLAGS variable.  Then I re-ran the Makefile for the 
test sample included with wxwindows with the following results:

C:\wx\samples\tab>make -f makefile.g95
gcc -Wl,--subsystem,windows -mwindows -LC:/wx/lib  -v -o test.exe 
test.o test_re
sources.o C:/wx/lib/libwx.a -lstdc++ -lgcc -lwinspool -lwinmm -
lshell32 -lcomctl
32 -lctl3d32 -lodbc32 -ladvapi32
Reading specs from C:\EGCS-1~1.2\BIN\..\lib\gcc-lib\i386-mingw32\egcs-
2.91.66\sp
ecs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
 ld --subsystem windows -o test.exe C:\EGCS-1~1.2\BIN\..\lib\gcc-
lib\i386-mingw3
2\egcs-2.91.66\..\..\..\..\i386-mingw32\lib\crt2.o -LC:/wx/lib -
LC:\EGCS-1~1.2\B
IN\..\lib\gcc-lib\i386-mingw32\egcs-2.91.66 -LC:\EGCS-1~1.2
\BIN\..\lib\gcc-lib -
L\egcs-1.1.2\lib\gcc-lib\i386-mingw32\egcs-2.91.66 -LC:\EGCS-1~1.2
\BIN\..\lib\gc
c-lib\i386-mingw32\egcs-2.91.66\..\..\..\..\i386-mingw32\lib -L\egcs-
1.1.2\lib\g
cc-lib\i386-mingw32\egcs-2.91.66\..\..\..\..\i386-mingw32\lib -
LC:\EGCS-1~1.2\BI
N\..\lib\gcc-lib\i386-mingw32\egcs-2.91.66\..\..\.. -L\egcs-1.1.2
\lib\gcc-lib\i3
86-mingw32\egcs-2.91.66\..\..\.. --subsystem windows test.o 
test_resources.o C:/
wx/lib/libwx.a -lstdc++ -lgcc -lwinspool -lwinmm -lshell32 -
lcomctl32 -lctl3d32
-lodbc32 -ladvapi32 -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -
lgdi32 -lcomdl
g32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -
lmsvcrt

I left your final test step for reference to anyone that wants to 
learn to trace stuff in compiled libs.  But as you can see from the 
above.  I now got a clean link.

CONCLUSION:  The only change I made was to unset the GCC_EXEC_PREFIX 
before I began. I take this to mean that it should not be set and 
will remark it out of my mingw32.bat file pronto.  I never got around 
to undoing the MSCVRT stuff, and as it turns out I was on the wrong 
track I think.

>4. If all of provide no clue, time for some detective work. First 
check
>   for HUGE_dll in the C++ runtime library:
>     
>   C:\> cd c:/egcs-1.1.2/lib
>   C:\> nm --print-file-name libstdc++.a | nm HUGE
>   libstdc++.a:floatconv.o:         U ___imp__HUGE_dll
>
>   now, check libcrtdll.a:
>
>   C:\> cd c:/egcs-1.1.2/i386-mingw32/lib
>   C:\> nm --print-file-name libcrtdll.a | nm HUGE
>   libcrtdll.a:ds16.o:00000000 T __HUGE_dll
>   libcrtdll.a:ds16.o:00000000 ? ___imp__HUGE_dll
>   libcrtdll.a:ds16.o:00000000 ? __imp___HUGE_dll
>
>   If you get something else, there's a problem somewhere. We can 
talk
>   then.
>

and as for:

>> 
>> REM
>> REM replace k:\mingw32 with whatever your installation root may be.
>> REM
>> path c:\egcs-1.1.2\bin;%PATH%;
>> 
>> SET GCC_EXEC_PREFIX=c:\egcs-1.1.2\lib\gcc-lib\
>> set BISON_SIMPLE=c:\egcs-1.1.2\share\bison.simple
>> set BISON_HAIRY=c:\egcs-1.1.2\share\bison.hairy
>> set C_INCLUDE_PATH=c:\egcs-1.1.2\include
>> set CPLUS_INCLUDE_PATH=c:\egcs-1.1.2\include\g++;c:\egcs-1.1.2
\include
>> set LIBRARY_PATH=c:\egcs-1.1.2\lib
>> set GCC_EXEC_PREFIX=c:\egcs-1.1.2\lib\gcc-lib\
>
>Please get rid of all bug BISON_SIMPLE and BISON_HAIRY, but only if 
you
>have bison installed. It doesn't come with Mingw compiler 
distribution.

Yes I the BISON I have installed, and am leaving only the BISON 
variables set.

>Try not to be frustrated by these problems; these are just part of 
the
>learning process, albeit somewhat cruel at times. I have much more
>trouble when I have to use Visual Studio once in a while to check for
>something using VC 6; it took me a while one time to figure out why
>it insisted on linking libpcmtd.lib or some such library no matter 
what
>I did until I changed some linker option somewhere ...

For me it was the frustration of the Simplton VB, and somehow client 
after client would get OCX's unregistered somehow in the registry and 
Crash things over and over again.

Regards,
Richard

_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com

--
Want to unsubscribe from this list?
Send a message to [email-masked]