Hello Sebastian, 2013/3/1 Sebastian Wolff <[email protected]>: > Dear list! > > first of all: Thanks for providing MingW-w64. Nevertheless, I fell into a > problem that I can not solve without help. Now I hope someone of you can > give me some advice to solve it. > > I use Mingw-w64 distributed with OpenSuse Linux 12.2 64 Bit (based on Gcc > 4.7.2). I need to call a function from a (static!) third-party library which > was compiled using VC++ 9.0 (VS2008) targeting amd64, file name: > the_third_party_lib.lib. the_third_party_lib.lib is pure C - hence it > should be binary compatible with GCC.
So there shouldn't be much trouble about that beside that newer runtime might uses additional exports not present by default in the default-version msvcrt.dll. > Now I have an interesting situation: > > Linking with standard options gives me: >> undefined reference to `__sys_nerr' >> undefined reference to `__sys_errlist' > > I can resolve this by changing the specs file to link against libmsvcr90.a > Then, GCC links fine: >> gcc -v -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 --param=ssp-buffer-size=4 >> -mms-bitfields -fno-keep-inline-dllexport -fpermissive -fexceptions -frtti >> main.c -lthe_third_party_lib -lruntmchk -lole32 -loleaut32 -lWbemUuid >> -lws2_32 -lcomctl32 -lcomdlg32 -lnetapi32 -mwindows -specs=spec90 > Note: The libraries runtmchk and WbemUuid are from the VS2008 and are needed > by the_third_party_lib. > > The link command (excerpted from gcc -v) is: >> collect2 -m i386pep --subsystem windows -Bdynamic lib/crt2.o >> lib/crtbegin.o -L. -Llib tmp.o -lthe_other_lib -lruntmchk -lole32 -loleaut32 >> -lWbemUuid -lws2_32 -lcomctl32 -lcomdlg32 -lnetapi32 -lmingwthrd -lmingw32 >> -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcr90 -lgdi32 -lcomdlg32 -ladvapi32 >> -lshell32 -luser32 -lkernel32 lib/crtend.o > Hence it really takes the modified specs and overrides msvcrt. Well, the issue you have here is solvable. You should simply use additionally on command-line for linking the -static option. The point here is that gcc's runtime-DLLs are linked against msvcrt.dll. also -lmoldname links against msvcrt.dll, so for what purposes you actual need it? > Running the executable using latest WINE on Linux also works fine: There is > no segfault and I can call the API of the_third_party_lib without errors. Sure, Wine doesn't do manifest-file checks. Therefore it runs without issues. > On Windows 7, however, I get the error > "R6034 An application has made the attempt to load the C runtime > incorrectly" That is caused by manifest-file. the syntax of this file has to fit and the used runtime-libraries should be mentioned with proper hash within it. There is some FAQ on our Wiki page, and also some good blogs about how to write proper manifest files. > This error may happen on recent Windows versions if no or a wrong manifest > is applied. Further it can appear in case of conflicting runtimes in a > single application. Right, try to use -static option and avoid use of -lmoldnames, this should avoid double runtimes. > I also put a manifest file next to my executable a.exe: > a.exe.manifest: > <?xml version='1.0' encoding='UTF-8' standalone='yes'?> > <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> > <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> > <security> > <requestedPrivileges> > <requestedExecutionLevel level='asInvoker' uiAccess='false' /> > </requestedPrivileges> > </security> > </trustInfo> > <dependency> > <dependentAssembly> > <assemblyIdentity type='win32' name='Microsoft.VC90.CRT' > version='9.0.21022.8' processorArchitecture='amd64' > publicKeyToken='1fc8b3b9a1e18e3b' /> > </dependentAssembly> > </dependency> > </assembly> > > and I still get the same error on Windows7. There were some rumors in the > WWW hinting that a mistake in the manifest could be the problem. Hence I > built the same executable with VC++ and copied its manifest to be safe. Sure, the issue here is msvcrt.dll dependency for you. > The tool "Dependency Walker", however, starts to track the origin of the > problem: There exist references to both, msvcrt.dll AND msvcr90.dll. > > > After some discussion on the MingW mailing list I started a new approach: > > I now compiled my own GCC (4.7.2), my own static libgcc (the GCC DLLs > introduced dependencies to msvcrt.dll, hence I - probably - need static > linkage) and my own mingw-w64 runtime (SVN trunk). No, just use -static option! > For the mingw-w64 runtime, I redefined new specs before compiling it. The > specs were defined according to the step-by-step instructions at > http://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file > > There is one problem: There is no liboldname90 in Mingw-w64, hence I kept > liboldname. Yes, for what purpose you need it? > The runtime was recompiled with > > MINGW_LIB="--enable-lib64 --disable-lib32 > $M_SOURCE/mingw-w64/mingw-w64-crt/configure --host=$MINGW_TRIPLE \ > --prefix=$M_CROSS/$MINGW_TRIPLE $MINGW_LIB > make -j6 CFLAGS="-specs specs_msvcr90" > make install Well, you don't need to rebuild runtime. There is actual no need to do that at all. > Further I checked if the compiler is indeed using the new specs. It does. > > The test program was then compiled by > $CC -v -specs specs_msvcr90 -DMINGW_HAS_SECURE_API=1 \ > -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 \ > --param=ssp-buffer-size=4 -mms-bitfields -fno-keep-inline-dllexport \ > -O2 -mthreads -Wall -frtti $SOURCES $LIBDIR $INCDIR $MYLIB \ > -lruntmchk -lole32 -loleaut32 -lWbemUuid -lws2_32 -lcomctl32 \ > -lcomdlg32 -lnetapi32 -static-libgcc -static > > > Still I get the same error. Dependency walker gives me the same dependencies > as before: > advapi32.dll comctl32.dll comdlg32.dll kernel32.dll msvcrt.dll msvcr90.dll > netapi32.dll ole32.dll oleaut32.dll user32.dll ws2_32.dll > Interestingly, for MSVCRT.dll it only shows a few methods on the C-side, > i.e. _access, _getcwd, _getpid, _open, _strdup, _stricmp, _unlink. The > profiling gives the error in: > "DllMain(0x0000000074980000, DLL_PROCESS_ATTACH, 0x000000000022FB00) in > "MSVCR90.DLL" returned 0 (0x0)." > (after calling SLL_PROCESS_ATACH from MSVCRT) Sure, as this approach doesn't solve your issue. > > The discussion on the MingW mailing list ended at this point referring to > the Mingw-w64 list. Several people suggested linking against liboldname90 > and not liboldname. I know that Mingw-w64 started as a fork of MingW and > that the developers wiped out most of historic stuff - probably too much? Hmm, no. I don't see a good reason for moldname-library. Again for what purpose you are needing it? > One more thing: With MingW it is possible to link against Msvcr90.dll > cleanly. See for example the following blog: > However, I am at the end with my ideas in fixing this problem. I checked out > some recent posts: >> http://developer.berlios.de/devlog/akruis/2012/06/10/msvcr90dll-and-mingw/ >> https://lists.launchpad.net/kicad-developers/msg09473.html That isn't true. The issue isn't MinGW.org or MinGW-w64 venture, it is a matter of runtime-libraries used by default. Both ventures are using by default msvcrt.dll library. So gcc's shared runtime-libraries are built using msvcrt.dll library. So same issue, and things applying here to MinGW.org are applying to mingw-w64, too. > > Any suggestions on how to solve this issue using Mingw-w64 are very welcome! As said above. Avoid use of moldname, as I don't see here actual a good reason to us it at all. But well, I might be wrong, so please let me know for what purposes you need it here? Secondly use additionally the -static option on linking. This should avoid most msvcrt.dll references, > > Best regards > > Sebastian Regards, Kai ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
