gnucash on windows: compile possible, running not yet; no further work from me

[Mike Alexander]

--On March 17, 2006 10:20:24 PM -0500 David Reiser 
<dbreiser at earthlink.net> 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           mta at umich.edu
Ann Arbor, MI            PGP key ID: BEA343A6