[L2Ork-dev] Potential Gem bug?

[Ivica Bukvic]

So, I did some digging and it appears there is a seemingly superfluous
implementation of of dlsym inside the newest version of Gem. The RTE.cpp
file already looks for s_stuff.h which contains sys_searchpath in both
vanilla and pd-l2ork and hence, why you would want to look for the same via
dlysm is beyond my comprehension. It is not like the static var
sys_searchpath will change, and if it does, dlsym will fail just as badly
as looking for it in s_stuff.h, requiring the same amount of changes to the
source either way. Further, the code has no checks and balances in terms of
dlsym returning non-null variable which suggests an unsafe implementation,
needless to mention that for Win platform there is a comment, quoting: /*
no idea whether this actually works... */. Now, I do not know enough about
the dlysm to understand what needs to be done with pd-l2ork executable for
it to return the correct address. Apparently, dlsym should take care of
this automagically but for some reason doesn't, and the compile flags
AFAICT are identical. That said, why Gem would want to use dlsym in this
case is beyond me. I have been wrong many times before, yet to me the only
reason for this code's existence is to break compatibility with pd-l2ork,
which, if true, is not a particularly compelling reason for its existence...

Below is a minimal patch to RTE.cpp that would solve this universally,
while making the RTE.cpp method safer. Now, if someone can help me figure
out why the pd-l2ork 1.x branch is stuck on Gem 0.93 when pulling the
module and how to address this, that would be fantastic.

Best,

Ico

--- src/RTE/RTE.cpp 2019-04-25 21:22:06.910252212 -0400
+++ /home/l2orkist/Desktop/RTE.cpp 2019-04-25 21:22:19.910098957 -0400
@@ -201,7 +201,7 @@
       return false;
     }
 #if defined HAVE_S_STUFF_H
-    rte_searchpath = namelist_append((t_namelist*)rte_searchpath,
path.c_str(), 0);
+    rte_searchpath = namelist_append(sys_searchpath, path.c_str(), 0);
 #endif
   }
   return true;

-- 

Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico at vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net



On Thu, Apr 25, 2019 at 11:22 AM Ivica Ico Bukvic <ico at vt.edu> wrote:

>
> On 4/23/2019 10:11 AM, IOhannes m zmoelnig wrote:
>
> On 23.04.19 13:48, Ivica Bukvic wrote:
>
> Thank you, IOhannes. As a point of clarification, this affects pd-l2ork
> (1.x) but not Purr-Data (2.x). Also, Gem is compiled from source and no
> other pd version is installed, so I am unsure why there should be any
> binary incompatibility.
>
> because Gem might make assumptions about the (private) binary layout
> which do not hold true for Pd-l2ork.
>
> The only way this may happen is if Gem ignores the Pd's (and therefore
> Pd-L2Ork's) .h include files and uses its own internal versions instead,
> which would make little sense. Hence, my confusion.
>
> afaict, it is *not* Gem that is crashing, but rather pd-l2ork itself:
> the last call i see is to namelist_append(). so either this procedure
> does not fulfil the expectations of Gem, or the "sys_searchpath" symbol¹
> (which is passed as the first argument to namelist_append()).
>
> I'll gladly look into this. That said, I am surprised to see Gem
> successfully compile if the function in question somehow does not comply
> with the Gem's expectations.
>
> Best,
>
> Ico
>
> gfmdsrt
> IOhannes
>
> ¹ "symbol" as in "variable name" or "function name"; totally unrelated
> to Pd's t_symbol.
>
>
>
> _______________________________________________
> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttps://disis.music.vt.edu/listinfo/l2ork-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20190425/d9d66d52/attachment.html>