Open GoogleCodeExporter opened 8 years ago
Almost forgot: I tried the build on Debian sid using gcc 4.3
Original comment by julien.l...@googlemail.com
on 8 Jul 2009 at 9:08
I have the same error. Still no fix!
Original comment by onida...@gmail.com
on 11 Jul 2009 at 9:07
i have the same error , too . Need Help !!
Original comment by tyric...@gmail.com
on 16 Jul 2009 at 1:37
Same problem here, fw 3.0 jailbreaked by redsn0w.
Original comment by pal...@gmail.com
on 4 Aug 2009 at 6:59
Any plans to have a look at this issue ?
Original comment by roberto....@gmail.com
on 18 Sep 2009 at 7:34
Well i had this issue on cygwin, firmware 3G 3.0, trying to build gcc-4.2.
The pb was i was not using ld64 but ld as linker from the odcctools package. I
did that because
1: it is written to do so in the wiki (../../odcctools/configure
--target=arm-apple-darwin --
disable-ld64)
2: ld64 did not compile anyway.
But actually, you need to build ld64 coz that's the only one which knows how to
handle
S_16BYTE_LITERALS SECTION_TYPEs (simple ld gives the error we've reported if
this kind of
section type is encoutered).
Btw, i had pb building ld64 because of this "patch" (saurik added this on rev
287) =>
// start temp HACK for cross builds
extern "C" double log2 ( double ) throw();
#define __MATH__
// end temp HACK for cross builds
i just tried to remove it, and ld64 compiles fine now. And so do gcc-4.2. Hope
it'll help, even
if cygwin is not officially supported, i landed there when i was googling for
my pb :)
(Sorry for my bad english :-/)
Original comment by Gbil...@gmail.com
on 28 Feb 2010 at 3:15
I am getting this error as well on Ubuntu 10.04. G++ 4.1.3. I tried enabling 64
bit, but that didn't work:( there were more errors then your quick fix.
Original comment by ashr...@gmail.com
on 5 Jul 2010 at 12:02
Thanks Gbillou for the hint, I got the ld64 to compile (just needed a clean).
Although top of tree had new changes anyway.
So I get this error still. I added some debug information to show what
section_type it wanted:
error_with_cur_obj("unknown flags %lu (type) of section %lu"
" (%.16s,%.16s) in load command %lu",
section_type, j, s->segname, s->sectname, i);
The output is "libc.dylib unknown flags 15 (type)"
Looking at loader.h
#define S_16BYTE_LITERALS 0xe /* section with only 16 byte literals */
we only go up to 16byte literals.
I guess we need support for S_32BYTE_LITERALS? I am using firmware 3.2.
Original comment by ashr...@gmail.com
on 5 Jul 2010 at 10:58
right, obdcctools needs to be updated to use the new platform
namely this (Although all the rest too)
#define S_DTRACE_DOF 0xf /* section contains
I don't know how simple this is to do.. probably not.
Original comment by ashr...@gmail.com
on 5 Jul 2010 at 11:27
It seems that these DTRACE_DOF sections aren't required for normal operations.
I've made a small tool which patches flags 0xf to 0x1 (zerofill). Such patched
dylibs work fine with both the apple and odcc linkers. Yes, this is a terrible
hack :)
Original comment by q...@kuku.eu.org
on 12 Jul 2010 at 7:55
Attachments:
Right. Could you tell me how to use this tool (strip-dylibs.c). thanks.
Original comment by henryshu...@gmail.com
on 27 Aug 2010 at 3:17
Original issue reported on code.google.com by
julien.l...@googlemail.com
on 8 Jul 2009 at 9:03