pereraa / iphone-dev

Automatically exported from code.google.com/p/iphone-dev
0 stars 0 forks source link

libc.dylib unknown flags (type) of section 4 (__TEXT,__dof_magmalloc) in load command 0 #185

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
building llvm-gcc-4.0 against the 3GS firmware fails with the following:

/home/julien/src/iphone-dev/build/llvm-gcc-4.0-iphone/gcc/xgcc
-B/home/julien/src/iphone-dev/build/                                      
   lvm-gcc-4.0-iphone/gcc/ -B/usr/local/arm-apple-darwin/bin/
-B/usr/local/arm-apple-darwin/lib/ -isys                                  
       em /usr/local/arm-apple-darwin/include -isystem
/usr/local/arm-apple-darwin/sys-include -O2  -DIN_G                       
                  C -DCROSS_DIRECTORY_STRUCTURE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -                                
         old-style-definition  -isystem ./include  -fPIC -pipe -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_F                                
         OAT_NOT_NEEDED -Dinhibit_libc -I. -I.
-I../../../llvm-gcc-4.0-iphone/gcc -I../../../llvm-gcc-4.0-ip             
                            one/gcc/.
-I../../../llvm-gcc-4.0-iphone/gcc/../include
-I../../../llvm-gcc-4.0-iphone/gcc/../libcp                               
          /include  -I/home/julien/src/llvm-svn/include
-I/home/julien/src/llvm-svn/include -Dmalloc=kern_os_                     
                    alloc -Dfree=kern_os_free -DLIBCC_KEXT -static -fno-pic
-fno-exceptions -fno-non-call-exceptions -D                               
          _divsi3 -xassembler-with-cpp -c
../../../llvm-gcc-4.0-iphone/gcc/config/arm/lib1funcs.asm -include        
                                  ibgcc/kext/_divsi3.vis -o
libgcc/kext/_divsi3.o
/usr/local/bin/arm-apple-darwin-ld: /opt/iphone_root//usr/lib/libc.dylib
unknown flags (type) of setion 4 (__TEXT,__dof_magmalloc) in load command 0
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dylib] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
`/home/julien/src/iphone-dev/build/llvm-gcc-4.0-iphone/gcc'
make[1]: *** [stmp-multilib] Error 2
rm cpp.pod fsf-funding.pod gcc.pod gcov.pod gpl.pod gfdl.pod
make[1]: Leaving directory
`/home/julien/src/iphone-dev/build/llvm-gcc-4.0-iphone/gcc'
make: *** [all-gcc] Error 2

Original issue reported on code.google.com by julien.l...@googlemail.com on 8 Jul 2009 at 9:03

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
I have the same error. Still no fix!

Original comment by onida...@gmail.com on 11 Jul 2009 at 9:07

GoogleCodeExporter commented 8 years ago
i have the same error , too . Need Help !!

Original comment by tyric...@gmail.com on 16 Jul 2009 at 1:37

GoogleCodeExporter commented 8 years ago
Same problem here, fw 3.0 jailbreaked by redsn0w.

Original comment by pal...@gmail.com on 4 Aug 2009 at 6:59

GoogleCodeExporter commented 8 years ago
Any plans to have a look at this issue ?

Original comment by roberto....@gmail.com on 18 Sep 2009 at 7:34

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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