GNU bug report logs -
#19569
Problem with line splitting output from func_emit_wrapper
Previous Next
To reply to this bug, email your comments to 19569 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
[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.