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

[Christian Stimming]

Am Samstag, 18. März 2006 07:26 schrieb Mike Alexander:
> <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. 
> > I've added it to Bugzilla (334951).

If that one linking variable in src/business/business-core/file/Makefile.am 
was the only problem, then it has been fixed in r13663. Comment added to 
bugzilla.

> 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.  

With all due respect, but it is actually *you* who completely misunderstood 
what the last Makefile changes were all about, and it seems to me you didn't 
even have a look at these concrete changes in detail. Otherwise you would 
have probably noticed that the way of library building hasn't been changed at 
all. The only change was that all libraries where symbols are imported from 
are now specified at link time, whereas before, only a subset of these 
libraries have been specified and the rest of the symbols were left 
completely unresolved at link time, which is a contradiction to libtool's 
"-no-unresolved" argument. Again: 

- Before: Lots of imported symbols from libraries; some symbols can be 
resolved explicitly; others are left unresolved
- After: Lots of imported symbols from libraries; for all symbols it is made 
sure that they can be resolved explicitly

> 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.  

You got it right until the very last sentence, which is completely wrong. We 
never did try to make any DLLs self-contained and we will never do so. 
Neither does libtool and friends require that. The only difference is that 
the imported symbols need *all* to be resolvable at link-time (but the DLL 
still won't contain them, only import them), whereas previously it was 
allowed to leave pretty much all of them unresolved until runtime and/or 
until linking an executable, which is why we have lots of test executables 
that should check some of the resolvable symbols (but actually they don't 
check the majority of them).

> 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.  

Now we're getting to the point. Yes, it is probably an architectural problem 
that other modules require symbols from the backend-file module; it is a 
linker problem that they need symbols from a "loadable module" as opposed to 
a library at all. The linker problem can be solved by moving the shared part 
of backend-file from the backend-file module into a new backend-file-library, 
which is what we discussed on IRC already and what will probably be 
implemented in a few days. This will resolve the linker problem that has been 
existing for a long time now; the windows trial with libtools "-no-undefined" 
argument rather revealed it, but it didn't introduce it. 

The architectural question whether libgncmod-business-file should use 
functions from there is a totally different discussion. I'd just remind 
everyone that the very same set of symbols is additionally needed by 
libgncgnome.la, so the symbol importing problem has been existing for even 
longer than the business-file module introduced it a second time.

> I would suggest backing out many of the recent makefile changes 

No. Totally misses the point.

Christian