> Then it might be fixed when Apple does the next import of the main
> branch of gcc3.3 . Let us wait with those changes until Apple releases
> the next version of the developer tools which will probably be based on
> gcc3.3
Maybe, I've been able to confirm the problem using gcc 3.1 via sourcefor
On Wednesday, May 28, 2003, at 01:08 PM, John Maddock wrote:
The undefind reference comes from posix_api.o . I guess that
s_match_vtable is not used in that file.
You bet it is, you would get the unresolved external if it wasn't
being used
:-)
On MacOS X using g++ version 3.3 in addition to the
> The undefind reference comes from posix_api.o . I guess that
> s_match_vtable is not used in that file.
You bet it is, you would get the unresolved external if it wasn't being used
:-)
> >> On MacOS X using g++ version 3.3 in addition to the linker problem I
> >> had to make all the functions y
> but that just instantiates what I currently need in my code and is no
> real solution.
I agree completely.
> Why do you manually build these vtables and don't use virtual functions?
Because they're dispatched based upon a numeric ID stored in the state
machine.
John.
__
