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

Previous Next

Package: libtool;

Reported by: Aaron Burghardt <aaron.burghardt <at> gmail.com>

Date: Sun, 11 Jan 2015 18:20:04 UTC

Severity: normal

To reply to this bug, email your comments to 19569 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-libtool <at> gnu.org:
bug#19569; Package libtool. (Sun, 11 Jan 2015 18:20:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aaron Burghardt <aaron.burghardt <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-libtool <at> gnu.org. (Sun, 11 Jan 2015 18:20:05 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Aaron Burghardt <aaron.burghardt <at> gmail.com>
To: bug-libtool <at> gnu.org
Subject: 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)]

This bug report was last modified 10 years and 164 days ago.

Previous Next


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