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.
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
