John Tytgat wrote:
In message <[EMAIL PROTECTED]>
Lee Noar <[EMAIL PROTECTED]> wrote:
[Snip fix]
Does this seem a reasonable fix?
I'm wondering if we can't go for an easier approach by making sure that
when pthreading is used all the necessary other pthread functions from
UnixLib are being pulled in as well. As this is essentially what you're
doing above.
Something like in libunixlib/pthread/create.c (assuming pthread_create
is an appropriate call to trigger the pullin of the other set of pthreads):
--8<--
void __dummy_pthread_pulling(void)
{
...add here a dummy call to all other pthread routines which are
needed..
}
--8<--
If it works, it will be simplier than what you have but at the expense
that all those pthread routines will be put in static programs, even if
they are not C++ programs. Creating an extra library (libpthread.a) which
needs to get in the linker line feels a bit as overkill.
Yes, OK, that should do the trick. As the gthread implementation tests
for the existence of pthread_cancel to determine if multi-threading,
perhaps that would be the best place to add the dummy function if only
for consistency. I'll run a few tests, and if all is OK, I'll commit the
changes.
Lee.
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
