can't build from cvs

[Michael T. Garrison Stuber]

For whatever it's worth, autogen.sh (at least on my Mandrake 8.2 system), 
automatically picks up the system's libtool and nukes the one from CVS. 
Libtool 1.4.2 has some extra magic in it to try and be more intelligent 
about link parameters for interdependent library.  Unfortunately, while 
it's smarter, it doesn't actually work.  When I went to Mandrake 8.2 I had 
to forcibly remove the 1.4.2 libtool and replace it with 1.4.  We either 
need the make scripts fixed to work with 1.4.2, or we need to figure out 
what's wrong with 1.4.2 and let the libtool folks know.

--On Saturday, April 20, 2002 12:11:42 PM -0700 David Hampton 
<hampton@employees.org> wrote:

> On Sat, 2002-04-20 at 01:28, Martin Schulze wrote:
>>
>> I'm afraid I didn't keep the 'Makefile.am's that didn't work for me.
>> The whole affair might be a libtool issue - 'cvs checkout gnucash'
>> delivers version 1.4c of the 'libtool' script - because the order of the
>> entries in LIBADD/LDADD seems to be so important and I don't know whether
>> this should be the case.
>> Do you use a different libtool? I haven't tried another one.
>
> [Copying gnucash-devel.]
>
> I'm using:
>
>   [hampton@hampton-pc hampton]$ libtool --version
>   ltmain.sh (GNU libtool) 1.4 (1.922 2001/04/25 00:05:37)
>
>> At least the second error is quite obvious for me as you really try
>> to compile identical symbols into the same module twice:
>
> Gnucash shouldn't be trying to do this.
>
>> The following code is taken from src/engine/gncmod-engine.c which is
>> compiled into libgncmod-engine.a and exactly the same lines are e.g.
>> in src/backend/file/gncmod-backend-file.c which is compiled into
>> libgncmod-file.a - together with libgncmod-engine.a according to
>> the original src/backend/file/Makefile.am which results in the error:
>
> I don't see where libgncmod-engine.a is compiled into
> libgncmod-backend-file.a.  I see the compile line, but its referencing
> the .la libtool file which should convert to the .so file.
>
>> I wonder - is it intended to build libgncmod-...-.a or should it
>> rather be libgncmod-...-.so?
>
> I just did a 'make clean; make' in my tree and only the following .a
> files were built:
>
> 	libgncmod-test.a
> 	libgncmod-test-engine.a
> 	libgnc-test-file-stuff.a
>
> I think this is your problem.  It would explain why you are seeing
> symbols multiply defined and I don't.
>
>> Do you still want the src-subtree sent? It really is a fresh checkout
>> of the gnucash module from the gnucash-cvs-server (with the
>> 'Makefile.am's now modified).
>
> No.  I think we've isolated the problem.  For some reason your copy of
> libtool is building static libraries instead of shared libraries.
>
> Rerun autogen.sh again and check the output to see if its building
> static or shared libraries.
>
>   checking whether the linker (/usr/bin/ld) supports shared libraries...
>      yes
>   checking how to hardcode library paths into programs... immediate
>   checking whether stripping libraries is possible... yes
>   checking dynamic linker characteristics... GNU/Linux ld.so
>   checking if libtool supports shared libraries... yes
>   checking whether to build shared libraries... yes
>   checking whether to build static libraries... no
>
> You could also try adding the --enable-shared argument to autogen.sh.
>
> I tried using the --disable-shared argument and didn't see your problem,
> but I did see the build system start directly linking in a bunch of .a
> files and I got literally hundreds of errors for undefined symbols.
> (The same 25 or 30 symbols, over and over.)
>
>> Anyway, do you think my patch could make things worse for other people?
>> I will try to compile with a more recent version of libtool on a
>> different machine and keep you informed.
>
> I'm reluctant to apply your patch since I can't recreate your problem
> and there appears to be another explanation.  If we can't resolve this
> problem, I'll apply your patch locally and test it out to see if it
> causes me any problems.
>
> David
>