Re: link statically with one library and dynamically with another?
On Sun, 4 May 2008, Jack Bates wrote: How can I link statically with one library and dynamically with another? In an environment you don't personally control, the only way to be absolutely sure is to provide the full path to the static library (e.g. /usr/local/lib/libfoo.a) rather than using -l syntax. That is what libtool itself does under the covers when it intends to link statically. The problem is that virtually all Unix linkers search for shared libraries first and scan the path a second time for static libraries. Libtool itself provides these options: -all-static do not do any dynamic linking at all -static do not do any dynamic linking of uninstalled libtool libraries -static-libtool-libs do not do any dynamic linking of libtool libraries Platform/linker specific options can be passed direct to the linker using -Wl,option type syntax. If you are luckly, libtool will preserve the original location of these options in the command line. Getting options out of order with what they apply to is a common libtool bug. - which did successfully link dynamically with libapr and statically with libtidy, but libtool warned me that referencing .libs/libtidy.a was not portable. You should heed that warning. If your libtidy is not built appropriately for use as a loadable module (e.g. PIC code on platforms which need it), the the linkage may fail. Or the module loading will fail at run time. The program which loads the module may simply core dump. An option you should consider is to build libtidy as a convenience library which can then be safely linked with your module. This approach likely requires that you create your own build environment for libtidy. Bob === Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
LIBLTDL
For GraphicsMagick I need to maintain a GraphicsMagick-config script which contains such things as the list of libraries necessary to link. The conditionally installed libltdl seems to make this difficult to figure out. If enable_ltdl_convenience is 'yes' then it is wrong to list -lltdl as needed but if enable_ltdl_install is 'yes' and enable_ltdl_convenience is 'no, then it appears that -lltdl should be listed as a dependency. In GraphicsMagick things are even more confusing since for a static build, libltdl is not used at all. It is necessary to build this logic out of internal configure variables. A bunch of existing substitutions will need to change in scripts and Makefiles. Ugh! It seems that the GM 1.2 release is a bit botched since I did not take the time to think through the convoluted logic. I suspect that other packages will be bit by this as well. 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: LIBLTDL
On Sat, 3 May 2008, Gary V. Vaughan wrote: Sane options are to link against the installed libltdl if it is good enough (whatever that means) or use a convenience libltdl otherwise. I agree with that. Otherwise people may accidentally interfere with a formally installed libltdl maintained by a package manager. 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: [Patch] cwrapper invokes target directly
On Tue, 29 Apr 2008, Charles Wilson wrote: If I can get some feedback on the '*_with_wine.sh' script I could update the patch to also support $build=some_unixy_platform_with_wine and $host=mingw. I have a MinGW cross-compiler hosted off of FreeBSD 7.0. Presumably I can run Wine on it. I know that Linux has special hooks in order to automatically run Windows executables using Wine. Is the Wine execution support dependent on this Linux feature? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libltdl and cygwin 1.7.0
On Wed, 30 Apr 2008, Eric Blake wrote:
Cygwin 1.7.0 will change the size of MAX_PATH in its headers, but the old
cygwin_conv_to_* API silently suffers from buffer overrun if more than 256
bytes occur in the conversion. As a result, cygwin developers wisely
deprecated the old API when adding the new cygwin_path_conv, and compilation
now issues a warning (which in turn cripples -Werror builds):
libltdl/loaders/loadlibrary.c: In function `vm_open':
libltdl/loaders/loadlibrary.c:147: warning: `cygwin_conv_to_full_win32_path' is
deprecated (declared at /usr/include/sys/cygwin.h:52)
make[2]: *** [libltdl/loaders/loadlibrary.lo] Error 1
OK to apply?
This looks good to apply to me except for the minor nit that the
bracing indentation within the HAVE_DECL_CYGWIN_CONV_PATH is wrong
(and should be corrected).
-#if defined(__CYGWIN__)
+#if HAVE_DECL_CYGWIN_CONV_PATH
+ if (cygwin_conv_path (CCP_POSIX_TO_WIN_A, filename, wpath, MAX_PATH))
+{
+ LT__SETERROR (CANNOT_OPEN);
+ return 0;
+ }
+ len = 0;
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 368] New libtoolize --no-warn option.
On Tue, 29 Apr 2008, Gary V. Vaughan wrote: I hope this will allay Ralf's concerns for users who want to stick with deprecated macro interfaces, and don't want libtoolize to nag them to upgrade. Okay to commit? The immediate concern I have with this approach (--no-warn) is that the main reason for using it is to make use of a package's autogen.sh (or whatever) more pleasing. However, since old libtoolize does not support the option, it is likely to simply quit. As a result, --no-warn can not safely be used if it is possible that some developers are using old libtoolize while others are using modern libtoolize. That makes it almost worthless. This is one rare case where providing the option via an evironment variable is safer. Then the many autogen.sh can set an environment variable to hush the warnings. Did you consider that? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 368 bis] New libtoolize --no-warn option and LIBTOOLIZE_OPTIONS parsing.
On Tue, 29 Apr 2008, Gary V. Vaughan wrote: I hope this will allay Bob's concerns for users who want to stick with deprecated macro interfaces, and don't want libtoolize to nag them to upgrade, even while some stubborn project developers refuse to upgrade to a libtool release that will help them do that. :-p Okay to push? This is definitely better, but there are still a few concerns. The text describing New features lists several libtool options which may be passed via the environment variable, but not this new --no-warn option. The term bailed out may be confusing to people who are not primarily english speakers. It seems best to use terms (e.g. quit) which are straightforward dictionary translations. If you fix these few issues, then the patch seems ok to me. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [Patch] cwrapper invokes target directly
On Tue, 29 Apr 2008, Charles Wilson wrote: Ping? Okay for push? *Any* comments at all? I forgot that you have the ability to do this by yourself. Ralf says that he has been busy and will soon be unavailable for a week or two. Meanwhile, Gary is wanting to cut a new release on (or before) May 3rd. Since we are trying to pop out new libtool releases a lot more often, can we defer your patch until after Gary cuts the forthcoming release? That way the patch has at least a whole month to be inspected and thoroughly tested before the subsequent release. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Libtool performance status (part 1.2965)
On Wed, 23 Apr 2008, Peter O'Gorman wrote: This improvement is almost entirely due to Ralf, so I encourage everyone who is subscribed to this list to seek him out and buy him many beers. Please take care not to buy Ralf too many beers at once since then his productivity may decrease. Spread the beers out over a year or so. 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: libtool performance status
On Tue, 22 Apr 2008, Ralf Wildenhues wrote: To put some sort of proof to my claims, here's what I get building GM unoptimized (CFLAGS=-g) on GNU/Linux with Libtool 2.2.2. and current master (all timings best of three): [ stuff removed ] Looks like a small but definite improvement to me. :-) Good! With libtool 2.2.X I am really not noticing all that much overhead for users to complain about. There is not enough time to make a mad dash to the coffee machine, much less make it back in the time spent by libtool. Many of the functions that libtool does are necessary. Even a total dolt could eventually come to realize this. Note that I have not tested on the XO laptop (http://www.laptop.org/) to know what the actual impact is on children using libtool in disadvantaged countries with pedal or solar power. I know that the FSF does support this project since they had an XO laptop in their booth. Also note that there is only 1.05s of unaccounted-for elapsed time, also Probably just a difference in how the OS performs its accounting. Hmm. That may or may not be libtool's fault, though; linking in itself isn't so cheap, I/O-wise. Can you please check whether libtool --tag=CXX --config is identical for each of the builds you timed? It is really not as easy as you presume for me to relibtoolize GraphicsMagick for testing. I don't maintain many different autotools installs and with 70+ builds simultaneously sharing one source tree such changes become tedious and time consuming. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
On Tue, 22 Apr 2008, Ross Burton wrote: At the moment, GTK+ does this in configure: deplibs_check_method=`(./libtool --config; echo 'eval echo $deplibs_check_method') | sh` if test x$deplibs_check_method '!=' xpass_all || test x$enable_static = xyes ; then ... Am I right in thinking that the first line can be removed, as initialising libtool will have created and set the variable deplibs_check_method? Was this behaviour present in libtool 1.5? I have not checked if this variable is identical for libtool 1.5, but yes, you can access the libtool configuration via existing variables rather than needing to consult an external libtool script. That is how I am doing it. 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: Problems with libtool 2.2.2 and /bin/sh pointing to dash
On Tue, 22 Apr 2008, Ralf Wildenhues wrote: I can successfully configure and use libtool with CONFIG_SHELL=/bin/dash /bin/dash ./configure -C make Same here. The total success was astonishing to me since my copy of 'dash' is a rough port to Solaris 10. Dash is faster than bash so there is advantage to using it. 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: libtool 2.2.2, ccache and -all-static
On Tue, 22 Apr 2008, Richard Purdie wrote: I've noticed another problem with two packages in poky, prelink and libvorbis. Both packages have areas where LDFLAGS=-all-static is used. The problem comes about since Poky sets CC to ccache gcc, then libtool puts the -static flag between ccache and gcc. To reproduce: wget http://www.vorbis.com/files/1.0.1/unix/libvorbis-1.0.1.tar.gz I have (bad) memories of building libvorbis so I double-checked the build I still have laying around (1.2.0) and see that after using AM_PROG_LIBTOOL, its configure.in then has a field-day with overwriting CC, CFLAGS, and other values. That is not how things are supposed to be done. It is little wonder that there are some libtool issues. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool performance status (part 1.2965)
Tonight I did some test timings of building GraphicsMagick 1.2 under Solaris 10. This time around I did a non-parallel build. I tested with the nefarious libtool 1.5.26 as well as various 2.X versions. Most tests used bash by default, but the last test run is with libtool-head and the 'dash' shell. It is clear to see that libtool 2.2 is vastly more efficient than the much maligned 1.5.26. It is also clear that the head version has improved its run times over 2.2.2. It is clear that 'dash' (aptly named) is faster than 'bash' (The World's Slowest Shell (TM)). Obviously time is better spent updating packages to use libtool 2.2.X rather than spinning the wheels adding a 'Dolt' shim layer. Someone should look under the covers and tune up bash as well. The improvement in system times (1:25.275 vs 41.018) is outrageous, and even though compilation is a CPU bound actity, the user times have improved noticeably as well. GraphicsMagick 1.2 build times == configured by /home/bfriesen/src/graphics/GraphicsMagick-head/configure, generated by GNU Autoconf 2.62, with options 'CFLAGS=-g -O2' 'CXXFLAGS=-g -O' '--enable-libtool-verbose' '--with-quantum-depth=16' '--enable-shared' '--with-modules' '--without-fpx' '--without-perl' libtool 1.5.26: real 4:53.877 user 3:26.912 sys 1:25.275 libtool 2.2: real 4:10.695 user 3:20.720 sys45.651 libtool 2.2.2: real 4:10.487 user 3:20.956 sys45.777 libtool 1.2965 2008-04-22 (bash) real 4:03.745 user 3:19.232 sys41.018 libtool 1.2965 2008-04-22 (dash) real 3:43.894 user 3:07.987 sys34.191 == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool performance status
On Mon, 21 Apr 2008, Ralf Wildenhues wrote: If they were lower in between, and since increased, there must have been at least one regression along the way. Can you use git bisect to identify one? Remember that you fixed an expr-related bug which was impacting FreeBSD and causing an error message to be displayed rather than code being executed. Perhaps this fix adds a small cost? Since only 54% of the time is attributed to user+system time the rest of the time must be spent doing things like moving the disk drive heads, waiting for I/O, servicing interrupts, or running other programs (none in this case). Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 363] Allow better compile time type checking for lt_dladvise
On Mon, 21 Apr 2008, Ralf Wildenhues wrote: Does this work with C and C++ compilers? Does it change the ABI or API? If yes, no, then I like it. Otherwise, as nice as it is, it would be a bit inappropriate for a minor release number, no? I use this approach in GraphicsMagick C code without any problems. If it changes the ABI then the existing code must be broken. It could only be seen as an API change if the using application did not use libtool's specified API types (as it should). We would (of course) test with many compilers prior to release. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: FYI - Use AC_CHECK_TOOL for lipo too.
On Mon, 21 Apr 2008, Peter O'Gorman wrote: Hi, I just pushed this. Since the full patch appears on the [EMAIL PROTECTED] list, perhaps it is not necessary to manually duplicate already committed patches on this list? What are the official rules regarding when the patch must be posted to this list as well? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: silencing libtool and automake
On Mon, 21 Apr 2008, Joachim Worringen wrote: We use libtool/automake/configure for our builds, but autotools-builds are pretty verbose, which is not always desired. I checked that by adding the @ silencer in the Makefiles and calling libtool with --silent we get what we want. Using current FSF released software and adding --silent to the libtool options, I obtain complete silence (other than compiler warnings/errors) via 'make -s'. Based on the above, it seems likely that you are not using the current releases of the software. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool performance status
Since libtool performance has become a concern, I have been measuring build times for a reference project in order to evaluate progress. I selected a project at random and ended up with one called 'GraphicsMagick'. I am testing the build on a FreeBSD 7.0 system with two 2.4GHz Intel Xeon CPUs. I am saddened to report that as of yesterday, build times for git libtool are now similar to libtool 2.2.2. This is not to say that there has not been progress. The reported system times have gone down (from 113 to 104) but the overall build times have crept back up so that they are similar to before. This means that users end up waiting just as long for the build to complete. I have attached the raw data, which includes some timings that I did with FreeBSD's /bin/sh and ksh93. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ PATH=/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/X11R6/bin:. /home/bfriesen/src/graphics/GraphicsMagick-head/configure 'CFLAGS=-g -O' 'CXXFLAGS=-g -O' '--enable-libtool-verbose' '--with-quantum-depth=16' --enable-shared '--with-modules' --without-perl Libtool 2.2.2: gmake -j 2 383.14s user 112.49s system 184% cpu 4:28.39 total gmake -j 2 387.55s user 112.91s system 184% cpu 4:31.33 total gmake -j 2 381.21s user 113.93s system 184% cpu 4:27.80 total gmake -j 2 383.57s user 110.94s system 184% cpu 4:28.25 total ltmain.sh (GNU libtool 1.2634 2008/04/11 17:21:54) 2.2.3a gmake -j 2 373.45s user 104.48s system 183% cpu 4:19.99 total gmake -j 2 366.93s user 106.25s system 182% cpu 4:19.03 total gmake -j 2 375.07s user 104.58s system 183% cpu 4:21.72 total gmake -j 2 373.90s user 104.60s system 183% cpu 4:20.25 total Using CONFIG_SHELL=/bin/sh gmake -j 2 345.53s user 82.93s system 180% cpu 3:56.79 total gmake -j 2 356.35s user 84.13s system 179% cpu 4:05.26 total Using CONFIG_SHELL=/usr/local/bin/ksh93 gmake -j 2 350.80s user 88.18s system 178% cpu 4:05.52 total gmake -j 2 349.59s user 87.31s system 179% cpu 4:03.20 total ltmain.sh (GNU libtool 1.2960 2008-04-19) 2.2.3a gmake -j 2 381.18s user 102.72s system 184% cpu 4:22.74 total gmake -j 2 381.66s user 103.63s system 182% cpu 4:25.81 total gmake -j 2 383.43s user 104.83s system 182% cpu 4:27.74 total gmake -j 2 384.38s user 104.25s system 182% cpu 4:27.78 total
Re: [PATCH 363] Allow better compile time type checking for lt_dladvise
On Sun, 20 Apr 2008, Gary V. Vaughan wrote: * libltdl/lt__private.h (lt__handle, lt__advise): Typedefs removed in favour of... * libltdl/ltdl.h (lt_dlhandle), libltdl/libltdl/lt_dlloader.h (lt_dladvise): ...changing from void* to forward declarations. * libltdl/loaders/dlopen.c, libltdl/loaders/loadlibrary.c, libltdl/lt_dlloader.c, libltdl/ltdl.c: Remove many redundant type casts. * NEWS: Updated. Suggested by Bob Friesenhahn [EMAIL PROTECTED] I like this very much. Besides helping user code, it should diminish the number of compiler warnings when compiling libltdl and may even avoid some optimization-related bugs. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 363] Allow better compile time type checking for lt_dladvise
On Sun, 20 Apr 2008, Gary V. Vaughan wrote: I like this very much. Besides helping user code, it should diminish the number of compiler warnings when compiling libltdl and may even avoid some optimization-related bugs. Is that a review with an implicit please apply? Or are you just cheering me on from the sidelines :-) I reviewed the code updates and liked them very much. Probably I was communicating in American when I should have been communicating in British. Here are my comments translated to British: please apply. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [PATCH 364] Capture lt~obsolete.m4 serial number correctly in libtoolize.
On Sun, 20 Apr 2008, Gary V. Vaughan wrote: * libltdl/m4/lt~obsolete.m4: Add the filename to the #serial marker so that libtoolize's serial number checks can find it in a non-include using aclocal.m4. * NEWS: Updated. Reported by Olly Betts [EMAIL PROTECTED] Olly's recent posts reveal several bugs, each of which I'll address with a separate patch. Okay to apply? This bug has annoyed me as well. Please apply this patch. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: func_arith and func_len
On Sat, 19 Apr 2008, Ralf Wildenhues wrote: Let's reuse at_func_arith from Autotest, to redo one of the link mode speedups that fell under the cracks a couple of years ago. IIRC somebody else suggested this recently, but I don't remember who. Please speak up so I can put your name in the ChangeLog entry. Roland Mainz [EMAIL PROTECTED] (OpenSolaris/Ksh93 guy) is the suitable party to blame. Note that for pre-Posix shells, the number of forks doubles in those loops (but the quadratic counting is not present there either); for practical cases that will lead to a slow-down with those shells. OK to apply? For these kind of dramatic improvements, I think that the users should be paying a much higher fee. I propose that the fee be increased to 35% more than they are paying today. I do not see anything wrong with the patch. Please apply it. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: expr complaint on FreeBSD for MinGW cross
On Sat, 19 Apr 2008, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Sat, Apr 19, 2008 at 01:56:59AM CEST: Ouch. ETOOLATE. Of course $name is used, in libname_spec for example. Please ignore this, I'll post an updated patch. OK to apply? While I have not tested this patch, it looks ok to apply to me. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: func_arith and func_len
On Sun, 20 Apr 2008, Ralf Wildenhues wrote: Sorry, but: first, there is no floating point in either Libtool, nor Posix shell semantics. Second, if you can prove to me (by posting timing comparisons) that conversion from integer to string or vice versa, has *any* performance impact whatsoever on Libtool, I'll gladly send lots of beer your way. I mean hey, we still fork quite a bit, and While for our purposes it is indeed unlikely that we can measure the difference, it seems that the code should use the most correct implementation if using it requires minimal effort. If all shells supporting this math syntax also support the native math types (which they likely do since this syntax comes from old ksh), then is there a reason why we would not prefer the native syntax for math if we are doing math? Is there a ripple effect? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Feature request: setting env vars for binary wrappers
On Fri, 18 Apr 2008, Roumen Petrov wrote: Because I think that modules/application/packages/etc should do their best work. I don't think that a particular package hast o support partially or to implement very basic functionality. The est example is microsoft software where application is feature reach but 99.9% of features are with partially or basic functionality. The difference between libtool and Microsoft software is that libtool is developed by volunteers and Microsoft software is developed by well-paid employees of a many billion-dollar company. As a result, every feature in libtool is developed because someone wants it badly enough that they are willing to develop it themselves. Libtool is not over-featured at this time. As Ralf says, we are already passing environment variables to the wrapper so it is no big deal to pass more. The only substantial change is for static builds which currently don't have a wrapper. The static build is a more significant concern since static builds are often used for debugging purposes and if we hide the static binary in a subdirectory, it may be more difficult to debug. We need to make sure that it is both possible to obtain the necessary run-time environment, and to run the debugger on the correct binary. Proposals for the cleanest way to do that are appreciated. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Feature request: setting env vars for binary wrappers
On Fri, 18 Apr 2008, Ralf Wildenhues wrote: We need to make sure that it is both possible to obtain the necessary run-time environment, and to run the debugger on the correct binary. Proposals for the cleanest way to do that are appreciated. Well, did this cease to work (except for the bug which was fixed in 2.2.2)? ./libtool --mode=execute gdb ./prog --args ... I assume that it works. Of course it does not work with some IDE-based debuggers. It can be made to work with programs like 'ddd' and 'emacs' which talk to a traditional debugger over a pseudo-tty or pipe. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Feature request: setting env vars for binary wrappers
On Thu, 17 Apr 2008, Behdad Esfahbod wrote:
If running uninstalled build is not a goal, why bother about
LD_LIBRARY_PATH'ing the uninstalled library path at all?
I feel your pain. As a workaround, for my own software I add a small
script which exports environment variables prior to running each test.
This is an extra shim layer that should not have to exist. The script
(attached) has substitutions applied to it prior to use. In the
future, I might include similar replicated code in each test script so
that the tests are completely stand-alone and run a bit faster.
An unfortunate thing is that not all software is configured the same.
For example, my own software supports independent configuration for
the location of different types of files. A single top prefix
environment variable would not directly work with my application while
it might work for others. A single top prefix would require that the
application know the structure of the build tree, which is likely a
bad thing since it may not match the install tree.
It seems to me that the proper place to fix this is at the Automake
level since Automake's weak support for tests is the true cause of the
problem.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
# !/bin/sh
# Copyright (C) 2003, 2004 GraphicsMagick Group
#
# This program is covered by multiple licenses, which are described in
# Copyright.txt. You should have received a copy of Copyright.txt with this
# package; otherwise see http://www.graphicsmagick.org/www/Copyright.html.
#
# Execute a program with the environment required to execute it using
# files from the source and build directory. This helps avoid needing to
# install GraphicsMagick before testing it.
#
# Written by Bob Friesenhahn [EMAIL PROTECTED] December 2003
#
top_srcdir='@abs_top_srcdir@'
top_builddir='@abs_top_builddir@'
MAGICK_CODER_MODULE_PATH='@MAGICK_CODER_MODULE_PATH@'
MAGICK_CONFIGURE_SRC_PATH='@MAGICK_CONFIGURE_SRC_PATH@'
MAGICK_CONFIGURE_BUILD_PATH='@MAGICK_CONFIGURE_BUILD_PATH@'
MAGICK_FILTER_MODULE_PATH='@MAGICK_FILTER_MODULE_PATH@'
DIRSEP='@DIRSEP@'
PATH=${top_builddir}/utilities:${PATH}
if test -n $VERBOSE
then
echo $@
fi
env \
LD_LIBRARY_PATH=${top_builddir}/magick/.libs:${LD_LIBRARY_PATH} \
MAGICK_CODER_MODULE_PATH=${MAGICK_CODER_MODULE_PATH} \
MAGICK_CONFIGURE_PATH=${MAGICK_CONFIGURE_BUILD_PATH}${DIRSEP}${MAGICK_CONFIGURE_SRC_PATH}
\
MAGICK_FILTER_MODULE_PATH=${MAGICK_FILTER_MODULE_PATH} \
PATH=${PATH} \
$@
Re: Allow bootstrap from git repository
If we need an increasing serial number, can't we obtain one from git? Does git offer the ability to update an RCS-style string in a text file each time it is modified? If that is the case, then we would just need to arrange to modify that file each time there is a commit to git. Of course since git uses distributed repositories, this might become tricky. We don't want to force someone to have to use git to do a 'make dist' but since git is necessary in order to submit changes, it is reasonable to make full use of it at that time. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Allow bootstrap from git repository
On Tue, 15 Apr 2008, Ralf Wildenhues wrote: bootstrapping without having git available. If you're now OK with needing git for bootstrapping, then we can go similar to Autoconf. No, that is not ok for me. :-) I had a different idea but now I realize that it was unworkable. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
libtool performance and shells
Since it has been claimed that libtool causes a lot of build overhead, I have been doing a *lot* of testing here with latest development libtool. We already know that libtool 1.5.X is very slow so it is not worth worrying about that and it is more worthwhile to get projects migrated to libtool 2.2.X since it is much faster. Peter O'Gorman came up with a simple useless code parsing benchmark which showed that GNU bash could be the Worlds Slowest Shell (TM) except for a Korn shell clone called 'pdksh' which never completed at all. Other tests also pointed out that bash seemed to be a bit sluggish. DTrace shows that bash spends an awful lot of time in memset() as compared with the other shells. Simple shell benchmarks seemed to indicate that shells derived from the Almquist shell (http://en.wikipedia.org/wiki/Almquist_Shell) were the fastest and smallest. Ksh93 was almost as quick. Bash was slowest at simple contrived benchmarks. However, there is an old saying The proof is in the pudding. I have run overall timings of configure and full builds using various shells on different systems and found that on average, bash was not significantly slower at running the configure script. I also found that bash was not significantly slower for an overall libtool-based build. Bash is never the fastest, but when it is slower there is not a significant impact to overall build time. There are some systems where there is some benefit to using a shell other than bash, but the difference does not seem large enough for Autoconf and libtool to be concerned enough to use a different shell selection algorithm. 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: No need for object file removal before compilation
On Sat, 12 Apr 2008, Ralf Wildenhues wrote:
Then, while I have some doubts about the practical applicability of
Bob's scenario, I left the code so that it would be supported: all
Bob's scenarios are rarely practical.
I would have been inclined to ok this one.
OK for the updated one? It makes for 5% faster
libtool --mode=compile gcc -c a.c
The patch looks ok to me. We shall see about the actual performance
improvement.
Bob
Thanks,
Ralf
2008-04-12 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh (func_mode_compile): Avoid
redundant removal of old output files before compilation.
Do not remove $obj until we have successfully grabbed the
lockfile (in case the compiler doesn't grok `-c -o'), because
it might be identical to $output_obj.
At the end of the function, before we remove the lockfile,
update $removelist so that if the trap hits after the lockfile
has been removed, we do not accidentally remove $output_obj that
does not belong to us.
(func_write_libtool_object): Use $MV instead of mv.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.106
diff -u -r1.106 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 11 Apr 2008 17:21:55 - 1.106
+++ libltdl/config/ltmain.m4sh 12 Apr 2008 06:55:46 -
@@ -650,7 +650,7 @@
non_pic_object=$write_oldobj
EOF
- mv -f ${write_libobj}T ${write_libobj}
+ $MV ${write_libobj}T ${write_libobj}
}
}
@@ -831,9 +831,6 @@
removelist=$lobj $libobj ${libobj}T
fi
-$opt_dry_run || $RM $removelist
-trap $opt_dry_run || $RM $removelist; exit $EXIT_FAILURE 1 2 15
-
# On Cygwin there's no real PIC flag so we must build both object types
case $host_os in
cygwin* | mingw* | pw32* | os2*)
@@ -850,8 +847,6 @@
if test $compiler_c_o = no; then
output_obj=`$ECHO X$srcfile | $Xsed -e 's%^.*/%%' -e
's%\.[^.]*$%%'`.${objext}
lockfile=$output_obj.lock
- removelist=$removelist $output_obj $lockfile
- trap $opt_dry_run || $RM $removelist; exit $EXIT_FAILURE 1 2 15
else
output_obj=
need_locks=no
@@ -881,17 +876,20 @@
$opt_dry_run || $RM $removelist
exit $EXIT_FAILURE
fi
+ removelist=$removelist $output_obj
$ECHO $srcfile $lockfile
fi
+$opt_dry_run || $RM $removelist
+removelist=$removelist $lockfile
+trap '$opt_dry_run || $RM $removelist; exit $EXIT_FAILURE' 1 2 15
+
if test -n $fix_srcfile_path; then
eval srcfile=\$fix_srcfile_path\
fi
func_quote_for_eval $srcfile
qsrcfile=$func_quote_for_eval_result
-$opt_dry_run || $RM $libobj ${libobj}T
-
# Only build a PIC object if we are building libtool libraries.
if test $build_libtool_libs = yes; then
# Without this assignment, base_compile gets emptied.
@@ -911,8 +909,6 @@
command=$command -o $lobj
fi
- $opt_dry_run || $RM $lobj $output_obj
-
func_show_eval_locale $command\
'test -n $output_obj $RM $removelist; exit $EXIT_FAILURE'
@@ -962,7 +958,6 @@
# Suppress compiler output if we already did a PIC compilation.
command=$command$suppress_output
- $opt_dry_run || $RM $obj $output_obj
func_show_eval_locale $command \
'$opt_dry_run || $RM $removelist; exit $EXIT_FAILURE'
@@ -998,6 +993,7 @@
# Unlock the critical section if it was locked
if test $need_locks != no; then
+ removelist=$lockfile
$RM $lockfile
fi
}
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: support of the cegcc compiler
On Sat, 12 Apr 2008, Vincent Torri wrote: 2) With those patches, libtool can now create dll's with cegcc. But I have that message when it tries to create the dll of my lib: *** Warning: linker path does not have real file for library -lws2. etc... saying it can not create the shared lib of my lib because the shared version of libws2 does not exist. Usually, there are 2 things to do: Generally it is demanded that any built DLLs only depend on DLLs (for obvious reasons such as duplicate symbols and intermixing of code types) but in the past there have been certain exceptions. For example, in the MinGW build, the C++ standard library did not support throwing exceptions out of a DLL so it was built as static. In that case libstdc++ was treated as a special case. At least that is how I remember it. 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: move func_mode_compile a little earlier
On Thu, 10 Apr 2008, Ralf Wildenhues wrote: Why don't you move all except func_mode_help further down until before func_mode_link? install and execute mode also deserve to be fast. OK with that change, and if you've checked that an eventual nonworking './libtool --mode=foo --help' would have been caught by our test suite. I definitely agree that link and install modes need to be fast. Apparent libtool slowness becomes very evident for a GraphicsMagick modules build where some 90 or so modules are built and need to be installed. Of course it is quite likely that this apparent libtool slowness should actually be attributed to linker slowness. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half
On Wed, 9 Apr 2008, Ross Burton wrote: I realise this isn't libtool 2.2, so I'm willing to believe there are further speedups. What I notice from your timings is that libtool 2.1 takes much less system time than libtool 1.5.26-3 but the user time is quite similar. The real time is surely most important, and it seems that the real time is improved with libtool 2.1 but not very dramatically. The mystery as to where the time is actually going is why I have suggested several times that there should be an effort to test libtool under a DTrace-enhanced shell (shell with a DTrace provider) and perform an analysis of what is being done and where time is being spent using dtrace. Even without a DTrace-enhanced shell, it is possible to see where time is going in a script using DTrace. A DTrace-enhanced shell is going into OpenSolaris. See http://blogs.sun.com/tpenta/entry/psarc_2008_008_dtrace_provider;. Quite often when I profile a program I find that something quite unexpected is hogging the time and the fix is quite trivial. Perhaps we will find this with libtool as well. For those of you who feel offended that I suggest using a tool which is only currently available under Solaris and OS-X Leopard, I find it to be no more insulting than a suggestion to run software under valgrind, which is only available under Linux (and sometimes on FreeBSD). 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: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half
On Wed, 9 Apr 2008, Josh Triplett wrote: I tested against 1.5.26. I'll give 2.2.2 a shot and see what I find. However, when I looked at 2.2.2, it still seems to have a multi-thousand-line shell script; do you just expect the benefit to come from the new shell-specific optimizations? Since shell scripts are not compiled, the size of a shell script has very little to do with its execution time. 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: supportof the cegcc compiler
On Wed, 9 Apr 2008, Vincent Torri wrote: It seems that most of this patch is just adding cegcc* to existing case statements. Do you think that the patch looks good ? I'm porting more and more libs, and creating the dll by hand is quite bothering. So i'm planning to works a bit on how to support cegcc in libtool. The problem is that, for me, libtool is some kind of black voodoo magic. So i don't know if it is reasonnable or not (i didn't write that patch) Not knowing anything in particular about 'cegcc', I don't have any philosophical or technical issues with the patch except that it should be submitted by its author so we know who wrote it and that they intended it to be contributed to GNU libtool. It is also useful to have a volunteer who is willing to test libtool to make sure that it works (and continues to work) for this target. I suggest that you find out who wrote this patch and convince them to submit it as an official libtool patch against libtool 2.X. 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: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half
On Wed, 9 Apr 2008, Eric Blake wrote: | Since shell scripts are not compiled, the size of a shell script has | very little to do with its execution time. On the other hand, recent improvements in autoconf 2.62 proved that we were able to speed up testsuite performance by more than 10% by merely refactoring Autotest output to avoid shell parsing of code that would not be executed. In other words, the time the shell spends on parsing its input, whether or not that input is executed, is not trivial. This is true. The script could be 10MB in size but if only the first five lines are ever executed the execution time should be similar to a similar five line script. This means that parts which are executed often should be up front. If there is a long list of shell functions which appear up front, then all those shell functions need to be parsed and remembered before the real executable code is executed. There may be value to extracting these shell functions into separate files which are sourced only when needed. This way the overhead of parsing linking code is not encountered while compiling, and vice-versa. Since there is surely overhead associated with opening and sourcing a file the chunk of code should be pretty large. Unfortunately, more files gives people more to complain about since a single large file is less offensive than many smaller files. If the build-time overhead associated with libtool 2.2 (vs Dolt) is really only 13% or so, someone needs to make the call as to what is an acceptable level of runtime overhead before Dolt can be disposed of an unecessary idea. Is the acceptable overhead 5%, 7%, 10%? What is the magic number? 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: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half
On Wed, 9 Apr 2008, Peter O'Gorman wrote:
(using bash)
$ for y in {1..100}; do echo func_notused${y} () { parse.sh; for x
in {1..1}; do echo foo parse.sh; done; echo '}' parse.sh;
done; echo 'echo Done' parse.sh
It seems that the slowest possible shell is selected by default.
Maybe that is bad?
On Solaris 10 (Opteron)
% ptime bash parse.sh
Done
real3.247
user2.923
sys 0.322
% ptime zsh parse.sh
Done
real0.991
user0.877
sys 0.112
% ptime ksh parse.sh
Done
real1.063
user0.922
sys 0.141
On Solaris 10 (SPARC)
% ptime bash parse.sh
Done
real 10.417
user 10.128
sys 0.283
% ptime zsh parse.sh
Done
real3.045
user2.817
sys 0.227
% ptime ksh parse.sh
Done
real3.432
user3.255
sys 0.175
On FreeBSD 7.0 (Intel Xeon)
% time bash parse.sh
Done
bash parse.sh 5.63s user 0.18s system 99% cpu 5.808 total
% time zsh parse.sh
Done
zsh parse.sh 2.02s user 0.36s system 99% cpu 2.379 total
On Mac OS-X Leopard (G5)
% time bash parse.sh
Done
bash parse.sh 4.46s user 0.41s system 99% cpu 4.891 total
% time zsh parse.sh
Done
zsh parse.sh 1.35s user 0.39s system 83% cpu 2.074 total
% time ksh parse.sh
[ runs forever apparently ]
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half
On Wed, 9 Apr 2008, Peter O'Gorman wrote: This is a list off shell functions that appear in the generated libtool script on my linux system (one of Ralf's patches is applied). Yes, we could probably move these around some to get func_mode_compile closer to the top. The important thing is not how close func_mode_compile() is to the top, but how close the code which invokes it is to the top. 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: Customizing soname
On Fri, 28 Mar 2008, Alon Bar-Lev wrote: I think that infrastructures such as libtool should allow customization of any attribute that affect the output. Of course there should be defaults but it should allow overriding to allow customization. This especially true when the customization is simple to implement and to maintain. Since libtool is portability software, each requested feature needs to be evaluated based on its impact to portability and its usefulness on many platforms. Your request is the first I can recall for supporting the ability to customize soname. 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: Fix disable-static -all-static (was: testsuite: 24 25 64 failed)
On Mon, 24 Mar 2008, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Mon, Mar 24, 2008 at 12:56:56PM CET: I'll address 25 separately (confirmed with --disable-static, BTW). Proposed, slightly ugly patch. Can you try it please, and do you have a name and email address to put in the ChangeLog and THANKS? Thus, OK to apply? Note that our manual explicitly allows to use -static even with --disable-static (which I am not sure whether it works everywhere, but the static.at test should expose that when libtool is configured that way), so the situation isn't quite clear-cut. This patch looks good to apply to me. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: libtool C++ link bug with -lm functions with Sun Workshop compiler
On Fri, 21 Mar 2008, Tim Mooney wrote: What version of Sun C++ are you using? The C++ from Workshop 12 with patches applied: $CC -V CC: Sun C++ 5.9 SunOS_i386 Patch 124864-01 2007/07/25 % CC -V CC: Sun C++ 5.9 SunOS_i386 Patch 124864-02 2007/12/18 To answer Bob's previous question, I generally upgrade any project I'm building to use libtool 1.5.latest, so right now I'm using 1.5.26. Maybe you should be trying 2.2 since support for the Solaris compiler has been redone so that linking is via the C++ compiler for C++ code. In spite of a few known bugs (many fixed now), the 2.2 version is much better than preceding versions due to its exhaustive test suite and quite a few years more development. 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: libtool C++ link bug with -lm functions with Sun Workshop compiler
On Thu, 20 Mar 2008, Tim Mooney wrote: Perhaps it is not best to run most of your configure script using the C++ compiler. Only run the C++ compiler to test C++ things. I don't disagree, but at the same time, if everything a project is going to build is going to be compiled by the C++ compiler, doesn't it make sense for the C++ compiler to actually do the tests? If it's the C++ Good point. However, it may be that some autoconf tests intended for C don't work properly when used with the C++ compiler. compiler that needs to see the prototype for sqrt(), and it's the C++ compiler that's going to initiate the link, it doesn't make a lot of sense for the tests to be conducted by the C compiler. That's hardly a good test; there are several reasons why what the C compiler can see for prototypes or test link might differ from what the C++ compiler would. There are projects out there, beyond GNU aspell, that are using the C++ compiler for many of the configure tests. Are they all wrong to do so? I don't recall if you mentioned the libtool version you are using. Libtool 2.2 usually uses the C++ compiler to link C++ programs and libraries. I just re-verified that it does do so for Solaris 10 with the Studio 12 compiler. Upgrading to 2.2, or the first subsequent release (scheduled for April 1st) may be the solution you are looking for. 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: libtool C++ link bug with -lm functions with Sun Workshop compiler
On Wed, 19 Mar 2008, Tim Mooney wrote: That means that doing something like AC_INIT(lttest, 0.60.5) AC_CONFIG_SRCDIR(configure.ac) AC_PROG_CXX AC_LANG([C++]) AC_CHECK_FUNCS(sqrt) AC_OUTPUT will always detect sqrt(), because the C++ compiler added `-lm -lc' behind the scenes. Then it seems like you did something wrong and libtool is not to blame. Perhaps it is not best to run most of your configure script using the C++ compiler. Only run the C++ compiler to test C++ things. I use LT_LANG([C++]) to tell libtool that I need support for C++. Then I do C++ related testing like this AC_LANG_PUSH(C++) some C++ tests AC_LANG_POP This works great under Solaris! 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: supportof the cegcc compiler
On Fri, 14 Mar 2008, Vincent Torri wrote: I would like to know when libtool supports the cegcc compiler. Right now, libtool refuses to build shared libraries with that compiler. Also, there are libtool patches for that compiler that were written more than 1 year ago (google with libtool + cegcc), and I've seen that libtool 2.2 (released 2 weeks ago) does not mention cegcc at all. Which is a bit strange, imho. When did you submit your patch to the libtool-patches list? I am not finding it. Support does not spring into libtool from the mailing list for other tools. It needs to be contributed according to FSF rules. 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: supportof the cegcc compiler
On Fri, 14 Mar 2008, Vincent Torri wrote: it's not my patch but here is what I've found: http://lists.pld-linux.org/mailman/pipermail/pld-cvs-commit/Week-of-Mon-20070226/144657.html and it's not in the libtool patch list. Should all patches be sent there ? It seems that most of this patch is just adding cegcc* to existing case statements. Due to FSF rules, patches should be submitted by the author Patches should be mailed to the libtool-patches list for review. If the patch is not a trivial one, then a contract needs to be signed with the FSF to assign the copyright for the work to the FSF. The current libtool release is 2.2 so the current release needs to be updated as well. We expect an update release for 2.2 in a couple of weeks, but there is currently no forecast for another 1.5.X release. 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: supportof the cegcc compiler
On Fri, 14 Mar 2008, Vincent Torri wrote: I would like to know when libtool supports the cegcc compiler. Right now, libtool refuses to build shared libraries with that compiler. Also, there are Vincent, In order to reasonably support this target, we need a volunteer who will faithfully test libtool on that target and work to resolve issues. Are you able to find a volunteer to support the cegcc compiler? It seems that the cegcc compiler must work almost the same as the MinGW compiler. I think that the main issue will be that libtool has a very sophisticated test suite which may currently depend on some features which are not in Windows CE. The test suite would need to be adapted to work reasonably well for this target. Even now, there are still some test failures with the MinGW compiler. 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: supportof the cegcc compiler
On Fri, 14 Mar 2008, Vincent Torri wrote: is there a web page that describes what to do, exactly ? See http://savannah.gnu.org/projects/libtool. You would want to check the code out from CVS HEAD. I am not sure if MSYS can bootstrap libtool so you might need to use Cygwin to do that. Latest versions of autoconf, automake, and m4 are required in order to bootstrap. Executing the bootstrap script is likely to take a *long* time. Test with 'configure', 'make', and 'make check'. As I'm using mingw, i can test it too :) Good! 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: git mirror of Libtool CVS repo
On Thu, 13 Mar 2008, Eric Blake wrote:
For starters, you can't bootstrap the git repo. Note these lines in
configure:
TIMESTAMP=`${CONFIG_SHELL} ${ac_aux_dir}/mkstamp ${srcdir}/ChangeLog`
package_revision=`( set $TIMESTAMP; echo $1; )`
In GraphicsMagick I do it like this:
TIMESTAMP=`awk '/^[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]/ { print
substr($1,1,4) substr($1,6,2) substr($1,9,2); exit; }'
${srcdir}/ChangeLog`
Since we should always update ChangeLog, it makes sense to use the
last date entered in ChangeLog.
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: Libtool head test status
On Sat, 8 Mar 2008, Ralf Wildenhues wrote: Now, in that test, the toplevel configure script chooses $top_srcdir/INSTALL (yes, the text file) as install script. I suspect this is because you have /uhome/src/gnu/libtool-head in the $PATH, the beginning of testsuite.log reveals that. Why is that, did you add that manually? Something in 'make check' must be putting it there since it is certainly not anything I did. Perhaps automake does this in order to find its scripts? It would be much safer to invoke any subordinate scripts using full paths. Unfortunately, Windows does not observe case. As evaluated by 'ls -l' in msys, the INSTALL file has permissions -rw-r--r-- so it should not be accidentally executed. However, if I pass /uhome/src/gnu/libtool-head/INSTALL to msys on the command line, it is indeed executed. The same happens with Cygwin. Perhaps since the execute bits are quite unreliable under Windows, any file is deemed executable. This is the path setting in the shell that invoked the tests: Bob [EMAIL PROTECTED] ~/mingw/libtool-head $ echo $PATH .:/usr/local/bin:/activestate/bin:/mingw/bin:/bin:/c/program files/graphicsmagick-1.1.11-q16:/c/Program Files/Microsoft DirectX SDK (June 2007)/Utilities/Bin/x86:/c/Perl/bin/:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/Microsoft SQL Server/80/Tools/Binn/:/c/Program Files/Rational/common:/c/Program Files/QuickTime/QTSystem/:/c/Qt/4.1.4/bin:/c/bin:/c/Adabas/bin:/c/Adabas/pgm:/c/Program Files/OpenVPN/bin Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Libtool head test status
On Sat, 8 Mar 2008, Ralf Wildenhues wrote: Now, in that test, the toplevel configure script chooses $top_srcdir/INSTALL (yes, the text file) as install script. I suspect this is because you have /uhome/src/gnu/libtool-head in the $PATH, the beginning of testsuite.log reveals that. Why is that, did you add that manually? It seems that our build environment is extending the path. Both msys and cygwin are happy to execute INSTALL as a shell script if passed to it like a command. Something is clearly doing a case-insensitive search of the PATH to find 'install' and is then using what it found. This is interesting: MINGW = Bob [EMAIL PROTECTED] ~ $ export PATH=/uhome/src/gnu/libtool-head:$PATH Bob [EMAIL PROTECTED] ~ $ which install install is /bin/install Bob [EMAIL PROTECTED] ~ $ which INSTALL INSTALL is /bin/INSTALL Bob [EMAIL PROTECTED] ~ $ INSTALL INSTALL: too few arguments Try `INSTALL --help' for more information. Bob [EMAIL PROTECTED] ~ $ echo $SHELL /bin/sh Cygwin == velma:~% which install /usr/bin/install velma:~% export PATH=/uhome/src/gnu/libtool-head:$PATH velma:~% which install /usr/bin/install velma:~% rehash velma:~% which install /usr/bin/install velma:~% install install: missing file operand Try `install --help' for more information. velma:~% INSTALL /uhome/src/gnu/libtool-head/INSTALL: line 1: Installation: command not found ./#.emacs#: line 2: syntax error near unexpected token `;;' ./#.emacs#: line 2: ` ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!' /uhome/src/gnu/libtool-head/INSTALL: line 4: syntax error near unexpected token `C' /uhome/src/gnu/libtool-head/INSTALL: line 4: `Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,' velma:~% echo $SHELL /bin/zsh velma:~% bash bash-3.2$ which install install is /usr/bin/install bash-3.2$ echo $PATH /uhome/src/gnu/libtool-head:/activestate/bin:/usr/local/bin:/usr/X11R6/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:. bash-3.2$ export SHELL=/bin/bash bash-3.2$ which install install is /usr/bin/install bash-3.2$ which INSTALL INSTALL is /usr/bin/INSTALL bash-3.2$ INSTALL INSTALL: missing file operand Try `INSTALL --help' for more information. == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
On Sat, 8 Mar 2008, Edward Hervey wrote: Hi, I'd like to give my feedback on these 7 patches (applied against trunk svn). Thanks for the useful feedback. This is good news. Awesome work ! I don't know what more is needed to push these patches in, if you need more feedback, logs, etc... please ask. The current plan is to address remaining issues found in the 2.2 release before any new functionality is added. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
On Fri, 7 Mar 2008, Ralf Wildenhues wrote: Because we generally use the same archive_cmds for F77, FC as for CXX, No we don't. archive_cmds _is_ tagged. In a casual test, it worked just fine for me to mix gcc and g++ with Solaris 10 f77 and f90. You may recall that mixing tools was not working for me under Solaris 10 so I have fortran variables (F77 FC) set to 'no' in config.site so that they won't be used in the libtool tests. At the time I thought that perhaps this was due to a lacking libtool feature rather than a 'bug'. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Ralf Wildenhues wrote: Then, let's avoid us getting blame for broken gcj installations. OK to apply this patch to avoid the gcj test when a compile would fail? Or do you feel tests for working compilers should be done in configure already? My feeling is that the sooner a fundamental problem with a compiler is found, the better, so it makes sense to adequately sanity-check all compilers that libtool is configured for in the configure script. If the compiler does not pass a basic sanity check, then libtool should not support the associated language tag. If the package specifies that it needs that language, then configure should quit with an error. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Peter O'Gorman wrote: I think the test for a working GCJ should be in libtool, and unset GCJ, avoid adding the tag etc.if it is found to be nonfunctional. We would have to issue a warning during configure or something. Does not look to be quite as easy as this patch though, if you want to apply this one as a stop-gap measure, that is fine. If libtool is integrated into a package and the package declares that it needs a Java compiler, then failure to pass basic tests should cause configure to quit with an error (similar to the way configure fails if the C compiler does not work). If libtool is built stand-alone (as in our distribution) then there should be a warning but the user should still be able to build and install libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Peter O'Gorman wrote: What would be ideal is to check that the compiler exists, is executable, works (an possibly, when not cross-compiling, test that trivial code that is compiled with the compiler runs) but not cause an error if the compiler is broken or does not exist, simply warn the user that a broken compiler was detected and set the same vars in the same way as would be set if no compiler was detected. I agree with most of this (ammended for cross-compile) except that it is wrong to assume that users watch configure output while it runs. Most people seem to use that time to get a cup of coffee (or another Canadian beer). There needs to be a way to output any warnings at the tail end of configure so that at least someone is more likely to see them. Without adequate notification to the user, the user is likely to try 'make' and then find that libtool does not work. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Ralf Wildenhues wrote: That's not a workable solution. The normal configure output and config.log were invented to do what Bob wants. Libtool cannot in general know what is important for the package, IMVHO. So if the functioning of a compiler is important, then configure should simply fail if the compiler does not work. I tend to agree with this, but the author of the package needs a way to know that libtool has failed to sufficiently configure and have a way to notify the user. Right now there is no documented way to know if libtool encountered problems during configuration. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
On Thu, 6 Mar 2008, Peter O'Gorman wrote: Libtool detected FC as f90, but otherwise used the gcc tools. I'll look into this. Because we generally use the same archive_cmds for F77, FC as for CXX, things can get a little messed up. This fixes the most common case, gcc, g++, g77/gfortran some other fortran compiler, by pretending the other fortran compiler does not exist. This seems ok for now but it does seem that the inability to mix compilers which would otherwise interoperate should be put on the list of future libtool issues to solve for the next big release. It seems perfectly reasonable to use a non-GNU fortran or C++ compiler along with GCC. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Ralf Wildenhues wrote: Then, let's avoid us getting blame for broken gcj installations. OK to apply this patch to avoid the gcj test when a compile would fail? Or do you feel tests for working compilers should be done in configure already? My feeling is that the sooner a fundamental problem with a compiler is found, the better, so it makes sense to adequately sanity-check all compilers that libtool is configured for in the configure script. If the compiler does not pass a basic sanity check, then libtool should not support the associated language tag. If the package specifies that it needs that language, then configure should quit with an error. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Peter O'Gorman wrote: I think the test for a working GCJ should be in libtool, and unset GCJ, avoid adding the tag etc.if it is found to be nonfunctional. We would have to issue a warning during configure or something. Does not look to be quite as easy as this patch though, if you want to apply this one as a stop-gap measure, that is fine. If libtool is integrated into a package and the package declares that it needs a Java compiler, then failure to pass basic tests should cause configure to quit with an error (similar to the way configure fails if the C compiler does not work). If libtool is built stand-alone (as in our distribution) then there should be a warning but the user should still be able to build and install libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Ralf Wildenhues wrote: But that should not be Libtool's decision, but the package's. Libtool already supports a syntax by which the package can specify the languages that it wants to configure for. I agree that this may not be expected to cause hard-failure if a language is found to not work. So it seems that we need a way to specify both the languages to try to configure for, and the ones that must work. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Peter O'Gorman wrote: What would be ideal is to check that the compiler exists, is executable, works (an possibly, when not cross-compiling, test that trivial code that is compiled with the compiler runs) but not cause an error if the compiler is broken or does not exist, simply warn the user that a broken compiler was detected and set the same vars in the same way as would be set if no compiler was detected. I agree with most of this (ammended for cross-compile) except that it is wrong to assume that users watch configure output while it runs. Most people seem to use that time to get a cup of coffee (or another Canadian beer). There needs to be a way to output any warnings at the tail end of configure so that at least someone is more likely to see them. Without adequate notification to the user, the user is likely to try 'make' and then find that libtool does not work. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [libtool 2.2] testsuite: 18 19 64 failed [Solaris 7 SPARC]
On Thu, 6 Mar 2008, Peter O'Gorman wrote: Libtool detected FC as f90, but otherwise used the gcc tools. I'll look into this. Because we generally use the same archive_cmds for F77, FC as for CXX, things can get a little messed up. This fixes the most common case, gcc, g++, g77/gfortran some other fortran compiler, by pretending the other fortran compiler does not exist. This seems ok for now but it does seem that the inability to mix compilers which would otherwise interoperate should be put on the list of future libtool issues to solve for the next big release. It seems perfectly reasonable to use a non-GNU fortran or C++ compiler along with GCC. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Wed, 5 Mar 2008, Peter O'Gorman wrote: Your gcj and automake are broken. Do you have a sane toolchain on any of your systems? We should also keep in mind that autoconf apparently only checks the C compiler to verify that it is sane. There don't seem to be any good sanity checks for the C++, Java, or Fortran compilers. If the program is available we try to use it in the tests. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Wed, 5 Mar 2008, Peter O'Gorman wrote: You are right, of course, it was too harsh. I was simply overwhelmed when I looked at the volume of mail on the bug-libtool list. You have no reason to be overwelmed. Just divide the volume of mail regarding 2.X by the four years it took to produce it. Then it seems fairly trivial. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 19 35 36 44 45 46 48 49 50 51 52 53 60 61 62 64 failed [GNU/Linux PowerPC]
On Thu, 6 Mar 2008, Ralf Wildenhues wrote: That sounds a little harsh. I think that the LZMA complaint from automake may be because libtool requests a lzma package and it requires the very latest automake to do so. Where does Libtool 2.2 require lzma? That would be a serious bug, requiring such a recent Automake. I was not able to find where libtool 'requests' a lzma package but I do see that all of the Makefile.in files in the distribution include a target for it (dist-lzma). The reported error message seems quite strange, particularly since LZMA is in caps. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: git? branch-2-2?
On Tue, 4 Mar 2008, Ralf Wildenhues wrote: As far as cramping Gary's style goes, Gary (only used as an example here) is prone to making large changes, and these changes may soon render 'master' useless as a good source of patches for stable branches. Ah, no, this problem is easily avoided. git cherry-pick allows you to pick individual patches from one branch into another. My point is that as the master version advances in time, the baseline for submitted patches will become more and more different. Eventually a patch from the master version can not reasonably be applied against a stable branch. One reason why I have not contributed all that much to libtool sources is that the level of effort to produce an emailable patch for peer approval on this list substantially raises the bar for contribution. While the patch is waiting to be approved, the local changes sit uncommitted in a working directory, hindering further work on the same files. Each developer needed to develop his own system for working around this limitation. I never did. It seems that git has much more to offer to meet these needs than CVS does. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: git? branch-2-2?
On Tue, 4 Mar 2008, Gary V. Vaughan wrote: My point is that as the master version advances in time, the baseline for submitted patches will become more and more different. Eventually a patch from the master version can not reasonably be applied against a stable branch. That's no different to the effort involved in porting fixes on branch-1-5 forward to HEAD in CVS. Exactly. This was not an easy chore even though CVS could give you a nice diff. If major libtool releases can occur much more often, then there should be less pain from maintaining branches. Incidentally, I suppose we should set about defining a sensible set of goals for Libtool 2.4 reasonably soon... I'll raise that again when 2.2.2 is done. The only two big things I can think of are o Better Windows support (for non-GNU compilers). o Multi-lib/multi-arch support (including building the libs). We have contributed patches for some of this already. I would be happy if 2.4 popped out with just the Windows part since multi-lib/multi-arch may be a big project and requires more consensus. It would also be nice if autoconf and libtool could work with a DTrace-fortified shell (http://blogs.sun.com/tpenta/entry/psarc_2008_008_dtrace_provider) so that we can do some really good performance profiling on it and make it faster. There is likely some low-lying fruit that we are not aware of. I'm looking forward to your patches now :-D My motiviations toward libtool are mostly selfish in that libtool is vital to other software I develop and maintain. When libtool becomes a blocker, then my motiviation level becomes high. :-) The 2.2 release is the first libtool release which satisfies all of my requirements (except for non-GNU Windows) in the last eleven years. In other words, it is the first libtool release that I feel comfortable with not using a development version in my released software. That is quite an achievement. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Libtool head test status
On Sun, 2 Mar 2008, Bob Friesenhahn wrote: Both are attached in lzma compressed format. I find it odd that the log file is much larger for MinGW/MSYS than for Cygwin. It seems that part of the reason for the bloat is that Makefiles don't make good shell scripts. :-) I see that in some cases the Makefile is being executed by the shell implying that a MAKE command expansion/substitution is not working. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: FYI: 355-gary-2-2-prerelease-updates.patch
On Sat, 1 Mar 2008, Gary V. Vaughan wrote: I promise. And more than 4 years ahead of schedule (check the diff against NEWS below if you don't believe me). -New in 2.1c: 2012-??-??; CVS version 2.1c, Libtool team: +New in 2.2: 2008-03-01; CVS version 2.1c, Libtool team: It seems to me that this release must surely have been rushed since it is so far ahead of schedule. Features must have been secretly removed. Please put back the features which were removed in order to meet the accelerated schedule. :-) Yahoo! Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Uh, oh, libtool does not build any more
With very latest CVS updates from Gary I am seeing this failure on my various host types: gmake all-recursive gmake[1]: Entering directory `/scratch/bfriesen/build/libtool-head' gmake[2]: Entering directory `/scratch/bfriesen/build/libtool-head' test -f doc/.dirstamp || gmake doc/.dirstamp gmake[3]: Entering directory `/scratch/bfriesen/build/libtool-head' gmake[3]: `/home/bfriesen/src/gnu/libtool-head/doc/.dirstamp' is up to date. gmake[3]: Leaving directory `/scratch/bfriesen/build/libtool-head' depbase=`echo libltdl/argz.lo | sed 's|[^/]*$|.deps/|;s|\.lo$||'`;\ /bin/bash ./libtool --tag=CC --mode=compile gcc-4.2.1 -DHAVE_CONFIG_H -I. -I/home/bfriesen/src/gnu/libtool-head -DLT_CONFIG_H='config.h' -DLTDL -I. -I/home/bfriesen/src/gnu/libtool-head -Ilibltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl/libltdl -O2 -MT libltdl/argz.lo -MD -MP -MF $depbase.Tpo -c -o libltdl/argz.lo /home/bfriesen/src/gnu/libtool-head/libltdl/argz.c \ mv -f $depbase.Tpo $depbase.Plo libtool: compile: gcc-4.2.1 -DHAVE_CONFIG_H -I. -I/home/bfriesen/src/gnu/libtool-head -DLT_CONFIG_H=config.h -DLTDL -I. -I/home/bfriesen/src/gnu/libtool-head -Ilibltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl/libltdl -O2 -MT libltdl/argz.lo -MD -MP -MF libltdl/.deps/argz.Tpo -c /home/bfriesen/src/gnu/libtool-head/libltdl/argz.c -fPIC -DPIC -o libltdl/.libs/argz.o libtool: compile: gcc-4.2.1 -DHAVE_CONFIG_H -I. -I/home/bfriesen/src/gnu/libtool-head -DLT_CONFIG_H=config.h -DLTDL -I. -I/home/bfriesen/src/gnu/libtool-head -Ilibltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl -I/home/bfriesen/src/gnu/libtool-head/libltdl/libltdl -O2 -MT libltdl/argz.lo -MD -MP -MF libltdl/.deps/argz.Tpo -c /home/bfriesen/src/gnu/libtool-head/libltdl/argz.c -o libltdl/argz.o /dev/null 21 /bin/bash ./libtool --tag=CC --mode=link gcc-4.2.1 -O2 -no-undefined -version-info 8:0:1 -dlpreopen libltdl/dlopen.la -L/usr/local/lib -R/usr/local/lib -o libltdl/libltdl.la -rpath /usr/local/lib libltdl/loaders/libltdl_libltdl_la-preopen.lo libltdl/libltdl_libltdl_la-lt__alloc.lo libltdl/libltdl_libltdl_la-lt_dlloader.lo libltdl/libltdl_libltdl_la-lt_error.lo libltdl/libltdl_libltdl_la-ltdl.lo libltdl/libltdl_libltdl_la-slist.lo libltdl/argz.lo libtool: link: `libltdl/loaders/libltdl_libltdl_la-preopen.lo' is not a valid libtool object gmake[2]: *** [libltdl/libltdl.la] Error 1 gmake[2]: Leaving directory `/scratch/bfriesen/build/libtool-head' == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Uh, oh, libtool does not build any more
On Fri, 29 Feb 2008, Gary V. Vaughan wrote: Thanks for the report. I'll hold the release until we figure out what's broken, however I can't reproduce that error on my Mac (where I have no fortran or java compilers): These are the tools I am using on the machine that did the bootstrap: autoconf (GNU Autoconf) 2.61 automake (GNU automake) 1.10.1 m4 (GNU M4) 1.4.10 GNU sed version 3.02 (old, I know, but somehow better) expr (GNU coreutils) 6.9 GNU Awk 3.1.5 gcc (GCC) 4.2.1 Builds are done outside of the source tree. Building under OS-X fails the same. All targets fail the same. What happens with a fresh checkout on your machine? Not sure. I will find out later. I am happy to provide you with an account on my machines if it will help you with this issue, or in the future. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Uh, oh, libtool does not build any more
On Fri, 29 Feb 2008, Bob Friesenhahn wrote: What happens with a fresh checkout on your machine? Not sure. I will find out later. That did it! Perhaps there is something not quite right in the maintainer dependencies or a timestamp was wrong. Testing builds now ... Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Uh, oh, libtool does not build any more
In a recursive diff between the broken CVS directory and the working one, I see this difference: Common subdirectories: libtool-head-old/libltdl/CVS and libtool-head/libltdl/CVS diff -r libtool-head-old/libltdl/Makefile.in libtool-head/libltdl/Makefile.in 47,48c47,48 config/install-sh config/ltmain.sh config/mdate-sh \ config/missing config/texinfo.tex lt__dirent.c lt__strl.c --- config/install-sh config/ltmain.sh \ config/missing lt__dirent.c lt__strl.c The difference does not seem to explain the strange substitution I was seeing. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Libtool head test status
These are results of tests I ran this evening. These are all builds from outside the source tree, including MinGW and Cygwin, which used a SMB mount to a Unix filesystem. Solaris 9 SPARC/GCC === 61 tests behaved as expected. 3 tests were skipped. Solaris 10 SPARC/GCC 61 tests behaved as expected. 3 tests were skipped. Solaris 10 x86/GCC == 61 tests behaved as expected. 3 tests were skipped. FreeBSD 5.4 === 62 tests behaved as expected. 2 tests were skipped. Apple OS-X Leopard PPC == 58 tests behaved as expected. 6 tests were skipped. Cygwin (old) on Windows XP == ERROR: 60 tests were run, 6 failed (3 expected failures). 4 tests were skipped. ## -- ## ## testsuite.log was created. ## ## -- ## Please send `tests/testsuite.log' and all information you think might help: To: [EMAIL PROTECTED] Subject: [libtool 2.1c] testsuite: 21 38 64 failed MinGW (old) on Windows XP = ERROR: 62 tests were run, 14 failed (3 expected failures). 2 tests were skipped. ## -- ## ## testsuite.log was created. ## ## -- ## Please send `tests/testsuite.log' and all information you think might help: To: [EMAIL PROTECTED] Subject: [libtool 2.1c] testsuite: 21 38 39 46 50 53 60 61 62 63 64 failed == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: linking a C program with a C++ library on Solaris
On Mon, 25 Feb 2008, Tim Mooney wrote: On Solaris, if you are linking against any C++ objects, you must use the C++ compiler to link. I don't know if that's common to other platforms or not, as I don't have access to the plethora of UNIX platforms I used to. In any case, the packages I've encountered don't seem to expect that, so the (libtool) link stage for the C project doesn't know to use C++, and the link fails. Libtool 2.2 does not have this problem. It should be released as soon as someone is available to create the release package since the consensus is that it is ready. Since it did not appear to happen this past weekend, maybe we will be lucky and it will pop out this next weekend. 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 a C program with a C++ library on Solaris
On Mon, 25 Feb 2008, Tim Mooney wrote: Thanks Bob, that's great news! I don't see anything in 2.1b's info files or README or NEWS for updating a project from 1.5.x to 2.2. I assume that means that there's nothing a project maintainer needs to do other than to re-libtoolize his or her project? I believe that backward compatability has been mostly respected. One thing I am aware of is that there is now a requirement that libtool be initialized before libltdl is initialized. There is some newer syntax now. This is what I am using for my nonrecursive project which also configures and builds libltdl nonrecursively. # Configure libtool AC_LIBTOOL_DLOPEN LT_INIT([disable-shared win32-dll]) LT_LANG([C++]) AC_SUBST(LIBTOOL_DEPS) # Configure libltdl LT_CONFIG_LTDL_DIR([ltdl]) LTDL_INIT([convenience nonrecursive]) Building libltdl nonrecursively saves a lot of configure time, and it makes the package smaller. I hope it is nice and warm in North Dakota. :-) 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: Convenience libraries build both PIC and non-PIC regardless of -static?
On Mon, 25 Feb 2008, Steven Brown wrote: Is there a way to tell libtool to not build those PIC objects without disabling shared libraries globally in the project with AC_DISABLE_SHARED? Probably not without an ugly recursive configure. The problem is that libtool does not know how the convenience libraries will be used so it plays it safe. If you are feeling brave, investigate using a non-recursive build in order to avoid convenience libraries entirely and improve build times. Time for my (mixed C and C++) project to build: recursive: gmake -j 6 89.10s user 7.47s system 195% cpu 49.413 total non-recursive: gmake -j 6 94.90s user 4.56s system 289% cpu 34.301 total The recursive project is older and has a bit less code to compile. The difference grows larger on slower systems. Notice that more build concurrency was achieved with the non-recursive build since with the recursive build there are more barrier points (e.g. packing and unpacking the convenience libs) where concurrency is not allowed. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool 2.2 release pending?
Is the libtool release scheduled for this weekend, or for next weekend? Thanks, 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: 2.1b license.
On Sat, 9 Feb 2008, Peter O'Gorman wrote: This reminds me, when doing the 1.5.26 release I started with a clean checkout, automake added COPYING v3, by chance I noticed and copied in v2. Should we commit COPYING to cvs to avoid this? That certainly seems like a wise idea, particulary since there are legal implications if someone checks out the files and the COPYING file is not there. 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: GNU Libtool 2.1b released (alpha release)
On Wed, 6 Feb 2008, Gary V. Vaughan wrote: With only one bug reported and fixed since Feb 1, either this is the most spectacularly well engineered release in the history of libtool, or else it is the least well tested release ever... I did voice one minor complaint on another list (automake). I don't like this one line in libltdl/Makefile.inc: BUILT_SOURCES += ltdl/$(ARGZ_H) since it still necessitate a recursive build when/if this Automake-contributed build rule is fixed: all: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) all-am so that it looks like all: all-am when BUILT_SOURCES is not defined and therefore avoids unnecessary recursion to achieve non-recursive build nirvana. Using BUILT_SOURCES is similarly evil to using SUBDIRS to a project desiring a completely non-recursive build. If there is a way to replace this with proper dependencies/rules prior to release, I would be very happy indeed. Ralph says this is not important but to me it is like purchasing a brand new sports car and noticing a small key mark on the driver side door. Not important to function but annoying as hell to the innate perfectionist. 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: GNU Libtool 2.1b released (alpha release)
On Fri, 1 Feb 2008, Gary V. Vaughan wrote: So, in effect, the patch I attached to my last message is the correct fix for the error you were seeing. Your micro-patch does work and does not bother me. Do you think we should put undocumented support for the temporary interface we had for a while back in for the next alpha? (a serious question) As long as package developers are aware of how things should be done in order to use latest libtool 2.1, it does not bother me if their packages do break. Libtool 2.1 is a work in progress and should be released soon. Other opinions may differ. 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: GNU Libtool 2.1b released (alpha release)
Gary, It turns out that your micro-patch does not actually work since there is a failure during 'make distcheck': gmake[2]: *** No rule to make target `ltdl/argz.lo', needed by `ltdl/libltdlc.la'. Stop. gmake[2]: Leaving directory `/scratch/bfriesen/build/GraphicsMagick-16-static/GraphicsMagick-1.2.020080201/_build' This was working not very long ago ... 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: [libtool 2.1b] testsuite: 16 54 55 56 failed
On Fri, 1 Feb 2008, Andreas Schwab wrote: Gary V. Vaughan [EMAIL PROTECTED] writes: Do you have a C++ compiler installed? No. I have a similar situation with Fortran since I have no other use for a Fortran compiler. In order to make the tests happy, I set both F77 and FC to 'no' in my /usr/local/share/config.site file. Presumably you could do the same for CXX. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.1b] testsuite: 16 54 55 56 failed
On Sat, 2 Feb 2008, Gary V. Vaughan wrote: DTRT. There should be no need to tweak config.site for CXX if F77 and FC are handled transparently... It would be nice if F77 and FC were properly handled transparently. Make it so! :-) It seems that in Andreas's environment 'g++' appears out of thin air. In my own environment there is confusion because even though GCC is being used, configure tries to use the Sun fortran compilers (also installed) with GCC-style formulas so tests fail. It seems likely that Sun fortran compilers could successfully be used but there is an implicit assumption that if the C compiler is GCC that all tools will be from the same tool chain. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: The right way to go in automake plus libtool
On Thu, 31 Jan 2008, Roger Ferrer Ibanez wrote: This works fine all the time (both running from the build directory and from the installe executable) but libtool complains, when doing 'make install' that it has to relink libB.la so I suspect that this is not the proper way to go. This complaint is not a cause for concern. It is really an informational warning that the program installed will not be 100% identical to the one tested via 'make check'. The need to re-link at install time is OS dependent. The most important thing is to make sure that your shared libraries are installed in the correct order so that when this relink occurs, it is against the freshly installed library rather than some older one which was already installed. 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: GNU Libtool 2.1b released (alpha release)
It is good that this is only an alpha release since it is now broken. Perhaps the massive flurry of changes at the very last minute was not a wise idea. I have been updating every few days without issues but today libtool broke GraphicsMagick: gmake[1]: *** No rule to make target `argz.lo', needed by `ltdl/libltdlc.la'. Stop. Configured with --enable-ltdl-convenience. 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: GNU Libtool 2.1b released (alpha release)
On Fri, 1 Feb 2008, Gary V. Vaughan wrote: What does this show in your environment? $ grep lt_ltdl_dir= configure lt_ltdl_dir='ltdl' $ grep lt_libobj_prefix lt_dlopen_dir=$lt_ltdl_dir; lt_libobj_prefix=$lt_ltdl_dir/ _ltdl_libobjs=$_ltdl_libobjs $lt_libobj_prefix$i.$ac_objext _ltdl_ltlibobjs=$_ltdl_ltlibobjs $lt_libobj_prefix$i.lo The same. What version of autoconf are you using? 2.61 Did you apply my small patch to the GraphicsMagick configure.ac and bootstrap scripts? I am not aware of any small patch from you. Is it diminishingly small so I might not have seen it? :-) FYI: Down-reving libtool to the version current as of 2008-01-28 produces a working libtool. I do recall Ralph mentioning to you a couple of days ago that something breaks GraphicsMagick but I did not pay much attention at the time. 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: 350-gary-maintain-private-libobj-namespace
Gary, This scrap of email from the libtool-patches list includes evidence that Ralf ran into the same problem that I ran into today. Something must be special about your environment. Note Ralf's observation that lt_libobj_prefix is not set by configure. Bob On Wed, 30 Jan 2008, Gary V. Vaughan wrote: Hallo Ralf, On 30 Jan 2008, at 14:43, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Tue, Jan 29, 2008 at 08:44:51AM CET: On 29 Jan 2008, at 06:45, Ralf Wildenhues wrote: I haven't reviewed your last two pending patches yet (but I'm not telling you to wait for me). Every little helps, even if you don't have time for a thorough review... Your latest version of this patch is so badly mangled as to be unapplicable. This is not the first time it happens. Please consider sending patches as (text!) attachments, or at least try to apply patches from your mails to see whether that works. Sorry, I was pasting the patch into the body since you asked me not to attach directly as that made it harder to review. I didn't use mailnotify because it breaks the thread. Maybe Mail.app will co-operate if I use a '.txt' extension for the patch attachments? Let me know if this is better. If not, I'll post with mailnotify, and put up with the broken message threading. When I try to apply this patch by hand, build and install, get CVS HEAD GraphicsMagick, and run its bootstrap script, I end up with this failure, which I assume is due to one of your patches, or to messup resulting from manual patch application. Anyway you should look at it before applying the patch (hint: lt_libobj_prefix seems not set in configure): /bin/sh ./libtool --silent --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall -pthread -module -avoid-version -L/usr/X11R6/lib -L/usr/lib -L/usr/lib -o ltdl/dlopen.la ltdl/loaders/dlopen.lo -ldl make[1]: *** No rule to make target `lt__strl.lo', needed by `ltdl/libltdlc.la'. Stop. make[1]: Leaving directory `/tmp/GraphicsMagick/build' make: *** [all] Error 2 Works for me, I reran bootstrap, and launched a successful VPATH build. Hopefully, you're just seeing a patch misapplication, otherwise we'll have to figure out what is different for us. Actually configure.ac and bootstrap can be cleaned up for (tomorrow's) libtool-2.1b. .txt patch attached, and fingers crossed. Index: b/libltdl/m4/ltdl.m4 === --- a/libltdl/m4/ltdl.m4 +++ b/libltdl/m4/ltdl.m4 [...] + +AC_CONFIG_COMMANDS_PRE([ +_ltdl_libobjs= +_ltdl_ltlibobjs= +if test -n $_LT_LIBOBJS; then + # Remove the extension. + sed_drop_objext='s/\.o$//;s/\.obj$//' This is code that ends up in configure. sed_drop_objext is not namespace clean, please prefix with _lt_ or so. Careless pasting from gnulib-tool. CCing the gnulib list so they can fix their version too... gl_sed_drop_objext? + for i in `for i in $_LT_LIBOBJS; do echo $i; done | sed $sed_drop_objext | sort | uniq`; do `sort -u' is portable. Tx. Fixed in the attached. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: FYI: 333-gary-refactor-LTDL_INIT.patch
On Wed, 16 Jan 2008, Ralf Wildenhues wrote: However, as usual, I don't feel qualified to review other aspects of this patch... Well, thanks anyway for spotting this typo! With this change, I am ok with the documentation updates. However, I am fairly confident that old libtool documentation recommended the opposite order, and opposite order was likely required at that time. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: make -s
On Mon, 14 Jan 2008, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Jan 10, 2008 at 08:29:33AM CET: For whatever output is left done by libtool I expect that whoever want's it silenced hard enough will have enough motivation to send a patch to [EMAIL PROTECTED]. Since repeatedly nobody stepped forward to do this, I wrote that patch myself now. OK to apply to HEAD? I think that this patch is ok but it is a major change so I think that we should hear from several people before applying it. This change will impact my own package since my package applies --silent by default in order to intentionally obtain a medium level of output. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
GraphicsMagick updated with latest CVS libtool
I have updated development GraphicsMagick with the latest CVS libtool. The snapshot is named GraphicsMagick-1.2.020080113.* (or later) and can be downloaded from ftp://ftp.graphicsmagick.org/pub/GraphicsMagick/snapshots;. This is a good test of development libtool with C, C++, and non-recursive build, with libltdl. However, libltdl's static preload feature is not used by this package. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
CVS Head FreeBSD 5.4 test results
## - ## ## Test results. ## ## - ## ERROR: 57 tests were run, 11 failed (3 expected failures). 2 tests were skipped. ## -- ## ## testsuite.log was created. ## ## -- ## Please send `tests/testsuite.log' and all information you think might help: To: [EMAIL PROTECTED] Subject: [libtool 2.1a] testsuite: 29 32 33 34 55 56 57 59 failed A gzipped testsuite.log is attached. The test results on Solaris 10 (SPARC and x86) and Apple OS-X Leopard seem reasonable. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ testsuite.log.gz Description: Binary data
Re: build check in AIX 5.2 / 5.3 / 6.1 - gcc/g++
On Thu, 10 Jan 2008, Rainer Tammer wrote: With gcc 4.0.0 I need to include: libltdl/ltdl.c #include sys/access.h R_OK is undefined Does using #include unistd.h not work as it should? Perhaps there is a fixincludes bug in this old double oh (double oh indicates suspect) GCC version? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: build check in AIX 5.2 / 5.3 / 6.1 - gcc/g++
On Thu, 10 Jan 2008, Rainer Tammer wrote: problem see below. Perhaps there is a fixincludes bug in this old double oh (double oh indicates suspect) GCC version? No, its a configure problem. The problem is that: gcc build libltdl/config.h: /* Define to 1 if you have the unistd.h header file. */ /* #undef HAVE_UNISTD_H */ That is quite a problem since this is an important header. It is useful to consult config.log and see why this test fails. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: make -s
On Thu, 10 Jan 2008, Bob Rossi wrote: Well, I might be over simplifying things because I don't understand the big picture. When I type 'make -s' I assume that the compiler commands that make kicks off will not be sent to stdout/stderr. I do expect that if the user has some stuff in the Makefile that prints to stdout/stderr that it would show up there. Yes, all 'make -s' is supposed to do is to cause make not to provide information about what it is doing. It should not influence anything else. The only contract that libtool should offer is that if --silent is supplied, it should similarly not provide information about what it is doing. It should only provide information about what has gone wrong. Unfortunately, sometimes it is very difficult to decipher an error message unless you know the precise action which was being performed. The automake project would be a better place to add extra smarts for a more silent build when using libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: _GLOBAL__FD_libfoo_so
On Thu, 10 Jan 2008, Ralf Wildenhues wrote: Glancing at GCC sources, I gather that symbols matching ^_GLOBAL__F[ID]_.*$ are init/fini functions for shared libraries. Would it be appropriate Ugh. if libtool skipped these when doing symbol extraction? On any system, when GCC is used, or even with any compiler? Would the above be the most general egrep pattern to match these symbols? Are there however other symbols we should not extract (so far only _GLOBAL_OFFSET_TABLE_)? I don't know, but most likely we will find out when the time comes. Thus, OK to apply this patch which fixes the failures (HEAD and branch-1-5)? The patch looks safe to apply to me. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: make -s
On Thu, 10 Jan 2008, Bob Rossi wrote: Well, I might be over simplifying things because I don't understand the big picture. When I type 'make -s' I assume that the compiler commands that make kicks off will not be sent to stdout/stderr. I do expect that if the user has some stuff in the Makefile that prints to stdout/stderr that it would show up there. Yes, all 'make -s' is supposed to do is to cause make not to provide information about what it is doing. It should not influence anything else. The only contract that libtool should offer is that if --silent is supplied, it should similarly not provide information about what it is doing. It should only provide information about what has gone wrong. Unfortunately, sometimes it is very difficult to decipher an error message unless you know the precise action which was being performed. The automake project would be a better place to add extra smarts for a more silent build when using libtool. 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: mingw install directory for shared lib
On Wed, 9 Jan 2008, Duft Markus wrote: Bob Friesenhahn wrote: On Tue, 8 Jan 2008, Ralf Wildenhues wrote: General question before fixing this: on w32, should even plugins have their DLLs go to $bindir? Yes, i'd agree to this... ;o) If you try to load a library by yourself, you will have to know what you're doing. If the DLL is linked to the executable, you have no (easy) way to influence what is done by the loader... Modules should not be linked with an executable. That would surely be bad design and should not be supported. There should be no need to load a module by yourself since libtool offers libltdl which does it for you by requesting to load the associated .la file. Regardless, loading modules directly is trivially easy under Windows. Of course there may still be problems if there are dependencies between plugins, that are installed in different directories, since loading one plugin will load all libraries this dll is linked to. If those are plugins themselves, they will have to be in PATH to be found (or in the same directory, etc.). The easiest solution is using parity ;) but thats self-advertisement again, sorry... There should be no dependencies between plugins. That would surely be bad design and should not be supported. Libtool should be supporting portable behavior. If the user does not desire to implement portable behavior, then there is little value to using libtool or libltdl. The portable definition for windows should be: library - Executables (usually) link directly with libraries and when the library is a DLL it should be installed in the executable search path, and (ideally) be in the same 'bin' directory as the dependent executables. module - Modules are only loaded via an explicit loading mechanism (e.g. Windows LoadLibrary() or libltdl. Modules may depend on libraries (see above) but should not depend on other modules. Since modules are explicitly loaded, they may be installed in an application-specific lib directory (just like for Unix). Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
