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
Problem on cygwin linking convenience libraries into a convenience library?
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 ___ 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
Linking convenience libraries
When using the compiler to perform the link and linking against convenience libraries, is there any reason to link explicitly against the extracted objects of the convenience libraries rather than just the .a file? I'm running into a problem on IRIX with the SGI C++ compiler that is solved if I link the .a files. I see no reason why we extract the convenience libraries libraries when linking against the compiler v. the linker. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking convenience libraries
On Thu, 3 Mar 2005, Albert Chin wrote: When using the compiler to perform the link and linking against convenience libraries, is there any reason to link explicitly against the extracted objects of the convenience libraries rather than just the .a file? I'm running into a problem on IRIX with the SGI C++ compiler that is solved if I link the .a files. I see no reason why we extract the convenience libraries libraries when linking against the compiler v. the linker. If we link against the .a file directly then the only objects which will get pulled in are the ones required to link (resolve symbols). This means that much of the library may be missing. If we are building an application it is desirable to shed unnecessary objects but it is not desirable to do that for libraries. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking convenience libraries
On Thu, Mar 03, 2005 at 11:41:00AM -0600, Albert Chin wrote: When using the compiler to perform the link and linking against convenience libraries, is there any reason to link explicitly against the extracted objects of the convenience libraries rather than just the .a file? I'm running into a problem on IRIX with the SGI C++ compiler that is solved if I link the .a files. I see no reason why we extract the convenience libraries libraries when linking against the compiler v. the linker. Ok, my mistakes. $whole_archive_flag_spec works around this. But, only when creating shared objects. Any portability problems with .a files in static archives? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking convenience libraries
On Thu, Mar 03, 2005 at 12:01:26PM -0600, Bob Friesenhahn wrote: On Thu, 3 Mar 2005, Albert Chin wrote: When using the compiler to perform the link and linking against convenience libraries, is there any reason to link explicitly against the extracted objects of the convenience libraries rather than just the .a file? I'm running into a problem on IRIX with the SGI C++ compiler that is solved if I link the .a files. I see no reason why we extract the convenience libraries libraries when linking against the compiler v. the linker. If we link against the .a file directly then the only objects which will get pulled in are the ones required to link (resolve symbols). This means that much of the library may be missing. If we are building an application it is desirable to shed unnecessary objects but it is not desirable to do that for libraries. What if we use $whole_archive_flag_spec? Are the following equivalent on Linux? 1. ld -soname libfoo.so 1.o 2.o 3.o [all .o's from lib1.a] \ [all .o's from lib2.a] 2. ld -soname libfoo.so 1.o 2.o 3.o \ --whole-archive lib1.a lib2.a -no-whole-archive If so, then we should be able to use $whole_archive_flag_spec in lieu of extracting everything. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking convenience libraries
On Thu, Mar 03, 2005 at 09:39:36PM -0600, Albert Chin wrote: On Thu, Mar 03, 2005 at 12:01:26PM -0600, Bob Friesenhahn wrote: On Thu, 3 Mar 2005, Albert Chin wrote: When using the compiler to perform the link and linking against convenience libraries, is there any reason to link explicitly against the extracted objects of the convenience libraries rather than just the .a file? I'm running into a problem on IRIX with the SGI C++ compiler that is solved if I link the .a files. I see no reason why we extract the convenience libraries libraries when linking against the compiler v. the linker. If we link against the .a file directly then the only objects which will get pulled in are the ones required to link (resolve symbols). This means that much of the library may be missing. If we are building an application it is desirable to shed unnecessary objects but it is not desirable to do that for libraries. What if we use $whole_archive_flag_spec? Are the following equivalent on Linux? 1. ld -soname libfoo.so 1.o 2.o 3.o [all .o's from lib1.a] \ [all .o's from lib2.a] 2. ld -soname libfoo.so 1.o 2.o 3.o \ --whole-archive lib1.a lib2.a -no-whole-archive If so, then we should be able to use $whole_archive_flag_spec in lieu of extracting everything. Sorry, this is already used when creating shared libraries. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
