On 1/13/2012 18:41, JonY wrote:
> On 1/12/2012 04:30, Christian Franke wrote:
>> JonY wrote:
>>> On 1/6/2012 04:42, Kai Tietz wrote:
2012/1/5 Christian Franke:
> [Originally sent to Cygwin mailing list]
>
> When printf/scanf functions from MinGW runtime are selected via
> __USE
2012/1/13 Daniel Green :
> Kai Tietz writes:
>
>> Hmm, == is the thing we want here, but it seems that in combination
>> with data it causes issues. Does build being successful by changing
>> line to vsnprintf DATA == _vsnprintf
>> ?
>
> vsnprintf DATA == _vsnprintf works.
Thanks, fix applied at
Kai Tietz writes:
> Hmm, == is the thing we want here, but it seems that in combination
> with data it causes issues. Does build being successful by changing
> line to vsnprintf DATA == _vsnprintf
> ?
vsnprintf DATA == _vsnprintf works.
-
Kai Tietz schreef op vr 13-01-2012 om 22:50 [+0100]:
> 2012/1/13 Daniel Green :
> > dlltool outputs the following:
> >
> > # dlltool --as-flags=--64 -m i386:x86-64 -k --as=as --output-lib
> > lib64/libmsvcrt.a --input-def
> > /crossdev/src/mingw-w64-svn/mingw-w64-crt/lib64/msvcrt.def --dllname
>
2012/1/13 Daniel Green :
> dlltool outputs the following:
>
> # dlltool --as-flags=--64 -m i386:x86-64 -k --as=as --output-lib
> lib64/libmsvcrt.a --input-def
> /crossdev/src/mingw-w64-svn/mingw-w64-crt/lib64/msvcrt.def --dllname
> msvcrt.dll
>
> c:\MinGW64\bin\dlltool.exe: Syntax error in def f
dlltool outputs the following:
# dlltool --as-flags=--64 -m i386:x86-64 -k --as=as --output-lib
lib64/libmsvcrt.a --input-def
/crossdev/src/mingw-w64-svn/mingw-w64-crt/lib64/msvcrt.def --dllname msvcrt.dll
c:\MinGW64\bin\dlltool.exe: Syntax error in def file C:/crossdev/src/mingw-w64-s
vn/mingw
Kai Tietz schreef op vr 13-01-2012 om 16:55 [+0100]:
> Well,
>
> I have used sys-root=/usr/local default.
>
> The adjusted command gives me for
>
> $ x86_64-w64-mingw32-nm /usr/local/x86_64-w64-mingw32/lib/libmsvcrt.a
> | grep wcslen
> I __imp_wcslen
> T wcslen
Well,
I have used sys-root=/usr/local default.
The adjusted command gives me for
$ x86_64-w64-mingw32-nm /usr/local/x86_64-w64-mingw32/lib/libmsvcrt.a
| grep wcslen
I __imp_wcslen
T wcslen
So symbol is present.
-
Earnie Boyd schreef op vr 13-01-2012 om 09:11 [-0500]:
> It appears to me to be a default library ordering problem. -lmsvcrt
> needs to follow -lmingwex in the linker parameter order. Add -v to
> your gcc options to see the order of default libraries being passed to
> the linker.
Here's the verb
JonY schreef op vr 13-01-2012 om 22:12 [+0800]:
> Can you do:
>
> x86_64-w64-mingw32-nm
> /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libmsvcrt.a | grep wcslen
>
> Please post the output, thanks.
This command doesn't give any output.
If the command is executed for the i686 library then it does g
gt; packages for Fedora. First I've updated to gcc 4.7 (20120106 snapshot),
> then binutils head (20120113 snapshot) and then mingw-w64 trunk
> (20120112 snapshot).
>
> Now when I try to compile a minimal .c file the following linker error
> occurs for the x86_64 target:
>
> $
se toolchain
> packages for Fedora. First I've updated to gcc 4.7 (20120106 snapshot),
> then binutils head (20120113 snapshot) and then mingw-w64 trunk
> (20120112 snapshot).
>
> Now when I try to compile a minimal .c file the following linker error
> occurs for the x86_64 target:
&
runtime. Or binutils is broken, but the link-order used - as
> you have shown it - looks correct.
>
Hey,
I've been bitten by this issue too while updating the base toolchain
packages for Fedora. First I've updated to gcc 4.7 (20120106 snapshot),
then binutils head (20120113 snap
On 1/12/2012 04:30, Christian Franke wrote:
> JonY wrote:
>> On 1/6/2012 04:42, Kai Tietz wrote:
>>> 2012/1/5 Christian Franke:
[Originally sent to Cygwin mailing list]
When printf/scanf functions from MinGW runtime are selected via
__USE_MINGW_ANSI_STDIO, then format string che
14 matches
Mail list logo
