GNU bug report logs - #19569
Problem with line splitting output from func_emit_wrapper

Previous Next

Full log

View this message in rfc822 format

From: Aaron Burghardt <aaron.burghardt <at> gmail.com>
To: 19569 <at> debbugs.gnu.org
Subject: bug#19569: Problem with line splitting output from func_emit_wrapper
Date: Sun, 11 Jan 2015 06:14:26 -0500

[Message part 1 (text/plain, inline)]

I am attempting to cross-compile the standard jpeg source, http://www.ijg.org <http://www.ijg.org/>, with mingw-w64 on OS X. The build fails because executables wrapped by libtool do not compile. The jpeg source comes with an ltmain.sh script produced by libtool version 2.4.2 . I happen to have libtool 2.4 installed, and I was able to build the project by running libtoolize, which generated an ltmain.sh from my older version. I tracked the issue down to a change in a sed command in ltmain.sh that splits long lines in the output of func_emit_wrapper() to make the output suitable for all compilers. This list thread lead to the following patch:

http://lists.gnu.org/archive/html/bug-libtool/2010-10/msg00000.html <http://lists.gnu.org/archive/html/bug-libtool/2010-10/msg00000.html>
http://git.savannah.gnu.org/cgit/libtool.git/commit/libltdl/config/ltmain.m4sh?id=c161010e9deec544410a3e91d105d07ed9ec9911 <http://git.savannah.gnu.org/cgit/libtool.git/commit/libltdl/config/ltmain.m4sh?id=c161010e9deec544410a3e91d105d07ed9ec9911>

To save having to click the link, the commit is:


diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 0418007..1078e75 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4268,9 +4268,15 @@ void lt_dump_script (FILE* f)
 {
 EOF
 	    func_emit_wrapper yes |
-              $SED -e 's/\([\\"]\)/\\\1/g' \
-	           -e 's/^/  fputs ("/' -e 's/$/\\n", f);/'
-
+	      $SED -n -e '
+s/^\(.\{79\}\)\(..*\)/\1\
+\2/
+h
+s/\([\\"]\)/\\\1/g
+s/$/\\n/
+s/\([^\n]*\).*/  fputs ("\1", f);/p
+g
+D'
             cat <<"EOF"
 }
 EOF

OS X’s sed is not GNU sed, is older, and doesn’t support many of GNU sed’s extensions. I could install GNU sed to resolve this, but I’m curious, is the sed command not POSIX compliant, or is OS X’s sed not POSIX compliant? Am I correct to think POSIX compliance is a goal of autotools?

Thanks,

Aaron

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.