Re: [Adonthell-devel] Re: CMake finalization?

[Kai Sterker]

On 9/30/06, Joël Vennin <address@hidden> wrote:

> > Joel, I don't think we need that __declspec crap, as gcc/ld should be
> > able to figure this out by themselves. I'm no expert though, so I
> > might be wrong.

> I'm not convinced, if you follow the information from
> http://www.belgeler.org/autobook/autobook-DLLs-with-Libtool.html
> you could see that even if you use gcc on mingw/cygwin we should play
> with __delcspec.

Thanks for the link. I'm not sure whether __declspec helps with the
linking, though. From TFL:

"Pointer comparisons do not always work as expected when the pointers
cross a dll boundary, since you can be comparing the addresses of the
stubs in the import library rather than the addresses of the actual
objects in the dll. gcc provides the __declspec extension to alleviate
this problem a little."

So we might need it if we run into problems with that, but I don't
think it helps finding missing symbols. I don't have my windows box
with me (they provided me another box at work, so I no longer bring my
own. Helps me to actually work instead of getting sidetracked with
Adonthell. I still have to get rid of the net though ... ;-)), so I
cannot post the output from the linker I get, but it boils down to the
following when linking libadonthell_event:

undefined reference to symbol cxx_to_py in ...

Note that I could link libadonthell_base and libadonthell_python. And
I am positive that I could link libadonthell_event if I'd explicitly
add libpy_runtime, since it would provide the missing symbol.

Now, in python.h (included from event::listener_py.h) we've got
something like this:

extern "C" {
        PyObject *cxx_to_py (void *instance, const char *name, const bool & 
ownership);
        void py_to_cxx (PyObject *instance, const char *name, void **retval);
}

I tried changing that to something like __declspec(import) instead of
extern "C", but it didn't make a difference. It still wanted
libpy_runtime linked in explicitly. Which is confirmed by external
sources, such as http://edll.sourceforge.net:

"As many people may know, DLLs have one limitation: they can't have
even one undefined symbol. This means at the time you create a DLL,
you must link it against other DLLs in order to get all the undefined
symbols from the object files resolved in some way."

I believe that our code is structured in a way that it has no circular
references between modules, so I guess we could get away by just not
having any undefined references. However, I haven't tested that yet.
The other solution would be to look for workarounds. This edll stuff
would be one, and libltdl has something they call dlpreopening which
might do the trick ...

Anyway, the conclusion is that I need to play around some more and do
some more reading on the subject. If anyone got other helpful links,
I'd appreciate that.

Kai