Turn off warning when installing modules?
Is there a good way to turn off the usage message that gets displayed every time a module is installed by libtool? This usage message is useful for normal shared libraries, but is not useful for loadable modules. Thanks, Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
GNU libtool 32/64-bit Support
Hello, We're currently using GNU libtool v1.4 on Solaris 2.6, but are preparing to upgrade to Solaris 8. Can you please tell me if you provide a 32-bit and 64-bit version of libtool and for how long you plan on supporting them? Thank you, Maria E. Torok NASA - CLCS COTS Software Coordinator Lockheed Martin Space Operations Phone: 321-861-9192 Fax: 321-861-9121 E-mail: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GNU libtool 32/64-bit Support
On Wed, 10 Oct 2001, Torok-1, Maria wrote: > We're currently using GNU libtool v1.4 on Solaris 2.6, but are preparing to > upgrade to Solaris 8. Can you please tell me if you provide a 32-bit and > 64-bit version of libtool and for how long you plan on supporting them? Libtool itself is a script so it does not care about 32-bit or 64-bit. The libltdl component is compiled so it does care. The development version of libltdl is currently not 64-bit bit safe. A patch was submitted to this list, but it has not been applied yet. Using the patch, ImageMagick has been shown to work properly under Solaris 8 when compiled as 32-bit or 64-bit. The patch simply makes libltdl POSIX-compliant. Libtool is not commercial software (although you may be able to purchase commercial support). Based on experience with other open source packages, it is safe to say that it will be supported for as long as it remains actively in use on your chosen operating system. If you send it to Mars, then it will be supported longer. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ar cru piecewise linking of same named objects
Robert Boehne <[EMAIL PROTECTED]> writes: > > Could you try changing AR_FLAGS in your libtool script > to see if that works? AR_FLAGS=cq seems to work on all the systems I've tried, and fixes the ultrix problem. As long as ranlib does its job then I imagine it'd have to work everywhere. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ar cru piecewise linking of same named objects
Kevin Ryde wrote: > > Robert Boehne <[EMAIL PROTECTED]> writes: > > > > Could you try changing AR_FLAGS in your libtool script > > to see if that works? > > AR_FLAGS=cq seems to work on all the systems I've tried, and fixes the > ultrix problem. As long as ranlib does its job then I imagine it'd > have to work everywhere. > What's the Ultrix problem? Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ar cru piecewise linking of same named objects
Robert Boehne <[EMAIL PROTECTED]> writes: > > What's the Ultrix problem? It was vax-dec-ultrix4.5 which had the small command line limit and suffered in the piecewise link. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool cvs rm -f ""
Solaris 2.7 and HP-UX 10 don't think much of rm -f "" it provokes a bit of an error rm: cannot remove `.' or `..' This arises from libtool when compiling, I think due to $output_obj being empty when -c -o works. This is no more than cosmetic, but perhaps cases where that might happen should have a 2>/dev/null or similar. Bit silly really, the whole point of -f is to make rm shut up in the first place. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool cvs rm -f ""
On Thu, Oct 11, 2001 at 09:24:15AM +1000, Kevin Ryde wrote: > Solaris 2.7 and HP-UX 10 don't think much of > > rm -f "" > > it provokes a bit of an error > > rm: cannot remove `.' or `..' > > This arises from libtool when compiling, I think due to $output_obj > being empty when -c -o works. > > This is no more than cosmetic, but perhaps cases where that might > happen should have a 2>/dev/null or similar. > > Bit silly really, the whole point of -f is to make rm shut up in the > first place. automake uses this construction in clean rules: -test -z "$(FOO)" || rm -f $(FOO) The comment in clean.am says: ## We must test each macro because it might be empty, and an empty "rm ## -rf" command looks disturbing. Also, the Solaris 2.4 "rm" will ## return an error if there are no arguments other than "-f". Cheers, Olly ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool cvs rm -f ""
Olly Betts <[EMAIL PROTECTED]> writes: > > ## We must test each macro because it might be empty, and an empty "rm > ## -rf" command looks disturbing. Also, the Solaris 2.4 "rm" will > ## return an error if there are no arguments other than "-f". Soor, I pruned too much, the libtool case is instead something like rm -f "foo.o" "" or for PIC, rm -f ".libs/foo.o" "" It's the empty argument which is the problem, not no arguments as such. I guess the quotes support spaces in filenames, it probably works without them. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool cvs rm -f ""
On Thu, Oct 11, 2001 at 09:57:18AM +1000, Kevin Ryde wrote: > Soor, I pruned too much, the libtool case is instead something like > > rm -f "foo.o" "" Ah right. > It's the empty argument which is the problem, not no arguments as > such. > > I guess the quotes support spaces in filenames, it probably works > without them. I understand autoconf/automake/libtool have problems with filenames with spaces in, though that's really not an argument for making things worse. As you suggested, "2> /dev/null" would hide the message. Or if that seems unclean, the rm could be split into two (perhaps for a small performance penalty in that rm gets run twice in one case): rm -f "foo.o" test -z "$foo_objs" || rm -f "$foo_objs" Or use an if to handle the two cases: if test -z "$foo_objs" ; then rm -f "foo.o" else rm -f "foo.o" "$foo_objs" fi Cheers, Olly ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GNU autoconf, automake, make, m4 32/64-bit Support
"Torok-1, Maria" wrote: > > Anything you could tell me regarding 32-bit and 64-bit versions of automake, > make, and m4 would also be appreciated! > [..] > > E-mail: [EMAIL PROTECTED] "Torok-1, Maria" wrote: > We're currently using GNU libtool v1.4 on Solaris 2.6, ... before you flood the mailing-list, autoconf/automake etcetera are scripted on top of other tools that are to be asked for 64-bit support, the scripts that we discuss on these mailinglists are not a problem. you could use the solaris make/cc just as you can use gmake/gcc - since I was able to build on ia64 with gnu tools, I don't see a problem here. Unix-systems will also ship with an m4 but autoconf manuals says it requires gm4 - I do not know if m4 @ sun.2.8 has evolved enough to be compatible. For automake you will want to look for a perl package. If that is good, feel free to do the rest. Does anyone intend to support 64-bit? Absolutly! and for all time... well, you know, it's the future atleast of unixish systems... cheers, -- guido joke: windows) where do you want to go today linux) where do you want to go tomorrow unix) are you coming guys? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
