completely lost building/linking DLLs
Basic problem statement: I've got a piece of software here that's
divided into "low" and "high" DLL halves. Using mingw32, I can
cross-compile both halves, but the high half won't link to the low
one. (The low one is standalone and works fine when I copy it over to a
Windows machine, so I know the toolchain basically works.)
I'm suffering from variable overload--there are just too many things
where I don't know how they are supposed to work, so there are too many
combinations to try. These low/high DLLs are part of a Tcl package,
which is configured using autotools and Tcl's own set of autotool macros
known as "TEA". I can't guarantee these things are doing The Right Thing
wrt either cross-compiling in general or windows DLLs in particular.
This code did originally build on Windows, but we've made modifications
to it (including splitting it into the low/high halves) and there's
basically no support online anymore. It's possible these changes are
preventing an easy Windows build.
Then there's the added fact that I have no idea how DLLs work at a
source level. I spent some time trying to make a sample low/high DLL
pair to eliminate any Tcl/autotools/TEA variables. However, "making
Windows DLLs from scratch via mingw" is already complicated enough that
I'm lost. Is there a tutorial for this?
As for the larger problem: I don't think I even know enough to ask an
intelligent question. Maybe if I just list out some promising facts,
someone will say something that can shed some light.
a) TEA/autotools generates code to look for DLLs, but not with a .dll
extension. It wants to find a .lib. It looks like this is some kind of
manifest or header type thing that can be linked against...?
b) If I explicitly put a reference to low.dll in my link line, I get a
bunch of "undefined reference"s, just like if I have nothing about low
in there at all.
c) I found 'dlltool', which seems promising. I can generate a .lib file
from my dll. (Why doesn't the low.dll Makefile do this already?) But
that doesn't fix the references and 'objdump' doesn't show those names
in there. ('nm' does.)
d) I told 'dlltool' to '--export-all-symbols' and most of my undefined
refs resolved. However, there's at least one junk name in there that
looks like a path name to the lib file itself. Like this:
e) Thinking about why --export-all-symbols wasn't the default, I assume
it's a public/private data thing. So maybe the real issue is that all
the low.dll API has to be exposed somehow?
That's what the package is called in CentOS 6.5. I don't know which
half of the fork this is actually from. I would have though the older
half, but from comments in an earlier thread maybe it's the newer half.
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/