Bug 803865

(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.

(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).

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

(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.

(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).

Great. I'll rebuild it with this flag once we know what is going to happen with bug #795094

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 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.

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

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).

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.