This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Paul Thiessen <paul@grserv.med.jhmi.edu> writes: > Thanks for your help! > This isn't a big deal, but I'm just trying to understand more fully how > all this works: I do notice that crtdll.dll is still being linked > in. (I tagged on an objdump -p at the end of this.) I thought from what I > read earlier that msvcrt.dll was basically a drop-in replacement for > crtdll.dll, but apparently that's not totally true? That there are still a > few functions in crtdll that msvcrt doesn't have? You're absolutely correct the crtdll is still being linked in certain conditions, but so far I haven't seen any problems due to it. It only happens when you use c++ or g77 (but not gcc), and the reason is the following: the math library is defined to libcrtdll.a when we build mingw32 compiler at compile time, and even if we use the msvcrt specs, it gets linked in. The workaround is the following (of course, you need to do this when if you find problems): instead of: $ c++ -o foo foo.o do, $ gcc -o foo foo.o -lstdc++ For g77, use gcc with -lg2c. The reason for not seeing any problem due to this is that msvcrt is a superset and already resolves all the references and it never gets to load anything from CRTDLL that conflicts. You check always check by telling the linker to be verbose (gcc -Wl,--verbose I believe is the right flag), which shows all the references. You can also use the map file option, -Wl,-M, to enumerate the resolution process. This is fixed in egcs-1.2. Regards, Mumit -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |