[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Finding command size; was Re: FIX for Arg list too long...

From: Robert Boehne
Subject: Finding command size; was Re: FIX for Arg list too long...
Date: Thu, 30 Nov 2000 14:54:38 -0600

To all Gurus:

Ok, I'm currently working on the implementation of a fix
for "Arg list too long" errors, but I wonder if anyone
could give me advice on how to get the size of the
command that will be used.  How about this:

length=`echo ${some_command} | dd bs=1 of=/dev/null 2>&1 | head -1 | cut
-d'+' -f1`

If I get the command length, I would then need to test if it
is too long, perhaps by adding one character to see if the length
calculated by the above method has changed

Q: is this portable?  My shell scripting book says it is not
extremely portable, any ideas on how to do this without dd?

Q: Should I just avoid this problem all together by always
building archive files by adding one object at a time?

Q: Are there any platforms that cannot make a shared
library out of an archive file? (AIX 4.2+ ?)


Robert Boehne

Alexandre Oliva wrote:
> On Nov 28, 2000, Robert Boehne <address@hidden> wrote:
> > Have you any ideas for possible ways to implement this?
> You mean, besides the sketch that's in the message you quoted.  No, I
> don't have thought it out at all beyond that.  Basically, you want to
> look for occurrences of AR in and check the length of the
> command-line that would be used, issuing multiple AR commands instead.
> In the case of archive_cmds, it may be harder than that, since the
> complete command-line is constructed in advance (that may be the case
> for AR too, these days), but I don't expect it to be too hard to
> figure out where to introduce the relinking steps.  Just make sure you
> clean up afterwards any temporary object files you create.
> > I think I can get the time, but my best idea so far is
> > to start by figuring out just how libtool works, and just
> > how "libtool" is created.
> libtool is basically plus configuration sections.
> is a preprocessed version of
> > If you can think of any gotchas to watch out for, it would probably
> > save me several days of development.
> Make sure you start in the multi-language branch.  I doubt this new
> feature will be ready in time for release 1.4, and development should
> be focused in the next major release, that will be based on the
> branch.
> --
> Alexandre Oliva   Enjoy Guarana', see
> Red Hat GCC Developer                  address@hidden,}
> CS PhD student at IC-Unicamp        address@hidden,}
> Free Software Evangelist    *Please* write to mailing lists, not to me

Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]