On Sunday 02 September 2007 10:37:13 Jeff Horwitz wrote: > not surprisingly, it looks like some symbols in libparrot conflict with > exported symbols from other libraries. i ran into this when testing > mod_parrot on an apache server with PHP 5 configured: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1077226080 (LWP 9187)] > 0x4065c4a4 in list_length () from /usr/local/apache2/modules/libphp5.so > (gdb) bt > #0 0x4065c4a4 in list_length () from > /usr/local/apache2/modules/libphp5.so > #1 0x40b7f47a in visit_loop_todo_list (interp=0x825c488, current=0x0, > info=0xbffff4e0) at src/pmc_freeze.c:1426 > #2 0x40b7f781 in run_thaw (interp=0x825c488, image=0x840978c, > what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1554 > #3 0x40b7f9c6 in Parrot_thaw (interp=0x825c488, image=0x840978c) > at src/pmc_freeze.c:1663 > > [snip] > > obviously parrot is looking for src/list.c:list_length, but instead gets > PHP5's list_length, which is already loaded into apache. i'm sure this > problem exists for other functions -- any ideas for how to address this? > we could prepend a Parrot_ prefix for the PARROT_API functions (which > list_length is), but that may not be appropriate for all situations.
I see no reason anything in src/list.c needs PARROT_API. Any objections? -- c
