search for: libmingwex

...gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/ bin/ld.exe: cannot find -lmoldname C:/MinGW/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/ bin/ld.exe: skipping incompatible C:/MinGW/bin/../lib/gcc/x86_64-w64-mingw32/4.9 .1/../../../../x86_64-w64-mingw32/lib/libmingwex.a when searching for -lmingwex C:/MinGW/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/ bin/ld.exe: skipping incompatible C:/MinGW/bin/../lib/gcc/x86_64-w64-mingw32/4.9 .1/../../../../x86_64-w64-mingw32/lib\libmingwex.a when searching for -lmingwex C:/MinGW/bin/../lib/gc...

Hi Martell, r289280 was not intended to be a significant functional change in the sense that it would cause programs to fail to link, so this may be a bug I introduced in r289280 (or one of the followup patches, which also changed link order). How is crt0_c.c being added to the link? If crt0_c.c is supplying a definition of the main function I would expect it to be in an archive which would

Timothy B. Terriberry wrote: > Instead I've attached a patch that uses fgetpos/fsetpos. This is > totally untested (I haven't even checked it compiles), but the idea > should work. MSDN says "The pos value is stored in an internal format and is intended for use only by *fgetpos* and *fsetpos*." (http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx), so