GNU bug report logs - #12156
bad tr command in SP2NL/NL2SP?

Previous Next

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

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

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

From: David Fang <fang <at> csl.cornell.edu>
To: bug-libtool <at> gnu.org
Subject: bad tr command in SP2NL/NL2SP?
Date: Tue, 7 Aug 2012 20:29:47 -0400 (EDT)

Hi,
	On i686-darwin10, using libtool-2.4.2, I see the following occur:

$ make libhacktcommon.la
/bin/sh ../libtool  --tag=CXX   --mode=link ccache g++ -pipe -ansi 
-pedantic-errors -Wold-style-cast -Woverloaded-virtual -W -Wextra -Wall 
-Wundef -Wshadow -Wno-unused-parameter -Wpointer-arith -Wcast-qual 
-Wcast-align -Wconversion -Werror -m32 -g -O2 -L/sw/lib  -L/sw/lib 
-Wl,-no_compact_linkedit -o libhacktcommon.la 
Object/common/object_base.lo Object/common/extern_templates.lo 
Object/common/dump_flags.lo common/config.lo common/ltdl-wrap.lo 
common/ICE.lo common/TODO.lo  ../libltdl/libltdlc.la
libtool: link: rm -fr  .libs/libhacktcommon.a .libs/libhacktcommon.la
libtool: link: (cd .libs/libhacktcommon.lax/libltdlc.a && ar x 
"/Users/fang/local/src/hackt-git/gcc-4.2-build/src/../libltdl/.libs/libltdlc.a")
usage: tr [-Ccsu] string1 string2
       tr [-Ccu] -d string1
       tr [-Ccu] -s string1
       tr [-Ccu] -ds string1 string2
libtool: link: ar cru .libs/libhacktcommon.a 
Object/common/.libs/object_base.o Object/common/.libs/extern_templates.o 
Object/common/.libs/dump_flags.o common/.libs/config.o 
common/.libs/ltdl-wrap.o common/.libs/ICE.o common/.libs/TODO.o
libtool: link: ranlib .libs/libhacktcommon.a
libtool: link: rm -fr .libs/libhacktcommon.lax
libtool: link: ( cd ".libs" && rm -f "libhacktcommon.la" && ln -s 
"../libhacktcommon.la" "libhacktcommon.la" )

I get this funny message about tr usage.


The exit status is 0, so it thinks nothing went wrong, but the resulting 
libhacktcommon.la shows:

---------- 8< snip ----------
# Libraries that this one depends upon.
dependency_libs=' -L/sw/lib'
---------- snip 8< ----------

with no mention of libltdl.

in Makefile.am, I have:
---------- 8< snip ----------
# convenience libraries
noinst_LTLIBRARIES = ... \
        libhacktcommon.la

libhacktcommon_la_SOURCES = ...
libhacktcommon_la_LIBADD = $(LIBLTDL)
---------- snip 8< ----------

where LIBLTDL happens to be (in this case):
LIBLTDL = ${top_build_prefix}libltdl/libltdlc.la

=============== cat libltdlc.la ====================
# libltdlc.la - a libtool library file
# Generated by libtool (GNU libtool) 2.4.2
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libltdlc.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=' '

# Libraries that this one depends upon.
dependency_libs=''

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libltdlc.
current=
age=
revision=

# Is this an already installed library?
installed=no

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=' 
/Users/fang/local/src/hackt-git/gcc-4.2-build/libltdl/./.libs/dlopen.a'

# Directory that this library needs to be installed in:
libdir=''
=============== end of libltdlc.la ===================

Looks normal to me.

The only occurrences of 'tr' I see in the libtool script are:
---------- 8< snip ----------
# turn spaces into newlines.
SP2NL="tr   "

# turn newlines into spaces.
NL2SP="tr ^M
   "
---------- snip 8< ----------

SP2NL looks weird to me.
My tr is /usr/bin/tr (darwin10).

$(top_srcdir)/configure shows:

---------- 8< snip ----------
# test EBCDIC or ASCII
case `echo X|tr X '\101'` in
 A) # ASCII based system
    # \n is not interpreted correctly by Solaris 8 /usr/ucb/tr
  lt_SP2NL='tr \040 \012'
  lt_NL2SP='tr \015\012 \040\040'
  ;;
 *) # EBCDIC based system
  lt_SP2NL='tr \100 \n'
  lt_NL2SP='tr \r\n \100\100'
  ;;
esac
---------- snip 8< ----------

coming from some libtool m4 macro, I assume?

Did something go wrong with SP2NL?

Here's a --debug trace of the above command:
---------- 8< snip ----------
+ eval '(cd $f_ex_an_ar_dir && ar x "$f_ex_an_ar_oldlib")'
++ cd .libs/libhacktcommon.lax/libltdlc.a
++ ar x 
/Users/fang/local/src/hackt-git/gcc-4.2-build/src/../libltdl/.libs/liblt
dlc.a
+ my_status=0
+ test 0 -eq 0
+ :
+ test yes = yes
+ false
+ rm -f 
/Users/fang/local/src/hackt-git/gcc-4.2-build/src/../libltdl/.libs/liblt
dlc.a.lock
+ ar t 
/Users/fang/local/src/hackt-git/gcc-4.2-build/src/../libltdl/.libs/libltd
lc.a
+ sort
+ sort -uc
+ :
++ find .libs/libhacktcommon.lax/libltdlc.a -name '*.o' -print -o -name 
'*.lo' -
print
++ sort
++ tr $'\r'
usage: tr [-Ccsu] string1 string2
       tr [-Ccu] -d string1
       tr [-Ccu] -s string1
       tr [-Ccu] -ds string1 string2
---------- snip 8< ----------

Looks like tr (piped) is only getting one argument.

If I try this on the command line (escaping $):
fang> tr \$'\r'
usage: tr [-Ccsu] string1 string2
       tr [-Ccu] -d string1
       tr [-Ccu] -s string1
       tr [-Ccu] -ds string1 string2

I get the usage message, and an exit status of 1.
I don't see a set -o pipefail in the script so the overall exit status of 
the libtool script is still 0.

Any idea what exactly went wrong?
Can you suggest a workaround?

Thanks for any help.

Fang


-- 
David Fang
http://www.csl.cornell.edu/~fang/

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

From: David Fang <fang <at> csl.cornell.edu>
To: 12156 <at> debbugs.gnu.org
Subject: Re: bug#12156: Acknowledgement (bad tr command in SP2NL/NL2SP?)
Date: Tue, 7 Aug 2012 22:13:50 -0400 (EDT)

I opened up a libtool script from a working build on a linux machine and 
saw:

# turn spaces into newlines.
SP2NL="tr \\040 \\012"

# turn newlines into spaces.
NL2SP="tr \\015\\012 \\040\\040"

I pasted-replaced that into the broken libtool script on darwin10.
I cleaned all .la files to remake them, and all of the above problems went 
away.

So I guess an ugly temporary workaround is to patch the 
configure-generated libtool script between configure && make?

Fang

-- 
David Fang
http://www.csl.cornell.edu/~fang/

Previous Next

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