From: Axel H. <aho...@gm...> - 2010-09-09 13:53:20
|
Hello Ralf et al, On Tue, Sep 07, 2010 at 10:41 PM Ralf Wildenhues wrote: > Hello Axel, > > * Axel Holzinger wrote on Tue, Sep 07, 2010 at 10:47:14AM CEST: > > On compiling FFmpeg's libavcodec from FFmpeg's main make > (calling all > > the subdirectories' make) I get the error "command line too > long" and > > obviously the command line is longer than 8192 > characters/bytes. (For > > the interested: the error happens at the stage of calling the > > archiver, as in the command line every object file is referenced by > > its relative path WITH the libavcodec subdirectory). > > Please supply a link to the tarball you are building. I'm buildung from SVN trunk, but I don't think there is an error in the build/configuration. svn://svn.ffmpeg.org/ffmpeg/trunk > > In some configure scripts there is a check for command line length > > included ("checking the maximum length of command line arguments"). > > That check comes from Libtool macros. Is libtool used for > linking here? I don't think so. > It has means to avoid the command-line length limit (either > by calling the archiver repeatedly, or, with newer libtool, > also using @file support). If that's broken, we'd like to know. > > If the package in question doesn't use libtool, well, it > could of course implement either of those workarounds as well. I think I found the reason for MinGW/MSys bash having the 8192 characters limit. I think MinGW/MSys bash is compiled as a Windows console application which brings up Windows' cmd.exe code which does the Window handling and keyboard/mouse input. And this part is known to have the 8192 characters input. To gain the 32768 characters commandline that NT/XP/Vista/7 offers via its CreateProcess function MinGW/MSys bash would need to be a native Win32 application instead of a console application. But this is still a wild guess. Somebody listening who knows how it is? Thank you Axel |