Patrick Hartling wrote:
> NightStrike wrote:
>> On 8/29/07, Patrick Hartling <patrick@...> wrote:
>>> I already did all of this. I am just trying to update the binutils pa=
>>> the toolchain since it is a couple of months out of date.
>> Ah, now I understand.
>>>> For information on building the crt, look here:
>>> I will look into this as I had not come across that project before. I=
>>> that it includes a newer snapshot of the CRT than the MinGW project
>>> downloads on SourceForge.
>>>> If you want, I can build you a toolchain and tar it up.
>>> That shouldn't be necessary, but I appreciate the offer. I haven't ye=
>>> confident that my 64-bit toolchain is working, so I may ask again lat=
>> Can you build a "Hello, world" yet?
> Yes, and Dependency Walker shows that it is a 64-bit binary. I should h=
> done that sooner. :)
> I saw that Binutils 2.18 was released yesterday, and I was able to buil=
> to target x86_64-pc-mingw32 without any troubles. Its ar still generate=
> files that ranlib and nm do not like, though. This is not too surprisin=
> there probably aren't too many differences yet between the CVS HEAD and=
> 2.18 branch. The Visual C++ linker also does not like them, and my real=
> here is to make a static build of FFmpeg that I can use with other soft=
> that is built with Visual C++.
Well, I am at a loss here. I have built multiple different versions of
binutils from the last two months, and I keep getting bad .a files. I hav=
built binutils using GCC 3.4.5 and 4.2.1 from MinGW as well as using vers=
3.4.4 from Cygwin. The last working version that I had was from June 29, =
rebuilding those sources does not work either. (If I had been more carefu=
I would have backed up the binutils installation that seemed to be workin=
but that's long gone now.)
My current theory is that GCC is the problem because I see some errors ab=
truncated .o files. I just built a GCC cross compiler from today's
Subversion trunk, and I still cannot make working .a files.
I also thought that it might help to update to the latest w64 CRT snapsho=
but I cannot build that either because of the same issues with .a files. =
error that I get is the following:
/usr/local/bin/x86_64-pc-mingw32-ar.exe rc libmingw32.a crt0_c.o crt0_w.o=
dll_argv.o gccmain.o CRT_fp10.o pseudo-reloc.o pseudo-reloc-list.o pesec=
cinitexe.o natstart.o gs_support.o atonexit.o dllmain.o dllentry.o
wildcard.o merr.o dllargv.o charmax.o xtxtmode.o tlssup.o xncommod.o
_newmode.o xthdloc.o mingw_helpers.o
C:\msys\1.0\local\bin\x86_64-pc-mingw32-ranlib.exe: libmingw32.a: File
format not recognized
I have been trying to see if I can make simple static libraries but have =
with limited success. In one case, I was able to create a 64-bit static
library from two object files, but when I looked at the contents using
x86_64-pc-mingw32-nm, it showed only the symbols from the first. If I try=
add a third object file to the static library, it complains that the firs=
=2Eo file in the archive is truncated.
Before I pursue this any further, I should ask this: should I expect to b=
able to link a 64-bit library made with MinGW with other 64-bit code
compiled using Visual C++ (version 8.0 in case it makes a difference)? I
have things working really, really well with 32-bit code, but the 64-bit
case seems just beyond my grasp. I understand that the 64-bit MinGW
toolchain and CRT are still in the early testing phases, but I get the
feeling that the source of my troubles is something really simple that I
have done wrong.
Patrick L. Hartling
VP Engineering, Infiscape Corp.