On Thu, 17 Jan 2013, Pavel Raiskup wrote:

> Hi liboolers,
>
> the problem — e.g. running the:
>
>  libtool execute ls BIGfile
>
> could stack computer atm (if user has swap enabled and) if the BIGfile
> refers to really big file not containing new-lines.
>
> For more info see the bug:
>
>  http://bugzilla.redhat.com/636045
>
> =====
>
> The problem is that libtool is trying to guess whether the 'BIGfile' is
> ltwrapper or not (I guess).  One step in this check is that libtool runs
> sed for 'head' purposes:
>
>  sed -e 4q BIGfile
>
> The problem of this sed command is that it is probably buffering whole
> "binary lines" (which may have gigabytes) into memory.  Don't know "how"

This seems like a problem even on larger machines.  Executables and 
libraries can be rather large files.  If sed does absorb the whole 
file (reading tens of megabytes, or even over 100 MB, for debug 
builds) then there is an efficiency loss.

Since libtool has a configure script, it can test for whatever 
features are needed and provide a portable fallback in case 'dd' is 
not available.

Everything would be easier if libtool would arrange to build a small 
helper executable in the build tree which it can used instead of 
system tools.  Libtool already builds a native executable in some 
cases.  This would diminish portability concerns and improve 
performance.  The main issue with this is that for cross-builds, a 
system native compiler needs to be used to build the helper 
executable.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/