Bug 803865 - Jack needs to be compiled with --mixed option so that 32 bit clients can run in a 64 bit install
Jack needs to be compiled with --mixed option so that 32 bit clients can run ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: jack-audio-connection-kit (Show other bugs)
16
x86_64 Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Orcan Ogetbil
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FedoraAudio
  Show dependency treegraph
 
Reported: 2012-03-15 15:15 EDT by Fernando Lopez-Lezcano
Modified: 2012-04-18 18:53 EDT (History)
3 users (show)

See Also:
Fixed In Version: jack-audio-connection-kit-1.9.8-8.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-18 18:53:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch that introduces the --mixed build option into the spec file (2.51 KB, application/octet-stream)
2012-03-15 15:15 EDT, Fernando Lopez-Lezcano
no flags Details

  None (edit)
Description Fernando Lopez-Lezcano 2012-03-15 15:15:08 EDT
Created attachment 570412 [details]
Patch that introduces the --mixed build option into the spec file

Description of problem:
32 bit Jack clients cannot run in a 64 bit install, they die with strange errors (the errors are not relevant, see solution below using an upstream build flag available for this purpose)

Version-Release number of selected component (if applicable):
All

How reproducible:
Always

Steps to Reproduce:
1. start a 32 bit Jack client in a 64 bit installation
2. it does not work on a 64 bit compiled server without the --mixed option
  
Actual results:
32 bit Jack client does not work

Expected results:
Either 32 or 64 bit Jack clients work

Additional info:
There are existing applications which can only be built on the i686 32 bit platform, they are proper Jack clients but they will not work with the existing Fedora builds as they are not built with the "--mixed" build flag. One example is the widely used ChucK computer music language and related applications (miniAudicle, Audicle, Tapestra, etc) - the project does not yet have a proper 64 bit port but it should work as a 32 bit application on a 64 bit install. 

Adding the "--mixed" flag solves the problem. I'm attaching a patch file for my current updated spec file based on the last spec file for Fedora 16. This should be updated on all currently maintained Fedora versions. 

It has been tested in a 64 bit Fedora 16 install with packages built in my Planet CCRMA plague based build environment (the 32 bit dependencies might need to be reworked for Koji). Both the 32 bit and 64 bit packages need to be installed for 32 bit clients to work
Comment 1 Orcan Ogetbil 2012-03-25 02:20:08 EDT
(In reply to comment #0)
> It has been tested in a 64 bit Fedora 16 install with packages built in my
> Planet CCRMA plague based build environment (the 32 bit dependencies might
> need to be reworked for Koji). Both the 32 bit and 64 bit packages need to be
> installed for 32 bit clients to work

I spent some time to build a recent version of ffado together with the requested changes in jack2 this weekend. But as soon as I got to including the "--mixed" mode, I remembered an issue I had before when I was building dssi-vst once upon a time. I am afraid what you ask is not doable with koji. 

When I pass --mixed to the configure script (waf), it automatically adds a -m32 to the compiler flags, and unfortunately the 64 bit compiler does not like this.

The way koji works is different than what you get from the standard yum repos. Koji has its internal repos, and they are designed in a way that the x86_64 builder does not have access to the i686 RPMs. I remember talking to the koji developers about it and they say this is intentional.
Comment 2 Fernando Lopez-Lezcano 2012-03-25 02:32:57 EDT
(In reply to comment #1)
> (In reply to comment #0)
> > It has been tested in a 64 bit Fedora 16 install with packages built in my
> > Planet CCRMA plague based build environment (the 32 bit dependencies might
> > need to be reworked for Koji). Both the 32 bit and 64 bit packages need to be
> > installed for 32 bit clients to work
> 
> I spent some time to build a recent version of ffado together with the
> requested changes in jack2 this weekend. But as soon as I got to including the
> "--mixed" mode, I remembered an issue I had before when I was building dssi-vst
> once upon a time. I am afraid what you ask is not doable with koji. 
> 
> When I pass --mixed to the configure script (waf), it automatically adds a -m32
> to the compiler flags, and unfortunately the 64 bit compiler does not like
> this.
> 
> The way koji works is different than what you get from the standard yum repos.
> Koji has its internal repos, and they are designed in a way that the x86_64
> builder does not have access to the i686 RPMs. I remember talking to the koji
> developers about it and they say this is intentional.

We are really screwed then. 

We would have to analyse how the --mixed flag is handled in the jack2 build system and patch / hack whatever it uses accordingly. I was afraid it would come to that. When compiled with the --mixed flag the build generates both 64 bit and 32 bit libraries. We would need to somehow disable the generation of the 32 bit library (then we don't need the 32 bit dependencies).
Comment 3 Orcan Ogetbil 2012-03-25 15:30:46 EDT
I took another look at the build script and the code. From what I understand, the only thing that the "--mixed" option does, other than compiling 32bit binaries, is enabling the "JACK_32_64" macro (wscript: 215). This macro is used only in defining an attribute (posix/JackCompilerDeps_os.h: 38) in the following context:

        #ifndef POST_PACKED_STRUCTURE
        /* POST_PACKED_STRUCTURE needs to be a macro
        expands into a compiler directive. The directive must  
        tell the compiler to arrange the preceding structure 
        declaration so that it is packed on byte-boundaries rather    
        than use the natural alignment of the processor and/or    
        compiler.
        */
        #if (__GNUC__< 4)  /* Does not seem to work with GCC 3.XX serie */
            #define POST_PACKED_STRUCTURE
        #elif defined(JACK_32_64)
            #define POST_PACKED_STRUCTURE __attribute__((__packed__))
        #else
            #define POST_PACKED_STRUCTURE
        #endif
    #endif

Is this what we really need? Note that the user can always install the 32bit package via
   # yum install jack-audioo-connection-kit.i686
Comment 4 Fernando Lopez-Lezcano 2012-03-25 18:57:59 EDT
(In reply to comment #3)
> I took another look at the build script and the code. From what I understand,
> the only thing that the "--mixed" option does, other than compiling 32bit
> binaries, is enabling the "JACK_32_64" macro (wscript: 215). This macro is used
> only in defining an attribute (posix/JackCompilerDeps_os.h: 38) in the
> following context:
> 
>         #ifndef POST_PACKED_STRUCTURE
>         /* POST_PACKED_STRUCTURE needs to be a macro
>         expands into a compiler directive. The directive must  
>         tell the compiler to arrange the preceding structure 
>         declaration so that it is packed on byte-boundaries rather    
>         than use the natural alignment of the processor and/or    
>         compiler.
>         */
>         #if (__GNUC__< 4)  /* Does not seem to work with GCC 3.XX serie */
>             #define POST_PACKED_STRUCTURE
>         #elif defined(JACK_32_64)
>             #define POST_PACKED_STRUCTURE __attribute__((__packed__))
>         #else
>             #define POST_PACKED_STRUCTURE
>         #endif
>     #endif
> 
> Is this what we really need? 

Thanks for looking at this!! Yes, if that is all it changes it should be as simple as enabling that macro on both the 64 and 32 bit builds. If I find time tomorrow I can try it. 

> Note that the user can always install the 32bit
> package via
>    # yum install jack-audioo-connection-kit.i686

Yes, that is what I did to test and it did work fine.
Comment 5 Fernando Lopez-Lezcano 2012-03-29 14:36:25 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > I took another look at the build script and the code. From what I understand,
> > the only thing that the "--mixed" option does, other than compiling 32bit
> > binaries, is enabling the "JACK_32_64" macro (wscript: 215). This macro is used
> > only in defining an attribute (posix/JackCompilerDeps_os.h: 38) in the
> > following context:
> > 
> >         #ifndef POST_PACKED_STRUCTURE
> >         /* POST_PACKED_STRUCTURE needs to be a macro
> >         expands into a compiler directive. The directive must  
> >         tell the compiler to arrange the preceding structure 
> >         declaration so that it is packed on byte-boundaries rather    
> >         than use the natural alignment of the processor and/or    
> >         compiler.
> >         */
> >         #if (__GNUC__< 4)  /* Does not seem to work with GCC 3.XX serie */
> >             #define POST_PACKED_STRUCTURE
> >         #elif defined(JACK_32_64)
> >             #define POST_PACKED_STRUCTURE __attribute__((__packed__))
> >         #else
> >             #define POST_PACKED_STRUCTURE
> >         #endif
> >     #endif
> > 
> > Is this what we really need? 
> 
> Thanks for looking at this!! Yes, if that is all it changes it should be as
> simple as enabling that macro on both the 64 and 32 bit builds. If I find time
> tomorrow I can try it. 

I just tried it and it works. I patched wscript to always define JACK_32_64, removed the "--mixed" flag and all other cruft from the spec file, rebuilt and tested on x86_64. Installing both the i686 and x86_64 packages enabled 32 bit apps to work correctly (tested with chuck).
Comment 6 Orcan Ogetbil 2012-03-29 19:44:05 EDT
Great. I'll rebuild it with this flag once we know what is going to happen with bug #795094
Comment 7 Orcan Ogetbil 2012-04-07 22:24:42 EDT
Fernando, 
I am about to rebuild the  jack package with this flag, also with jack default priority set to 60, and limits.conf limit for jackuser set to 70. I think this would work for all use cases.

I have one last question. Do we need this -DJACK_32_64 flag on x86_64 only, or in all architectures, i.e. do the 32 bit clients also need this flag? I am not sure what exactly you tested.
Comment 8 Fernando Lopez-Lezcano 2012-04-08 03:15:19 EDT
(In reply to comment #7)
> Fernando, 
> I am about to rebuild the  jack package with this flag, also with jack default
> priority set to 60, and limits.conf limit for jackuser set to 70. I think this
> would work for all use cases.
> 
> I have one last question. Do we need this -DJACK_32_64 flag on x86_64 only, or
> in all architectures, i.e. do the 32 bit clients also need this flag? I am not
> sure what exactly you tested.

In my tests both 32 and 64 bit versions use the flag. I guess that it is so that both architectures see the same alignment in the structures they share. 

Thanks! (we should also look at rtirq and its configuration so that it matches these priority choices). I'll modify my rtirq build accordingly when I have some time.
Comment 9 Fedora Update System 2012-04-08 12:57:29 EDT
jack-audio-connection-kit-1.9.8-7.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/jack-audio-connection-kit-1.9.8-7.fc17
Comment 10 Fedora Update System 2012-04-10 16:17:40 EDT
Package jack-audio-connection-kit-1.9.8-8.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing jack-audio-connection-kit-1.9.8-8.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-5583/jack-audio-connection-kit-1.9.8-8.fc17
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2012-04-18 18:53:27 EDT
jack-audio-connection-kit-1.9.8-8.fc17 has been pushed to the Fedora 17 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.