On Wed, 2010-09-29 at 11:58 +0200, IOhannes m zmoelnig wrote: > pd does some (not-so) magic, to find the pd.tk lying next to the pd-gui > binary. > since the pd-gui binary is "/usr/lib/pd/bin/pd-gui" (according to "pd > -verbose") it should find the script as /usr/lib/pd/bin/pd.tk > > attached is the isolated code that does the name-mangling. > to test, compile it with "make pdpath" and then run: > $ ./pdpath /usr/lib/pd/bin/pd-gui" > this should give you something like: > checking './pdpath' -> '.' -> './bin/pd.tk' > checking '/usr/lib/pd/bin/pd-gui' -> '/usr/lib/pd' -> > '/usr/lib/pd/bin/pd.tk'
Bizarro, here it gives this:
p...@chianamo:~/tmp$ gcc -o pdpath pdpath.c
p...@chianamo:~/tmp$ ./pdpath /usr/lib/pd/bin/pd-gui
checking './pdpath' -> '.' -> './bin/pd.tk'
checking '/usr/lib/pd/bin/pd-gui' -> '/usr/lib/pd/bin' ->
'/usr/lib/pd/bin/bin/pd.tk'
Debugging the pdgui_setname function, it looks like the issue is that it
is not using the strncpy function properly, it is assuming that it will
terminate the string properly when it explicitly does not:
Warning: If there is no null byte among the first n bytes of src, the
string placed in dest will not be null-terminated.
The below patch to pdpath.c fixed the issue for me:
--- pdpath.c.orig
+++ pdpath.c
@@ -20,6 +20,7 @@
pdgui_path = malloc(n+9);
strncpy(pdgui_path, str, n);
+ pdgui_path[n] = 0;
while (strlen(pdgui_path) > 0 && pdgui_path[strlen(pdgui_path)-1] == '/')
pdgui_path[strlen(pdgui_path)-1] = 0;
if (t = strrchr(pdgui_path, '/'))
Don't have time right now to test it on pd itself but I'll do that in
the next day or two.
> i fail to see the "interesting" warnings (unless you allude to the
> "xport_dynamic" stuff, which is interesting somehow, but unfortunately
> totally unrelated (this warning only appears when building plugins,
> which you are currently not loading)
Yeah, completely unrelated but very strange errors.
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
