[gccsdk] Problems running C++ programs compiled with GCC4
John.Tytgat at aaug.net
Tue Aug 5 12:43:41 PDT 2008
In message <4897534A.8050507 at sky.com>
Lee Noar <leenoar at sky.com> wrote:
> It would seem that weakrefs were added to GCC and GAS to overcome
> the problem we're seeing. See this post for an explanation of weakrefs:
> it specifically mentions libstdc++ and the gthr-* headers. Linux GCC
> correctly pulls in the pthread functions - whether that is because it's
> a separate library in its own right, I don't know.
> I have a solution,
Nice work !
> but I'm not sure whether you'd call it a fix, a
> workaround or a bodge which is why I'll describe it here first before
> committing anything.
> The problem is that several pthread functions are not pulled in by the
> linker because the references to them are weak. I've replaced the empty
> version of libpthread.a with one that contains:
> extern void pthread_once(void);
> extern void pthread_getspecific(void);
> extern void pthread_key_create(void);
> extern void pthread_key_delete(void);
> extern void pthread_setspecific(void);
> static void pthread_dummy(void)
> By then adding:
> -Wl,--whole-archive -lpthread -Wl,--no-whole-archive
> to the link line (which could be done automatically), the weakrefs are
> resolved. Tutris works using this. This is only necessary for static c++
> programs, ironically, dynamically linked code is OK.
> 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
Something like in libunixlib/pthread/create.c (assuming pthread_create
is an appropriate call to trigger the pullin of the other set of pthreads):
...add here a dummy call to all other pthread routines which are
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.
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc