GNU bug report logs - #20947
libtool 2.4.2 is not robust to a missing global_symbol_pipe

Previous Next

To reply to this bug, email your comments to 20947 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: Philip Chimento <philip.chimento <at> gmail.com>
To: bug-libtool <at> gnu.org
Subject: libtool 2.4.2 is not robust to a missing global_symbol_pipe
Date: Tue, 30 Jun 2015 15:24:41 -0700

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

This is a difficult-to-reproduce bug since it only occurs due to outside
influences. However, I believe libtool's behaviour could be improved to
make it more obvious what is going on when the bug occurs.

Many instances of the symptom can be found by doing an internet search for
"libtool global_symbol_pipe". Basically the configure check for the sed
expression to parse the output of nm can fail, without causing configure to
abort.

    checking command to parse /usr/bin/nm -B output from gcc object...
failed

This results in the variable global_symbol_pipe being empty in the
generated libtool script, which causes compilation to fail later on:

    libtool: link: /usr/bin/nm -B <OBJECT-FILES> | | /bin/sed 's/.* //' |
sort | uniq > <EXPORTED-SYMBOL-FILE>

    ./libtool: eval: line <LINE>: syntax error near unexpected token `|'

(The empty space between the pipes is where the empty global_symbol_pipe
variable is plugged in.)

That this happens is not libtool's fault, it's generally caused by a
misconfigured nm. However, I believe it would lead to fewer headaches for
libtool users if configure aborted with an explanation, or the libtool
script itself was more robust to the empty variable and didn't try to pipe
nm output through nothing.

Regards,
-- 
Philip

[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.