Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 451531 - Jack doesn't run on ppc64 linux
Summary: Jack doesn't run on ppc64 linux
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: jack-audio-connection-kit
Version: 9
Hardware: powerpc
OS: Linux
low
medium
Target Milestone: ---
Assignee: Andy Shevchenko
QA Contact: Fedora Extras Quality Assurance
URL: http://jackaudio.org
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-15 11:33 UTC by Carsten Jacobi
Modified: 2008-09-10 06:38 UTC (History)
2 users (show)

Fixed In Version: jack-audio-connection-kit-0.109.2-3.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-13 04:32:36 UTC


Attachments (Terms of Use)
Patch for 0.103.0-5.fc8 and 0.109.2-1.fc9.1 source RPMs (deleted)
2008-06-15 11:33 UTC, Carsten Jacobi
no flags Details | Diff

Description Carsten Jacobi 2008-06-15 11:33:07 UTC
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.

Comment 1 Carsten Jacobi 2008-06-15 11:33:07 UTC
Created attachment 309389 [details]
Patch for 0.103.0-5.fc8 and 0.109.2-1.fc9.1 source RPMs

Comment 2 Andy Shevchenko 2008-06-27 19:51:08 UTC
Thanks for detailed description. I havn't PPC/PPC64 architecture, but I'll try 
to update package.

Comment 3 Fedora Update System 2008-07-20 15:52:40 UTC
jack-audio-connection-kit-0.109.2-2.fc9 has been submitted as an update for Fedora 9

Comment 4 Fedora Update System 2008-07-23 07:18:39 UTC
jack-audio-connection-kit-0.109.2-2.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update jack-audio-connection-kit'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-6642

Comment 5 Fedora Update System 2008-07-28 19:30:10 UTC
jack-audio-connection-kit-0.109.2-3.fc9 has been submitted as an update for Fedora 9

Comment 6 Carsten Jacobi 2008-07-31 19:34:45 UTC
I have installed the new rpm and the problem doesn't occur any more.
I regard this issue as being fixed. Due to me, this ticket can be closed!

Comment 7 Fedora Update System 2008-09-05 12:17:29 UTC
jack-audio-connection-kit-0.109.2-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2008-09-10 06:38:27 UTC
jack-audio-connection-kit-0.109.2-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.