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

[Robert Boehne]

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+ ?)

Thanks,

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 ltmain.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 ltmain.sh plus configuration sections.  ltmain.sh
> is a preprocessed version of ltmain.in.
> 
> > 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 http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  address@hidden, redhat.com}
> CS PhD student at IC-Unicamp        address@hidden, gnu.org}
> 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