On Thu, 19 Jun 2003, Joe Kelsey wrote:

> Ok.  I hand-modified the linux-flashplugin6 shared library to remove all
> of the DT_NEEDED entries.  I then modified flashpluginwrapper to add the
> following functions:

[ ... snip wrapper functions ... ]

> I installed this new version of flashpluginwrapper, installed the
> linux-flashplugin6 library in browser_plugins.  Now, the Flash 6 code
> segfaults in pthread_mutex_init(), called from
> Program received signal SIGSEGV, Segmentation fault.
> 0x284549d6 in pthread_mutex_init () from /usr/lib/libc_r.so.4
> (gdb) bt
> #0  0x284549d6 in pthread_mutex_init () from /usr/lib/libc_r.so.4
> #1  0x298016b0 in MPCriticalSection::MPCriticalSection ()
>     from /usr/X11R6/lib/browser_plugins/libflashplayer.so

[ ... snip rest of stack trace ... ]

> Anyone familiar enough with Mozilla internals to understand why
> pthread_mutex_init segfaults?  Has Mozilla started its own threads by
> the time it loads the libraries?  I don't know where to look to track
> this down.  Maybe a difference between Linux and FreeBSD in the pthread
> semantics?

If the flash plugin is making direct calls to pthread functions,
you'll probably have to provide some sort of compatibility wrappers
for those as well, as the pthreads interface make use of lots of
implementation specific data types supplied by the caller.  These
types are not likely to have the same definitions in Linux and FreeBSD.

Check the documentation of all pthread* functions referenced in the
plugin, then find out the definitions of the types of their arguments
from pthread.h on each platform.

For example:

  pthread_mutex_init(pthread_mutex_t *mutex,
                     const pthread_mutexattr_t *attr);

On FreeBSD, pthread_mutex_t and pthread_mutexattr_t are pointers, on
Linux they are structs.

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to