On Tue, Jul 18, 2017 at 6:36 PM, Georg-Johann Lay <a...@gjlay.de> wrote: > Hi, I tried to build a canadian cross with Configured with > --build=x86_64-linux-gnu > --host=i686-w64-mingw32 > --target=avr > > While the result appears to work under wine, I am getting the > following error from ld in a non-LTO compile + link: > > e:/winavr/8.0_2017-07-18/bin/../lib/gcc/avr/8.0.0/../../../../avr/bin/ld.exe: > error: asprintf failed > > After playing around I found that -fno-use-linker-plugin avoids that > message, and I speculated that the error is emit by lto-plugin.c > > In claim_file_handler() we have: > > > /* We pass the offset of the actual file, not the archive header. > Can't use PRIx64, because that's C99, so we have to print the > 64-bit hex int as two 32-bit ones. */ > int lo, hi, t; > lo = file->offset & 0xffffffff; > hi = ((int64_t)file->offset >> 32) & 0xffffffff; > t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi) > : asprintf (&objname, "%s@0x%x", file->name, lo); > check (t >= 0, LDPL_FATAL, "asprintf failed"); > > > If hi != 0, then why is hi printed at the low end? Shouldn't hi and lo > be swapped like so > > t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, hi, lo) > > if this is supposed to yield a 64-bit print?
Looks odd indeed... I suppose such large archives are the exception ;) > > What else could lead to an "asprintf failed" ? Unfortunately I have > no idea how to debug that on the host... memory allocation failure I guess. Richard. > Johann >
