Re: Problem on cygwin linking convenience libraries into a convenience library?

[Olly Betts]

[Cc:-ing Patrick, who originally hit this problem]

On Tue, May 16, 2006 at 07:58:28AM +0200, Ralf Wildenhues wrote:
> * Olly Betts wrote on Tue, May 16, 2006 at 03:10:04AM CEST:
> >(I'm not totally sold on this approach - all those convenience libraries
> >take up a lot of space, and creating them takes time - it'd be nice to 
> >be able to build the library directly from all the object files, but
> >I've not sussed out a sanely maintainable way to achieve that...)
> 
> Non-recursive Makefiles are a way.  You can structure them by including
> Makefile.am snippets from the subdirectories.  (Be sure to use
> subdir-objects in this case.) 

That sounds promising.  Non-recursive Makefiles also avoid head
scratching when you fail to rebuild everything by accident because
you typed "make" while in a subdirectory.

> >The problem is missing references when building the "real" library, as
> >reported here: 
> >
> >http://article.gmane.org/gmane.comp.search.xapian.general/2071
> 
> There seem to be several issues intermixed here.  Which one is unsolved? 

The "BACKENDS_LA" parts (which is Patrick's report of the problem I
described).

> >If someone with access to a cygwin box wants to try to reproduce this,
> >then building this tarball (with the usual ./configure && make) should
> >do so: 
> >
> >http://oligarchy.co.uk/xapian/0.9.5/xapian-core-0.9.5.tar.gz
> 
> On a current Cygwin, this builds fine for me:
> ../xapian-core-0.9.5/configure -C
> make

Hmm.  Did you try with srcdir == builddir, in case that's a factor?

> make check 
> 
> (the last gives 3 errors, presumably due to disallowed net access).

It doesn't try to access the internet, but does try listening on and
opening connections to 127.0.0.1 (ports 1235 and 1237).  It probably
ought to skip (rather than fail) those test cases if the problem is
network related.  I don't think it's relevant to this issue, but I'd
like to see the errors if it's not just due to firewalling.

> So, sorry, I need more information to be able to reproduce this. 

Hopefully Patrick can help here.  If it builds for you but not for him,
then the issue must be a difference in your build environments.

> Do you have (maybe only in some cases) duplicate object file names
> which libtool fails to rename? 

I don't think so.  I've just checked and there are no duplicate source
files (though there are 2 files called document.h and 2 called
database.h).  The convenience library names are all unique too.

Cheers,
    Olly