From: Keith M. <kei...@us...> - 2008-12-02 23:07:25
|
On Tuesday 02 December 2008 03:41:56 Hin-Tak Leung wrote: > --- On Tue, 2/12/08, Chris Sutcliffe <ir0...@gm...> wrote: > <snipped> > > > > Very disappointing, since 2.18.50 builds OOTB, with > > > exactly the same configuration options. > > > > Given that the native build works, are we good, or do we > > need to hold-off while the cross-compiler is sorted out? > > Hiya, which way are you doing the building the cross-compiler? At this point, I'm just trying to build binutils-2.19 free-standing, configured for --target=mingw32, with identically the same options as we use in the cross-compiler build scripts. > I posted a diff - filed as one of the bugs/features in the > sourceforge web site - to update the cross-compile script to cope > with the "mingwrt" new naming schemes a while ago, and that seems > to work. I know you did; I've been following up on that, thanks. This problem is not, in any way, related to mingwrt naming. > (I am building on x86_64 linux to host on x86_64 linux to target > win32 - I think that's the way to word it). Yes, that seems right. > So I have it finished building Yes, so have I, with binutils-2.18.50, gcc-3.4.5, mingwrt-3.15.1 and w32api-3.12; it's when I plugged in binutils-2.19 that it broke, and I now know why; the tarball, as shipped by the binutils folks, has: * a messed up timestamp for bfd.info, which depends on elf.texi, and which in turn depends on elf.c; elf.c is newer than either of the dependents, requiring a regeneration of the info file, so building fails if makeinfo isn't installed, even though it isn't supposed to be needed. The regenerated elf.texi is, byte for byte, identical to the distributed version, so the regeneration isn't really necessary; this problem may be resolved by touching elf.texi and bfd.nfo in the source tree, to reschedule the timestamps. * missing deffilep.c, from the ld directory. This can be generated, if bison is installed, but once again, this is not supposed to be necessary, for building from a release tarball; it may be corrected, by adding the generated deffilep.c to the source hierarchy, and repackaging the tarball. > - I haven't tried building win32 things with it yet. No, I haven't got that far yet, either. Chris, lets hold off for a few more days, while I test my repackaged source tarball. When I'm satisfied, I'll upload it to `incoming' for you, then you can go ahead with the release. Regards, Keith. |