Alexandre Oliva wrote:
>
> On Dec 12, 2000, Robert Boehne <[EMAIL PROTECTED]> wrote:
>
> > Using the multi-language-branch as a starting point, I have a working
> > "libtool" script that incrementally links libraries to prevent running
> > into limits of the shell.
>
> Cool!
>
> > I have defined two new shell variables in libtool,
> > ${incr_archive_cmds} and ${old_incr_archive_cmds}, which are used
> > instead of ${archive_cmds}/${old_archive_cmds} when ${max_cmd_len}
> > is less than the length of the expanded
> > "${archive_cmds}/${old_archive_cmds}".
>
> I can see the point of old_incr_archive_cmds, given that
> old_archive_cmds can be pretty much anything, and you can't count on
> being able to incrementally add object files to it, but the good thing
> is that old_archive_cmds is only overridden on Cygwin and Mingw.
>
> However, incr_archive_cmds doesn't seem very useful to me. It would
> seem to me that it would be easier to arrange for libtool to know how
> to use reload_flag to link multiple object files into a single one,
> and iterate until the command line is short enough.
>
Right now, $incr_archive_cmds will first create an archive file one .o
at a time,
then link a shared object with the archive file in place of $libobjs.
This works, _but_ it is an order of magnitude slower than the direct
method
(which of couse, doesn't actually work). Many compilers have a command
line
switch for giving a list of object files in a text file, SGI, HP and
Tru64
all have this with their native compilers. I also just can't shake the
notion
that some platforms won't let you create shared objects from archives.
(of couse I could be wrong)
> But I like the idea of using preprocessor symbols. How about
> preprocessing a program with the same #includes you use, but ending
> with:
>
> #if defined ARG_MAX
> LIBTOOL linelen ARG_MAX
> #else
> # if defined NCARGS
> LIBTOOL linelen NCARGS
> # endif
> #endif
>
> Then you grep the preprocessed file for '^LIBTOOL linelen *[0-9]* *' and
> extract the constant with sed. If there's no such constant, we might
> play with binary searching the length by running, say, `ls'. Or just
> go with a fixed, reasonable number, that can then be increased on a
> per-platform basis.
Ah, yes, I hadn't thought about that, I'll incorporate your suggestion.
Sill I wonder what file to put it in, ltconfig.in seems to be the best
option.
> > In my current implementation, the old method of linking is used unless
> > ${incr_archive_cmds} is defined AND the command is too long for the
> > shell.
>
> What if the command line is too long and incr_archive_cmds isn't
> defined?
In this case there is some work to do, someone needs to add the
definition
of incr_archive_cmds to the ltcf-*.sh files. I can test quite a few
platforms
here (~7) , the rest will be left as an exercise for the reader. ;)
Also, in reading the GNU Coding Standards, the list of unix commands
that
are allowable does not include "wc". I can't help but use it, or
somthing
else not in the list. Will this be a problem? Should we ammend the
list?
Cheers!
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
