Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Message-ID: <19990410002216.59575.qmail@hotmail.com> X-Originating-IP: [129.37.77.91] From: "Richard Ashwell" To: khan AT xraylith DOT wisc DOT EDU, richval AT hotmail DOT com Cc: cygwin AT sourceware DOT cygnus DOT com Subject: Re: EGCS 1.1.2 - Mingw32 - wxWindows 2.0 Date: Fri, 09 Apr 1999 17:22:13 PDT Mime-Version: 1.0 Content-type: text/plain 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 cygwin-unsubscribe AT sourceware DOT cygnus DOT com