building windows build ([Bug 641832] Crash opening MySQL database after installing 2.4.2 over 2.4.0)
jralls at ceridwen.us
Sun Feb 13 16:17:31 EST 2011
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
> All special sauce is there, except for the PATH, which you must modify
>> 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
1445 for A in *.la; do
1446 sed '/dependency_libs/d' $A > tmp ; mv tmp $A
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.
More information about the gnucash-devel