Why do we chmod static libraries 644 after we install them? What's
wrong with leaving them at whatever the install line specified?
-jeff
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Mon, Oct 22, 2001 at 04:58:09PM -0400, [EMAIL PROTECTED] wrote:
> In cases where there are more object files than can fit in a single
> command line this method will fail. While it is faster it isn't as
> robust so I'm inclined to reject it.
OK, would you accept it if it were changed to:
if
Hmm. I was having trouble trying to feed 'xargs' it's data without
actually putting it all on a command-line at some point(silly, eh?).
In any event, perhaps something like this will work:
for each file
...
$rmfiles=$rmfiles $some_files_to_delete
...
if 100 < -l "$rmfi
On Wed, Oct 24, 2001 at 09:21:48AM -0500, Robert Boehne wrote:
>
> Libtool saves a good guess for the maximum length
> of command lines as max_cmd_len so if you wanted to
> support removing files up to an average of 99 characters
> you could divide max_cmd_len by 100 to get the number
> of files
When a compiler is insufficiently cool, libtool uses hard-link locking
to prevent the same file from being compiled in the same place.
It does this by waiting until:
ln /usr/bin/libtool whatever.lock
succeeds.
However, if libtool is installed on a different filesystem from where
the compile is
For static libraries, is it necessary that they be chmod'd 644? This
is done automatically by libtool, and I was wondering if there was a
way to leave them 664 (as install's -m flag specifies).
Thanks,
-jeff
___
Libtool mailing list
[EMAIL PROTECTED]
On Wed, Feb 05, 2003 at 05:09:14PM -0600, Bob Friesenhahn wrote:
> Unfortunately, there is a design problem with libtool. There should
> be libtool command-line switches to support this, but instead these
> options must be set when libtool is configured. These options are set
> via an autoconf co
