building windows build ([Bug 641832] Crash opening MySQL database after installing 2.4.2 over 2.4.0)

[John Ralls]

On Feb 13, 2011, at 12:49 PM, Christian Stimming wrote:

> Am Sonntag, 13. Februar 2011 schrieb John Ralls:
>> BTW, the windows build is absolutely hideous for developing in. `make &&
>> make install` doesn't, which is why I thought yesterday that I hadn't
>> correctly diagnosed the problem when I had. Instead, one has to run
>> make_install.sh, which grinds through a complete autoconf.sh && configure
>> cycle, and because that touches config.h, *everything* has to rebuild,
>> which takes about 45 minutes
> 
> I know, I know. However, the gnucash build requires the PATH to contain some 
> of the bin/ directories which have been created before by install.sh. If your 
> install.sh runs until the end, it displays a nice long message about all the 
> "export ..." variables that you should add to your msys' /etc/profile. I did 
> that on my windows build computer so that PATH contains autotools/bin, 
> gnome/bin, and so on, and because of that "make; make install" indeed does 
> work there. If it doesn't at your computer, it's because your msys' PATH 
> doesn't contain some entries, but once you add them there, all is fine.
> 
>> Can't we move whatever
>> special sauce is in the shell scripts into Makefile.am so that it will
>> work?
> 
> All special sauce is there, except for the PATH, which you must modify 
> yourself.
> 
>> Also, make check fails in the second check because of a problem with
>> future_modules. Obviously, more special sauce is needed in the test code,
>> because Gnucash itself has no problem loading modules.
> 
> Hm... I never tried "make check" on windows, because it would require to set a 
> new PATH in each test sub-directory because different from linux, the (test) 
> executables don't know the locations of the newly compiled libraries (through 
> the ELF rpath), so we would have to fix PATH each time per hand. I quickly 
> gave up on that one at the time, and haven't ever touched that again.
> 

Well, that brings up another question: Why *do* we install into all of those separate directories?

And no, it wasn't a $PATH problem; I've been at this long enough not to get tripped up by that. Make and make install *appear* to run successfully, and the timestamps on the files in inst change like they should... but when I ran under the debugger and got the crash with dbi_conn_queryf in the stack trace it was apparent that it doesn't work. Gdb also warned me that the source file was newer than the executable.

The special sauce seems to be (from make_install() in install_impl.sh):
1436     qpushd $_INSTALL_UDIR/lib 
1437         # Move modules that are compiled without -module to lib/gnucash and 
1438         # correct the 'dlname' in the libtool archives. We do not use these 
1439         # files to dlopen the modules, so actually this is unneeded. 
1440         # Also, in all installed .la files, remove the dependency_libs line 
1441         mv bin/*.dll gnucash/*.dll $_INSTALL_UDIR/bin 2>/dev/null || true 
1442         for A in gnucash/*.la; do 
1443             sed '/dependency_libs/d;s#../bin/##' $A > tmp ; mv tmp $A 
1444         done 
1445         for A in *.la; do 
1446             sed '/dependency_libs/d' $A > tmp ; mv tmp $A 
1447         done 
1448     qpopd

And it isn't the rpath (which is anyway set to the wrong place until after installation), it's libtool that's supposed to find the libraries in the build directories. Thats what libfoo.la is all about.

Oh well. I have enough to do already. I'll leave the M$Win stuff to you.

Regards,
John Ralls