[L2Ork-dev] Potential Gem bug?

[Ivica Ico Bukvic]

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 list
> L2Ork-dev at disis.music.vt.edu
> https://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/62f4c617/attachment.html>