This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Unresolved parent class constructors in DLLs
- From: Jason Spence <jspence at lightconsulting dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 22 May 2002 12:20:24 -0700
- Subject: Unresolved parent class constructors in DLLs
Hi -
I'm not on the list, please cc me on any replies.
I'm doing some research to see if GNU Bayonne can be ported to the
cygwin environment. We use a rather complicated setup to load
telephony driver shared objects. The sequence of events is:
1) Someone runs the bayonne executable, which has a global static
pointer named "driver" of type "class driver" which points to NULL.
2) bayonne calls dlopen() on the driver DLL.
3) One of the .cpp files making up the DLL defines a global static
instance of a VPBDriver class. Loading the driver DLL causes an
instance of the VPBDriver class to be created.
4) The VPBDriver class inherits from the Driver class, so it triggers
the Driver::Driver() constructor before we call the
VPBDriver::VPBDriver() constructor.
5) The Driver constructor sets the global static pointer "driver" to
the driver object to this value of the 'this' pointer.
6) Bayonne can now access driver-specific methods through the global
pointer to the Driver object.
So I wrote a simple test case that tries to load a DLL containing a
static instance of a child class that inherits from a parent class
WHICH IS NOT IN THE DLL. This doesn't work like it does on Linux,
causing the linker to bomb out during creation of the shared library
whining about how it couldn't resolve the parent class.
Can you even do stuff like this with PE DLLs?
--
- Jason
Never call a man a fool; borrow from him.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/