--On March 17, 2006 10:20:24 PM -0500 David Reiser
<[EMAIL PROTECTED]> wrote:
On Mar 17, 2006, at 12:15 PM, Christian Stimming wrote:
But I have shown that *compiling* on Windows/mingw32 is possible.
So, it is now possible to compile on Windows, but it doesn't run, and
the build is now broken for Macintosh. Maybe I'm biased, but I don't
see this as progress. Mike Alexander raised the issue earlier in the
week, and I've added it to Bugzilla (334951).
Right, it's a problem.
I have several comments on this, actually. Unfortunately you're
probably not going to like them since they may mean more work.
First, there seems to be some idea that it's impossible to resolve an
external symbol in a Windows DLL at load time. Perhaps I'm
misunderstanding what you're saying, but if you're trying to make all
DLLs completely self contained so they have no dependencies on other
DLLs this is neither necessary nor desirable. It takes some header
file magic to make it work, but that's just the price of doing business
on Windows. Not pleasant, but necessary.
I have lots of experience with this in the MSVC environment, but I've
never used the Gnu toolchain to do any significant Windows development
so I was afraid that it might not support this. However it seems to.
A quick Google search found
<http://sourceware.org/autobook/autobook/autobook_251.html#SEC251>
which explains how to do this using libtool and friends. If you follow
the procedures outlined there you won't have to make all the DLLs
completely self-contained. However it will require non-trivial changes
to many of the headers and source files. Again, this is the price of
doing business on Windows.
The second thing I wonder about (which I think Derek has already
mentioned) is why something like libgw-business-core needs a symbol in
file-backend in the first place. This seems to me like it exposes an
architectural problem. The file backend is a plugin that has (or
should have) a well-defined API that outsiders use to call it. If
libgw-business-core is bypassing that API and calling directly to an
entry point in the DLL that seems wrong. What if a different backend
is being used (I realize that there really aren't any others now, but
someday there might be)? Calling into the file backend in that case
seems pretty unlikely to work.
I would suggest backing out many of the recent makefile changes that
try to link everything into every DLL and instead export and import the
necessary symbols in each DLL. This is more work, but it will be much
better in the long run.
I've added this to the bugzilla entry too, but I decided to send it to
the list since there has been a lot of discussion of this already. We
can move the rest to bugzilla if you want.
--
Mike Alexander [EMAIL PROTECTED]
Ann Arbor, MI PGP key ID: BEA343A6
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
