On Dec 17, 2012, at 6:05 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-12-17 10:55, IOhannes m zmoelnig wrote:
this makes packaging externals for e.g. Debian a nightmare, as it basically should trigger a .so-name change, but since we are linking against the application instead of an ordinary library, all the tools that would detect such an incompatibility will fail.
this is not only theoretical, but already happened: the Gem" binary as currently packaged in Debian cannot be loaded anymore with the git/master version of puredata.
so please revert the "#define sys_close close" stanzas.
instead i would ask you to provide sys_open() (and friends) implementations in s_path, even for platforms where they are mere wrappers around the system functions.
i created a patch on sourceforge that implements sys_f?(open,close) on all platforms and thus re-establishes binary compatibility.
the new functions are simply wrappers around the system open/close functions. the open wrappers also use sys_bashfilename (like the w32 version), which should be quite a noop on non-w32 platforms for now.
see: https://sourceforge.net/tracker/?group_id=55736&atid=478072
I think this approach works. The patch you provided seems totally untested, as in not even compiled on GNU/Linux or Mac OS X. It includes the _close() function in sys_close() which only works on Win32 and it gives this warning when building on Mac OS X:
s_path.c: In function ‘sys_open’: s_path.c:450: warning: ‘mode_t’ is promoted to ‘int’ when passed through ‘...’ s_path.c:450: warning: (so you should pass ‘int’ not ‘mode_t’ to ‘va_arg’) s_path.c:450: note: if this code is reached, the program will abort
(I attached the patch for reference, it doesn't seem to be up on the patch tracker any more.)
.hc