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