Re: use $EXEEXT consistently in new testsuite
Hi Roumen, * Roumen Petrov wrote on Wed, Nov 26, 2008 at 12:46:00AM CET: I will check this failure: 28: Runpath in libtool library filesFAILED (runpath-in-lalib.at:59) Please post tests/testsuite.log, so we can see the verbose failure output. You can also run make check-local TESTSUITEFLAGS='-v -d -x 28' for mostly the same information (-x adds tracing output). Interestingly, I don't see this failure on a linux-mingw cross. Maybe you worked from the tree from Sunday? I overlooked one EXEEXT instance in runpath-in-lalib.at there, fixed on Monday. The other not ok test: 21: F77 convenience archives skipped (convenience.at:110) 22: FC convenience archivesskipped (convenience.at:170) 23: Java convenience archives skipped (convenience.at:267) It is time to install those tools :( ;) Well, if you don't have them, don't worry. 29: static linking flags for programs skipped (static.at:177) Yes, I've seen this one as well with a linux-mingw cross. 35: static library contains static library expected failure (archive-in-archive.at:49) 68: build tree relpaths expected failure (deplibs-ident.at:68) These two are known bugs in Libtool. They are not system-specific. 74: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:43) Still no time to look into this one. This is a followup failure of 28 above. The max_cmd_len test reruns some of the previous tests, but with a modified libtool script that simulates a low command line length limit. That way, we can exercise some code paths that deal with many objects so the resulting commands don't fit in one command line. So if 28 fails, this one should fail, too. Don't worry about it until 28 is fixed. Cheers, Ralf
stop libtool from compiling everything twice
Hi, is there a way to stop libtool from compiling everything twice? I am compiling a convenience library, so I add the -static and -prefer-non-pic flag, but it's still compiling my file twice. The command looks like this: libtool --mode=compile g++ -prefer-non-pic -static -g -pipe -c file.cpp the output looks like this: g++ -g -pipe -c file.cpp -o .libs/file.o g++ -g -pipe -c file.cpp -o file.o /dev/null 21 it seems like overkill to compile this file twice, if libtool really needs the .o file in the .libs folder a cp would suffice IMO. OS is Ubuntu 64bits, libtool version is 1.5.26-1ubuntu1 Any thoughts? thanks _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE___ http://lists.gnu.org/mailman/listinfo/libtool
Re: stop libtool from compiling everything twice
On Thu, Nov 27, 2008 at 4:52 PM, herman bastiaens [EMAIL PROTECTED] wrote: is there a way to stop libtool from compiling everything twice? I am compiling a convenience library, so I add the -static and -prefer-non-pic flag, but it's still compiling my file twice. The command looks like this: I usually build everything with --disable-static; that seems to cause libtool to compile files only once. I don't know if this works for convenience libraries specifically, or if they'd still get compiled both ways. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: stop libtool from compiling everything twice
* Bernd Jendrissek wrote on Thu, Nov 27, 2008 at 05:32:08PM CET: On Thu, Nov 27, 2008 at 4:52 PM, herman bastiaens [EMAIL PROTECTED] wrote: is there a way to stop libtool from compiling everything twice? I am compiling a convenience library, so I add the -static and -prefer-non-pic flag, but it's still compiling my file twice. The command looks like this: I usually build everything with --disable-static; that seems to cause libtool to compile files only once. I don't know if this works for convenience libraries specifically, or if they'd still get compiled both ways. Should work for convenience archives just fine, and is a good idea if static linking is not needed. If you need both static and shared elsewhere, you can also try libconv_la_LIBTOOLFLAGS = --tag=disable-static Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
tips for checking changes to library version numbers?
Hello, Does anyone have any good ways to check that updates to -version-info numbers accurately reflect the actual changes in the API of a library when making a new release? Currently I do this by (1) comparing 'nm' output against the old library to find any added/deleted functions (2) manually inspecting a diff of the header files (3) looking at the accumulated NEWS/Changelog entries for possible changes in semantics. I am open to suggestions for reducing human error... thanks. -- Brian Gough GNU Scientific Library - http://www.gnu.org/software/gsl/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Static Library Linking Issue
If I try and link the static libs with LDFLAGS -version-info, rather then static, I get a large amount of undefined reference errors from the shared object file: ../../common/.libs/libcommon_mapi.so.1.0: undefined reference to `PpropFindProp' ../../common/.libs/libcommon_mapi.so.1.0: undefined reference to `HrGetOneProp' ../../common/.libs/libcommon_mapi.so.1.0: undefined reference to `MAPIAllocateBu ffer' ../../common/.libs/libcommon_mapi.so.1.0: undefined reference to `MAPIAdminProfi les' ../../common/.libs/libcommon_mapi.so.1.0: undefined reference to `MAPIAllocateMo re' ../../common/.libs/libcommon_mapi.so.1.0: undefined reference to `HrSetOneProp' collect2: ld returned 1 exit status On Mon, 24 Nov 2008 11:43:39 -0600 (CST), Bob Friesenhahn [EMAIL PROTECTED] wrote: On Mon, 24 Nov 2008, Gavin Norman wrote: I'm trying to link a module library that can be used for dlopen against a static lib. This is the issue I get: Libtool will not allow that since it can't assure that the static library has been built appropriately to do anything more than core dump. However, you can use a libtool convenience library, which is always assured to have been built appropriately for use in a shared library or module. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ -- Gavin Norman M: +614 0935 4020 E: [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: tips for checking changes to library version numbers?
Hi Brian, * Brian Gough wrote on Thu, Nov 27, 2008 at 08:34:45PM CET: Does anyone have any good ways to check that updates to -version-info numbers accurately reflect the actual changes in the API of a library when making a new release? Currently I do this by (1) comparing 'nm' output against the old library to find any added/deleted functions (2) manually inspecting a diff of the header files (3) looking at the accumulated NEWS/Changelog entries for possible changes in semantics. Sounds good. A test suite with good coverage of the API definitely helps, too. If it can do 'installcheck', then you can try running the suite of the old version on the new installed files. If the library has seen only upward compatible changes since, then it should even work to run programs linked against the old library, when linking it to the new one at runtime. Of course this is pretty system-specific to do. Unfortunately, libtool doesn't help much with it. On most GNU/Linux systems, you can try it by setting LD_LIBRARY_PATH appropriately to divert old installed(!) programs to use (elsewhere) installed new libraries. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
error when helptoman is missing
Hey, I just want to mention that, with the newest git (taken 10 minutes ago), when compiling libtool with no help2man available, I get an error: /home/torri/tmp/gitroot/libtool/libltdl/config/missing: line 54: help2man : commande introuvable followed by a warning. Of course, after having installed help2man, there is no problem. Maybe configure should check the availability of help2man and the doc should be built accordingly. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
func_emit_cwrapperexe_src() errors with mingw32ce
Hey, Natively, the Windows CE OS has no concept of environment variable. Hence, when mingw32ce is used, func_emit_cwrapperexe_src() fails because of missing getenv() and putenv() (or setenv() also, of course). I don't know what to do here (removing or not thee calls, as I don't know why they are used. There are also 2 other functions that are missing with that compiler: * getcwd() it's possible to get the path where the current process is launched. Again, i don't know if it's simpler to remove that call or if one should provide a way to have the path where the process is launched. * _spawnv() i don't know any simple way to fake that function. Maybe one should add another test in the 'host' case for that specific compiler which wo do nothing (in that case, one can remove the #ifndef in the case the host is mingw*) Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
