Re: ./libtool[1086]: eval: syntax error at line 1: `|' unexpected

On 31 March 2017 at 09:04, Jeffrey Walton wrote:
>>> The build fails with the following:
>>>
>>> gmake[2]: Entering directory `/export/home/build/libidn2-0.16'
>>> /bin/sh ./libtool  --tag=CC   --mode=link gcc -std=gnu99
>>> -fvisibility=hidden -m64 -version-info 1:4:1 -no-undefined
>>> -export-symbols-regex '^idn2_.*|_idn2_punycode_..code'  -o libidn2.la
>>> -rpath /usr/local/lib64 idna.lo lookup.lo register.lo bidi.lo
>>> version.lo error.lo punycode.lo free.lo data.lo tr46map.lo tables.lo
>>> context.lo -L/usr/local/lib64 -liconv -R/usr/local/lib64
>>> -L/usr/local/lib64 -lunistring -L/usr/local/lib64 -liconv -ldl
>>> -lpthread -R/usr/local/lib64 lib/libgnu.la -ldl -lpthread
>>> libtool: link: /bin/nm -p  .libs/idna.o .libs/lookup.o
>>> .libs/register.o .libs/bidi.o .libs/version.o .libs/error.o
>>> .libs/punycode.o .libs/free.o .libs/data.o .libs/tr46map.o
>>> .libs/tables.o .libs/context.o   lib/.libs/libgnu.a |  | /bin/gsed
>>> 's/.* //' | sort | uniq > .libs/libidn2.exp
>>> ./libtool[1086]: eval: syntax error at line 1: `|' unexpected
>>> gmake[2]: *** [libidn2.la] Error 3
>>>
>>> If I am parsing things correctly, the "unexpected |" is due to a
>>> missing command. Solaris is very Posixy, and I'm not sure which
>>> command may be running afoul.
>>>
>>> My questions are:
>>>
>>>   1. Is a command missing?
>>>   2. If so, which command is missing?
>>>   3. How do I fix the issue?
>>>
>>
>> It seems to me that `lt_cv_sys_global_symbol_pipe` somehow gets to be
>> empty and thus `$global_symbol_pipe` gets to be empty and thus the `|
>> |` happens. Can you post `config.log`?
>
> Thanks Václav.
>
> The log was kind of big so I placed it on Pastebin:
> https://pastebin.com/t95U9WjS.
>
> Would you like it in another form?
>
> Jeff

This is fine.

Bear in mind that I am not libtool developer so all of the following
is just my guessing:

As I have suspected: `lt_cv_sys_global_symbol_pipe=''`. I think that
there is a genuine issue in libtool that it does not handle empty
`lt_cv_sys_global_symbol_pipe` at all.

Looking further into config.log, it seems to me that this might be
related to this check:

~~~
configure:7765: checking command to parse /bin/nm -p output from gcc
-std=gnu99 object
configure:7885: gcc -std=gnu99 -c -g -O2  conftest.c >&5
configure:7888: $? = 0
configure:7892: /bin/nm -p conftest.o \| sed -n -e 's/^.*[
]\([BDRT][BDRT]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed
'/ __gnu_lto/d' \> conftest.nm
configure:7895: $? = 0
cannot find nm_test_var in conftest.nm
configure:7885: gcc -std=gnu99 -c -g -O2  conftest.c >&5
configure:7888: $? = 0
configure:7892: /bin/nm -p conftest.o \| sed -n -e 's/^.*[
]\([BDRT][BDRT]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' |
sed '/ __gnu_lto/d' \> conftest.nm
configure:7895: $? = 0
cannot run sed -n -e 's/^.*[     ]\([BDRT][BDRT]*\)[     ][
]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | sed '/ __gnu_lto/d'
configure:7999: result: failed
~~~

The libtool tests are trying to run using plain `sed` instead of the
configured `$SED`. Dunno if that is the issue but bad `sed` might be a
problem, too.

Also, I see your `SHELL=/bin/sh`. What shell is that? I would suggest
running with `SHELL` set to something modern like Bash.

This also appears to have already been reported in the past:
https://lists.gnu.org/archive/html/bug-libtool/2015-07/msg00000.html

So, my recommendation is to run again under Bash with `SHELL` set to
it. If that still fails, try telling it to use GNU nm by providing
NM=/path/to/gnm on `configure` command line.

-- 
VH

_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool