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
