Description of problem:

Any time you try to start a program on ppc64 that is linked to the libjack.so
shared library you'll get a relocation error.
One example for an application linked to libjack.so within the Fedora
distribution is the ARTS sound deamon. This way, the whole KDE sound concept (at
least for KDE 2 and 3) can't roll up on that platform.

Version-Release number of selected component (if applicable):
0.103.0-5.fc8
0.109.2-1.fc9.1

How reproducible:


Steps to Reproduce:
1.Start Fedora Core 8 or Fedora Core 9 on a ppc64 system
2.Install jack-audio-connection-kit and the example clients RPM
3.Start "jack_connect"
  
Actual results:

jack_connect fails with

jackd: error while loading shared libraries: /usr/lib64/libjack.so.0:
R_PPC64_ADDR32 40000056b70 for symbol `' out of range

Expected results:

jack_connect prints out the help message

usage: jack_connect <src_port> <dst_port>
The source port must be an output port of the source client.
The destination port must be an input port of the destination client.

Additional info:

I tracked down the problem to this source files:

config/cpu/powerpc/cycles.h

        __asm__ __volatile__(
                "98:    mftb %0\n"
                "99:\n"
                ".section __ftr_fixup,\"a\"\n"
                "       .long %1\n"
                        ^^^^^
                "       .long 0\n"
                        ^^^^^
                "       .long 98b\n"
                        ^^^^^
                "       .long 99b\n"
                        ^^^^^

Now, this is indeed a problem on 64bit systems because you put pointers into 
32bit variables and that will hardly be relocatable. So, I have looked up the 
spot in the kernel source where I guess you also have this code snippet from. 
I have found this in include/asm-powerpc/reg.h:

#ifdef __powerpc64__
#ifdef CONFIG_PPC_CELL
#define mftb()          ({unsigned long rval;                           \
                        asm volatile(                                   \
                                "90:    mftb %0;\n"                     \
                                "97:    cmpwi %0,0;\n"                  \
                                "       beq- 90b;\n"                    \
                                "99:\n"                                 \
                                ".section __ftr_fixup,\"a\"\n"          \
                                ".align 3\n"                            \
                                "98:\n"                                 \
                                "       .llong %1\n"                    \
                                "       .llong %1\n"                    \
                                "       .llong 97b-98b\n"               \
                                "       .llong 99b-98b\n"               \
                                ".previous"                             \
                        : "=r" (rval) : "i" (CPU_FTR_CELL_TB_BUG)); rval;})
#else
#define mftb()          ({unsigned long rval;   \
                        asm volatile("mftb %0" : "=r" (rval)); rval;})
#endif /* !CONFIG_PPC_CELL */

#else /* __powerpc64__ */

#define mftbl()         ({unsigned long rval;   \
                        asm volatile("mftbl %0" : "=r" (rval)); rval;})
#define mftbu()         ({unsigned long rval;   \
                        asm volatile("mftbu %0" : "=r" (rval)); rval;})
#endif /* !__powerpc64__ */

The "move from time base" instruction seem to be handled differently on a 
ppc64 core on a cell ship than on the "common" ppc64 cores (that must be 
p-series or PowerPC-970). But if I understand your comment in cycles.h right 
you need only the lower half of the time base, so an "mftbl()" would be 
sufficient for your needs (and this one seems at least be the same for the 
two powerpc64 cases).
My suggestion is to introduce one more preprocessor variable in your 
aclocal.m4:

    *64-bit*)
      libsuff=64
      case $host in
        x86_64-*kfreebsd*-gnu)
          LD="${LD-ld} -m elf_x86_64_fbsd"
          ;;
        x86_64-*linux*)
          LD="${LD-ld} -m elf_x86_64"
          ;;
        ppc*-*linux*|powerpc*-*linux*)
          LD="${LD-ld} -m elf64ppc"
          CFLAGS="${CFLAGS} -D__powerpc64__"
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          ;;

And then split up another condition in the cycles.h header:

#ifdef __powerpc64__
        __asm__ __volatile__("mftbl %0" : "=r" (ret));
#else /* __powerpc64__ */
        __asm__ __volatile__(
                "98:    mftb %0\n"
                "99:\n"
                ".section __ftr_fixup,\"a\"\n"
                "       .long %1\n"
                "       .long 0\n"
                "       .long 98b\n"
                "       .long 99b\n"
                ".previous"
                : "=r" (ret) : "i" (CPU_FTR_601));
#endif /* __powerpc64__ */

This should make the libjack.so relocatable on all powerpc systems again.

I have attached a patch I applied on the 0.103.0-5.fc8 and on the
0.109.2-1.fc9.1 RPM to solve the problem successfully.