On 01.03.2013 17:27, Sebastian Wolff wrote: > 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.
Have you tried to put the_third_party_lib into a dll (build with msvc), and to link against this dll from mingw? Using multiple dlls where all uses different runtimes should be possible without problems. > > 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. > > > 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. > > On Windows 7, however, I get the error > "R6034 An application has made the attempt to load the C runtime incorrectly" > > 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. > > 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. > > 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). > > 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. > > 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 > > 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) > > > > 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? > > 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 > > > Any suggestions on how to solve this issue using Mingw-w64 are very welcome! > > > Best regards > > Sebastian > > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
