Hi
Attached patch exhibits different behavior depending on where and how [routeOSC] was built. It seems pre-built binaries from the Debian repositories insert an empty symbol (see attached patch) in the output, but only on amd64 and armhf (Raspberry Pi), but not i386. Also, when I compile routeOSC myself on those platforms (amd64, armhf), the result shows the expected behavior.
routeOSC from Pd-extended works as expected on all platforms.
It looks to me as if the way the external is compiled is responsible for the differences. Among others I'm in charge of the package pd-osc in the Debian repository, but I don't have a clue how to track such a problem. That is why I am asking the list. Any clues?
How likely is it that other externals are not working exactly the same on different platforms? I'm more concerned about 'not exactly' than about 'not at all'.
Roman
On 03/26/2015 09:49 AM, Roman Haefeli wrote:
Hi
Attached patch exhibits different behavior depending on where and how [routeOSC] was built. It seems pre-built binaries from the Debian repositories insert an empty symbol (see attached patch) in the output, but only on amd64 and armhf (Raspberry Pi), but not i386. Also, when I compile routeOSC myself on those platforms (amd64, armhf), the result shows the expected behavior.
routeOSC from Pd-extended works as expected on all platforms.
It looks to me as if the way the external is compiled is responsible for the differences. Among others I'm in charge of the package pd-osc in the Debian repository, but I don't have a clue how to track such a problem. That is why I am asking the list. Any clues?
are you sure? i think that this is a problem of the actually installed versions of pd-osc (maybe you are confusing the current debian package version "0.2-1" with the prior "0.1-2"?)
in any case, i'm running sid/amd64 and get: OUTPUT: 99 EXPECTED: YES
How likely is it that other externals are not working exactly the same on different platforms? I'm more concerned about 'not exactly' than about 'not at all'.
unlikely. or likely, depends on your definition of "not exactly". e.g. some externals will make use of special instructions (think SIMD) when compiled for a given CPU (SSE4 is likely not available on armhf).
fgmard IOhannes
On Thu, 2015-03-26 at 21:57 +0100, IOhannes m zmölnig wrote:
On 03/26/2015 09:49 AM, Roman Haefeli wrote:
Hi
Attached patch exhibits different behavior depending on where and how [routeOSC] was built. It seems pre-built binaries from the Debian repositories insert an empty symbol (see attached patch) in the output, but only on amd64 and armhf (Raspberry Pi), but not i386. Also, when I compile routeOSC myself on those platforms (amd64, armhf), the result shows the expected behavior.
routeOSC from Pd-extended works as expected on all platforms.
It looks to me as if the way the external is compiled is responsible for the differences. Among others I'm in charge of the package pd-osc in the Debian repository, but I don't have a clue how to track such a problem. That is why I am asking the list. Any clues?
are you sure?
No (after checking again)
i think that this is a problem of the actually installed versions of pd-osc (maybe you are confusing the current debian package version "0.2-1" with the prior "0.1-2"?)
Exactly. I tricked myself by launching 'pd' (pointing to /usr/local/bin/pd) instead of '/usr/bin/pd' on a i386 Wheezy machine, and made myself think it must be related to the architecture. Actually, also on the i386 Wheezy machine I get wrong behavior with pd-osc 0.1-2. It is really only a matter of the version pd-osc. As you said.
in any case, i'm running sid/amd64 and get: OUTPUT: 99 EXPECTED: YES
Thanks for testing.
Roman
-
IOhannes m zmölnig -
Roman Haefeli