Re: cwrapper generates long strings.

[Charles Wilson]

On 10/1/2010 7:28 AM, Peter Rosin wrote:
> I.e. I have this on line 865 in lt-main.c:
> 
>   fputs ("relink_command=\"(cd 
> /c/cygwin/home/peda/libtool/git/msvc/tests/testsuite.dir/112; 
> PATH=\\\"/LOADS:/OF:/ENTRIES\\\"; export PATH; 
> PATH=\\\"/LOADS:/OF:/ENTRIES\\\"; export PATH; 
> /c/cygwin/home/peda/automake/lib/compile cl -MD -Zi -EHsc -o @OUTPUT@ 
> .libs/main-static.obj  sub2/.libs/a.lib )\"\n", f);
> 
> In my case the string is 3400+ characters which is too much for MSVC 6,
> but this appears to not be really compiler specific, and I can easily
> imagine other compilers with other arbitrary (and possibly standardized)
> limits.

c99 compilers must support const char* arrays of at least 4096.  Most
compilers actually support much larger ones.

c89 requires only support for up to 509.  See:
http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00161.html
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00004.html

> One thing that could be done is to only have the PATH once, but that is
> not a real fix.

It's also not general.  One is explicitly setting PATH, the other is
setting $shlibpath_var (which happens to be PATH on win32).

> Should we worry about my insane case?

I don't think it is a high priority.  What we could do is implement a
"line emitter" in ltmain.m4sh, for use by func_emit_cwrapper_exe.  Right
now, it takes the output of func_emit_wrapper and puts "fputs(\"" and
"\n\"" around each line.

Instead, each line could be fed to a line-emitter function that chops
the line into segments of <= 500 chars.

But...that's a lot of effort for very little gain.

I think a better approach would be to start asking, why do we still need
the cwrapper to contain and emit the shell wrapper code in the first
place?  Maybe instead, we should just remove --lt-dump-script and all
related code.

It was originally present because the cwrapper would emit the shwrapper,
and then exec it.  But now, the cwrapper exec's the real program
directly, so this functionality is no longer needed.  It hasn't been
needed for years, but I didn't want to make too many changes at once so
I left it there even after cwrapper was changed to direct exec the real
program.  But...I always intended to get rid of it.  Perhaps now is the
time.

--
Chuck