<div dir="ltr"><div dir="ltr"><div dir="ltr">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...<div><br></div><div>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.</div><div><br></div><div>Best,</div><div><br></div><div>Ico</div><div><br></div><div><div>--- src/RTE/RTE.cpp<span style="white-space:pre"> </span>2019-04-25 21:22:06.910252212 -0400</div><div>+++ /home/l2orkist/Desktop/RTE.cpp<span style="white-space:pre"> </span>2019-04-25 21:22:19.910098957 -0400</div><div>@@ -201,7 +201,7 @@</div><div> return false;</div><div> }</div><div> #if defined HAVE_S_STUFF_H</div><div>- rte_searchpath = namelist_append((t_namelist*)rte_searchpath, path.c_str(), 0);</div><div>+ rte_searchpath = namelist_append(sys_searchpath, path.c_str(), 0);</div><div> #endif</div><div> }</div><div> return true;</div><div><br></div><div>-- <div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><pre cols="72"><pre cols="72">Ivica Ico Bukvic, D.M.A.<br>Director, Creativity + Innovation<br>Institute for Creativity, Arts, and Technology<br><br>Virginia Tech<br>Creative Technologies in Music<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br><br><a href="http://www.icat.vt.edu" target="_blank">www.icat.vt.edu</a><br><a href="http://www.performingarts.vt.edu" target="_blank">www.performingarts.vt.edu</a><br><a href="http://l2ork.icat.vt.edu" target="_blank">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net" target="_blank">ico.bukvic.net</a></pre></pre></div></div></div></div></div></div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 25, 2019 at 11:22 AM Ivica Ico Bukvic <<a href="mailto:ico@vt.edu">ico@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><br>
</p>
<div class="gmail-m_-9063963664210840589moz-cite-prefix">On 4/23/2019 10:11 AM, IOhannes m
zmoelnig wrote:<br>
</div>
<blockquote type="cite">
<pre class="gmail-m_-9063963664210840589moz-quote-pre">On 23.04.19 13:48, Ivica Bukvic wrote:
</pre>
<blockquote type="cite">
<pre class="gmail-m_-9063963664210840589moz-quote-pre">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.
</pre>
</blockquote>
<pre class="gmail-m_-9063963664210840589moz-quote-pre">because Gem might make assumptions about the (private) binary layout
which do not hold true for Pd-l2ork.</pre>
</blockquote>
<p>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.<br>
</p>
<blockquote type="cite">
<pre class="gmail-m_-9063963664210840589moz-quote-pre">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()).</pre>
</blockquote>
<p>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.</p>
<p>Best,</p>
<p>Ico<br>
</p>
<blockquote type="cite">
<pre class="gmail-m_-9063963664210840589moz-quote-pre">gfmdsrt
IOhannes
¹ "symbol" as in "variable name" or "function name"; totally unrelated
to Pd's t_symbol.
</pre>
<br>
<fieldset class="gmail-m_-9063963664210840589mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-9063963664210840589moz-quote-pre">_______________________________________________
L2Ork-dev mailing list
<a class="gmail-m_-9063963664210840589moz-txt-link-abbreviated" href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a>
<a class="gmail-m_-9063963664210840589moz-txt-link-freetext" href="https://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></pre>
</blockquote>
</div>
</blockquote></div>