[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problem on cygwin linking convenience libraries into a convenience libra
From: |
Olly Betts |
Subject: |
Problem on cygwin linking convenience libraries into a convenience library? |
Date: |
Tue, 16 May 2006 01:10:04 +0000 (UTC) |
User-agent: |
slrn/0.9.8.1 (Linux) |
I'll apologise up front that this isn't the world's greatest bug report.
Unfortunately I don't have access to a viable cygwin platform for
testing this myself, so I just have end-user reports to go on.
My library currently builds by linking files in each directory into a
convenience library, and then all all these convenience libraries get
linked into the "real" library, along with a dummy C++ source file
so that libtool knows what language to link as.
We've linked this way for a long time, except that there's an extra
sub-sub-directory added comparatively recently.
(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...)
There's one directory which is two levels deep, and here the middle
level builds a convenience library from one C++ source and the
convenience libraries from the subdirectories, like this (LIBADD_*
are set to either "foo/libfoo.la" or nothing depending on which backends
are enabled in configure - by default the first is disabled so there are
4 sub-convenience libraries):
libbackend_la_SOURCES = database.cc
libbackend_la_LIBADD = \
$(LIBADD_MUSCAT36) \
$(LIBADD_QUARTZ) \
$(LIBADD_FLINT) \
$(LIBADD_INMEMORY) \
$(LIBADD_REMOTE) \
multi/libmulti.la
This works fine, except on cygwin it seems. It used to work, but
stopped at some point I can't accurately determine. The first version
where it was reported as a problem was the one where I upgraded from
using libtool 1.5.8 to 1.5.18, which probably means this problem started
between those two versions. Nothing leaps out at me from libtool's NEWS
or Changelog but perhaps a more trained eye would see something.
The problem is missing references when building the "real" library, as
reported here:
http://article.gmane.org/gmane.comp.search.xapian.general/2071
My reply in that thread was wrong - fixing the FIND.EXE problem didn't
fix this.
Oddly, Linux->cygwin cross-compilation seems to work fine (I've not
tested the resulting library and executables but they do link!)
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
There aren't any special dependencies (unless you count a C++ compiler.)
I think I'm probably going to just workaround this problem by simply
linking the sub-subdirectory convenience libraries directly into the
real library which is perhaps a little less clean, but does eliminate
one large convenience library. But I felt I should report the problem
too.
Cheers,
Olly
- Problem on cygwin linking convenience libraries into a convenience library?,
Olly Betts <=