Log in

View Full Version : Latest Git X264 won't compile under OSX 10.5.6


e88z4
25th December 2008, 03:24
Could someone please help me with this error for how to fix it? I compiled with gcc 4.0.1 and latest Xcode 10.5. I am trying to build a shared library for mplayer.
Thanks in advance.

ld: warning codegen in _x264_predict_16x16_init_mmx (offset 0x0000000E) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_16x16_init_mmx (offset 0x0000001A) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_16x16_init_mmx (offset 0x00000033) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_16x16_init_mmx (offset 0x0000003D) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_16x16_init_mmx (offset 0x00000050) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_16x16_init_mmx (offset 0x00000064) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8c_init_mmx (offset 0x0000000E) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8c_init_mmx (offset 0x0000001B) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8c_init_mmx (offset 0x00000035) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x0000000E) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x0000001F) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x00000027) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x0000002F) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x00000037) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x0000003F) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x00000047) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x00000051) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x00000059) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_8x8_init_mmx (offset 0x00000061) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_4x4_init_mmx (offset 0x00000011) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_4x4_init_mmx (offset 0x00000019) prevents image from loading in dyld shared cache
ld: warning codegen in _x264_predict_4x4_init_mmx (offset 0x00000021) prevents image from loading in dyld shared cache
ld: absolute addressing (perhaps -mdynamic-no-pic) used in _get_ref from common/mc.o not allowed in slidable image
collect2: ld returned 1 exit status
make: *** [libx264.65.dylib] Error 1

cacepi
25th December 2008, 04:46
Could someone please help me with this error for how to fix it? I compiled with gcc 4.0.1 and latest Xcode 10.5.
I'm getting the crash too, on 32-bit only when building a dynamic library. 64-bit and 32/64-bit static libraries work.

ld: absolute addressing (perhaps -mdynamic-no-pic) used in _get_ref from common/mc.o not allowed in slidable image


Ah, here's why. From the gcc manual:

-mdynamic-no-pic
On Darwin and Mac OS X systems, compile code so that it is not relocatable, but that its external references are relocatable. The resulting code is suitable for applications, but not shared libraries.

Therefore, you need to remove -mdynamic-no-pic:

diff --git a/configure b/configure
index eb51091..7452306 100755
--- a/configure
+++ b/configure
@@ -184,9 +184,6 @@ case $host_os in
SYS="MACOSX"
CFLAGS="$CFLAGS -falign-loops=16"
LDFLAGS="$LDFLAGS -lm -lmx"
- if [ "$pic" = "no" ]; then
- CFLAGS="$CFLAGS -mdynamic-no-pic"
- fi
;;
freebsd*)
SYS="FREEBSD"

e88z4
25th December 2008, 06:12
Thanks! It works.

yuvi
25th December 2008, 07:04
I doubt that you used the latest dev tools; this bug was fixed a while back. Make sure you have XCode 3.1; the ld that shipped with 3.0 has this bug.

Also if you actually care about PIC code in shared libs then enable PIC. But even then I think the 32-bit assembly won't be truly PIC.

Mr VacBob
25th December 2008, 20:43
I don't encourage use of shared libraries, but it will work fine without PIC if your ld is up to date (ld64-85.2.1). There's some normal code structure that requires -Wl,-read_only_relocs,suppress too, but I've forgotten what it was. It doesn't seem to be present in x264.

cacepi
25th December 2008, 21:31
I doubt that you used the latest dev tools.This was tested on XCode 3.1.2, so it still seems to be broken on 32-bit.

I personally didn't see this bug until e88z4 mentioned his problems compiling, as I invariably build 64-bit and it works there. I'm not sure how PPC performs; I no longer have my G4.

Although, I do agree that forcing PIC just to satisfy this one case - i.e. shared library on 32-bit - is overkill. I just guess it means that running '--enable-shared' on 32-bit Darwin should imply '--enable-pic'.

Mr VacBob
25th December 2008, 21:40
Post your config.mak -- it works fine for me under 32-bit.

cacepi
25th December 2008, 21:56
Post your config.mak -- it works fine for me under 32-bit.

Nothing different than what you'd get from a './configure --enable-shared':

prefix=/usr/local
exec_prefix=${prefix}
bindir=${exec_prefix}/bin
libdir=${exec_prefix}/lib
includedir=${prefix}/include
ARCH=X86
SYS=MACOSX
CC=gcc
CFLAGS=-O4 -ffast-math -Wall -I. -falign-loops=16 -mdynamic-no-pic -DHAVE_MMX -DARCH_X86 -DSYS_MACOSX -DHAVE_PTHREAD -s -fomit-frame-pointer
ALTIVECFLAGS=
LDFLAGS= -lm -lmx -lpthread -s
AS=yasm
ASFLAGS=-O2 -f macho -DPREFIX
EXE=
VIS=no
HAVE_GETOPT_LONG=1
DEVNULL=/dev/null
ECHON=printf
CONFIGURE_ARGS= '--enable-shared'
SOSUFFIX=dylib
SONAME=libx264.65.dylib
SOFLAGS=-dynamiclib -Wl,-single_module -Wl,-read_only_relocs,suppress -install_name $(DESTDIR)$(libdir)/$(SONAME)
default: $(SONAME)

Could it be a bad yasm? (yasm --version reports "yasm 0.7.99.HEAD Compiled on Dec 10 2008".)

--Edit: reverting to yasm 0.7.2 allows it to compile, although it still issues a mile of ld warnings as before.

vmrsss
27th December 2008, 13:40
It all works fine for me both 32 and 64bit, macosx 10.5.6, gcc-4.2.1, Xcode 3.1.1

e88z4
27th December 2008, 15:19
I doubt that you used the latest dev tools; this bug was fixed a while back. Make sure you have XCode 3.1; the ld that shipped with 3.0 has this bug.

Also if you actually care about PIC code in shared libs then enable PIC. But even then I think the 32-bit assembly won't be truly PIC.

I didn't have the latest XCode, I was on 3.0. I updated to 3.1.2, everything is fine. It might be the LD bug that causing this problem. It's not yasm either because, I was using the same SVN version from my previous attempt.