Linking on powerpc errors on relocations in non-writable sections

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build revision 41876 of llvm-svn on PowerPC Mac OS X (10.4)
2. Build revision 171 of iphone-dev 
3. Try to cross-compile ruby (after tweaking config.status)

What is the expected output? What do you see instead?

A working ruby interpreter

Please provide any additional information below.

arm-apple-darwin-ar rcu libruby-static.a array.o bignum.o class.o compar.o
dir.o dln.o enum.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o
math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o
re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o
variable.o version.o memcmp.o  dmyext.o
arm-apple-darwin-gcc -dynamiclib -undefined suppress -flat_namespace
-install_name /usr/local/ruby/lib/libruby.dylib -current_version 1.8.6
-compatibility_version 1.8   array.o bignum.o class.o compar.o dir.o dln.o
enum.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o
numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o
regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o
variable.o version.o memcmp.o  dmyext.o -ldl -lobjc   -o libruby.1.8.6.dylib
/usr/local/bin/arm-apple-darwin-ld: warning multiple definitions of symbol
_memcmp
memcmp.o definition of _memcmp in section (__TEXT,__text)
/usr/local/share/iphone-filesystem/usr/lib/libdl.dylib(memcmp.So)
definition of _memcmp
/usr/local/bin/arm-apple-darwin-ld:
/usr/local/lib/gcc/arm-apple-darwin/4.0.1/libgcc.a(_divsi3.o) has external
relocation entries in non-writable section (__TEXT,__text) for symbols:
___div0
collect2: ld returned 1 exit status
make: *** [libruby.1.8.6.dylib] Error 1

Original issue reported on code.google.com by x...@hdm.io on 16 Sep 2007 at 1:41

[GoogleCodeExporter]

Seems related:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14612

Original comment by x...@hdm.io on 16 Sep 2007 at 4:50

[GoogleCodeExporter]

Applying that patch seemed to resolve it (either that, or its another random mem
corruption issue).

Original comment by x...@hdm.io on 16 Sep 2007 at 7:47

[GoogleCodeExporter]

This should be forwarded to LLVM.

Original comment by nightwat...@gmail.com on 23 Sep 2007 at 9:11

• Changed state: WontFix