Re: Problem on cygwin linking convenience libraries into a convenience library?
[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 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem on cygwin linking convenience libraries into a convenience library?
Hi Olly, * Olly Betts wrote on Tue, May 16, 2006 at 03:10:04AM CEST: 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...) 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.) 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): 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. I can't see what's failing here. 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? 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 make check (the last gives 3 errors, presumably due to disallowed net access). So, sorry, I need more information to be able to reproduce this. Do you have (maybe only in some cases) duplicate object file names which libtool fails to rename? Cheers, and thanks for the report, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
