Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)

PrevNext  Index
DateMon, 07 Jan 2013 14:11:32 +0000
From John Emmas <[hidden] at tiscali dot co dot uk>
ToJACK Mailing List <[hidden] at lists dot jackaudio dot org>
In-Reply-ToStéphane Letz Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
Follow-UpAdrian Knoth Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
On 7 Jan 2013, at 13:37, Stéphane Letz wrote:

>> 
> What do you mean by " a server built, with one compiler to connect" ??
> 
> The point here is for jack clients using the public jack headers and linked with libjack.xxx, so for *clients* possibly yes (so we have this issue with data structure : like jack_position_t or jack_latency_range_t defined in *public* headers).
> 

Yes - in fact there are two mechanisms to consider.  Firstly, the server and its clients use a shared memory block which houses 3 x structs.  JackTransportEngine is one (IIRC) and there are two others.  This situation is only an issue if libjack is built with a different compiler than whatever built the server. For example, it's important in our Mixbus Debug build, where we generally use a version of libjack built using MSVC (because that's the only way we can debug it).

Secondly (like you said) client apps can obtain data from libjack which gets returned using structs.  So it's important that both libjack and the client app agree about the size and layout of those structs.

When we first built Mixbus using MSVC we encountered a problem because although both MSVC and GCC support 8-byte packing, they don't necessarily agree about the layout of an 8-byte packed struct.  MSVC might assume that a certain struct has 18 bytes whereas GCC assumes it has 20 bytes.  That was the reason why we originally needed to introduce 1-byte packing (it was the only arrangement where both compilers agreed about the struct layout).

John
PrevNext  Index

1357567902.20564_0.ltw:2,a <5311C688-59D1-42C5-BC8A-D13F0BF77EB3 at tiscali dot co dot uk>