Brad Garton

I've had several reports now of crashes from people using both [rtcmix~] and IRCAM's FTMlib. I think this could be a problem for other developers, especially anyone who is dynamically-loading their own dylib code library. The specific issue is that [rtcmix~] was built using yacc (bison) to design the parser. When [rtcmix~] calls the parser yyparse() function, it finds the entry for the FTMlib parser instead.

Here's what I think is going wrong: When I updated [rtcmix~], I noticed that the default behavior for Apple's CFBundleLoadExecutable() dynamic loader seems to have changed. In the past, the dylib symbol table was kept 'private', none of the loaded functions were exposed unless I did an explicit CFBundleGetFunctionPointerForName() to find the entry-point. I needed to keep individual instances of [rtcmix~] separate so that the parser/queue/etc. from one instance would not interfere with others. After much experimentation, I found that only by using the mach-o NSLinkModule() system (with options NSLINKMODULE_OPTION_PRIVATE | NSLINKMODULE_OPTION_BINDNOW) was I able to get unique and private loading of the rtcmix.dylib.

Apparently the IRCAM FTM objects don't do this when loading FTMib from the framework. I can't find the source for FTMlib, but 'nm' does show all the range of yyparse() material, and I see from some of the .h files that bison was used in FTMlib.

I could try to go in and rename all of the [rtcmix~] parsing functions, although this will be difficult because bison auto-generates the code. I also suspect that exposing dylib-loaded symbol tables are going to lead to other unwanted namespace conflicts. The ChucK developers have also used bison for their parser, and I have found that [chuck~] + FTMlib will also cause yyparse()-conflict crashes. Plus any inadvertent name conflicts could cause weirdness down the road...

Is there a good solution to this? I'm not a Real Live Programmer, so I may be overlooking something obvious. Any suggestions/advice are welcome!

I've had several reports now of crashes from people using both [rtcmix~] and IRCAM's FTMlib.  I think this could be a problem for other developers, especially anyone who is dynamically-loading their own dylib code library.  The specific issue is that [rtcmix~] was built using yacc (bison) to design the parser.  When [rtcmix~] calls the parser yyparse() function, it finds the entry for the FTMlib parser instead.

Here's what I think is going wrong:  When I updated [rtcmix~], I noticed that the default behavior for Apple's CFBundleLoadExecutable() dynamic loader seems to have changed.  In the past, the dylib symbol table was kept 'private', none of the loaded functions were exposed unless I did an explicit CFBundleGetFunctionPointerForName() to find the entry-point.  I needed to keep individual instances of [rtcmix~] separate so that the parser/queue/etc. from one instance would not interfere with others.  After much experimentation, I found that only by using the mach-o NSLinkModule() system (with options NSLINKMODULE_OPTION_PRIVATE | NSLINKMODULE_OPTION_BINDNOW) was I able to get unique and private loading of the rtcmix.dylib.

Apparently the IRCAM FTM objects don't do this when loading FTMib from the framework.  I can't find the source for FTMlib, but 'nm' does show all the range of yyparse() material, and I see from some of the .h files that bison was used in FTMlib.

I could try to go in and rename all of the [rtcmix~] parsing functions, although this will be difficult because bison auto-generates the code.  I also suspect that exposing dylib-loaded symbol tables are going to lead to other unwanted namespace conflicts.  The ChucK developers have also used bison for their parser, and I have found that [chuck~] + FTMlib will also cause yyparse()-conflict crashes.  Plus any inadvertent name conflicts could cause weirdness down the road...

Is there a good solution to this?  I'm not a Real Live Programmer, so I may be overlooking something obvious.  Any suggestions/advice are welcome!

ftmlib-and-rtcmixchuck-conflict-yyparse

oops, I forgot to say -- I used FTM.2.5.ALPHA.1-Max5 to check on [rtcmix~] and [chuck~], running on a MacBook Intel, Max5.05 (but I think the problem isn't unique to this combo).

FTMlib and rtcmix~/chuck~ conflict: yyparse