Strange build failure; something wrong with bash parsing?

quequotion · 2014-05-06 16:19:45

While trying to upgrade several packages, I've run into a rather obscure compilation error.

It looks like either something is wrong with the makefile or something is wrong with bash/autoconf/makepkg.

The package is: icu52 (a dependency of geary-git, I think*); something totally off the wall is being passed to the shell as a command (broken parsing?).

/bin/sh: line 2: @goods=: command not found

which occurs during:

make[1]: Making `all' in `cintltst'

If anyone has been able to successfully compile geary-git or icu52 (very) recently, please let me know if you found a workaround for these problems or never had them.

*geary-git fails to build with:

==> Updated version: geary-git r1698.b6cceac-1
==> Starting build()...
/usr/bin/ld: warning: libicuuc.so.52, needed by /usr/lib/libharfbuzz-icu.so.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libicudata.so.52, needed by /usr/lib/libharfbuzz-icu.so.0, not found (try using -rpath or -rpath-link)

However, neither geary-git nor harfbuzz-git have icu52 in (make)depends()...

EDIT: gtk3-git-ubuntu had an unrelated and now resolved issue; icu52 still fails to build.

Last edited by quequotion (2014-05-09 16:32:32)

quequotion · 2014-05-06 16:40:54

I did very thoroughly go over all makefiles in the relevant subdirectories, but I was unable to discern what could be wrong.

This error probably happens in:
icu/source/test/Makefile lines 77-109:

xcheck-recursive check-recursive check-exhaustive-recursive:
	@$(MKINSTALLDIRS) $(STATUS_TMP)
	@mystatus=$(STATUS_FULL)/status.$$$$.deleteme ; \
	$(RMV) "$$mystatus".* ; \
	@goods=; \
	bads=; \
	target=`echo $@ | sed s/-recursive//`; \
	list='$(SUBDIRS)'; for subdir in $$list; do \
	  echo "$(MAKE)[$(MAKELEVEL)]: Making \`$$target' in \`$$subdir'"; \
	  local_target="$$target"; \
	  if (cd $$subdir && $(MAKE) $$local_target TEST_STATUS_FILE="$$mystatus.$$subdir" ); then \
	    goods="$$goods $$subdir"; \
          else \
            bads="$$bads $$subdir"; \
          fi; \
	done; \
	for subdir in $$list; do \
	  if [ -f "$$mystatus.$$subdir" ]; then \
	    echo "-------------" ; \
	    echo "| ***     FAILING TEST SUMMARY FOR:              $$subdir  " ; \
	    cat "$$mystatus.$$subdir" ; \
	    echo "| *** END FAILING TEST SUMMARY FOR:              $$subdir" ; \
	    $(RMV) "$$mystatus.$$subdir" ; \
	  fi; \
	done; \
	echo "---------------"; \
	echo "ALL TESTS SUMMARY:"; \
        if test ! "x$$bads" = "x"; then \
	  echo "ok: $$goods"; \
	  echo "===== ERRS: $$bads"; exit 1; \
	else \
	  echo "All tests OK: $$goods"; \
	fi

Last edited by quequotion (2014-05-09 16:33:20)

quequotion · 2014-05-06 16:43:28

Never got gtk3-git to finish downloading, but resolved the problem with gtk3-git-ubuntu anyway (and assembled gtk2-git and gtk2-git-ubuntu while I was at it...)

Last edited by quequotion (2014-05-09 16:35:01)

Scimmia · 2014-05-06 16:56:02

-D_FORTIFY_SOURCE=2 is Arch's default CPPFLAGS. Probably a forgotten backslash somewhere that's trying to run it as a command instead of adding it to the gcc line.

ewaller · 2014-05-06 18:47:17

Just a sanity check. Verify using ls -l $(which sh)
that sh is an alias of bash.

Last edited by ewaller (2014-05-06 18:47:34)

quequotion · 2014-05-08 03:59:54

ewaller wrote:

Just a sanity check. Verify using ls -l $(which sh)
that sh is an alias of bash.

Verified, sh is bash.

\hbar · 2014-05-09 16:14:24

quequotion wrote:

	@mystatus=$(STATUS_FULL)/status.$$$$.deleteme ; \
	$(RMV) "$$mystatus".* ; \
	@goods=; \
	bads=; \

Isn't this the problem? It seems that bash can't deal with '@' in a variable name. This is not a problem if @ is at the beginning of a line because Make removes it before having bash parse it, but @goods is not at the beginning of the line, since there is a '\' at the end of the previous line.

My guess is that either the previous '\' is misplaced, or there should be no '@' before 'goods'.

Last edited by \hbar (2014-05-09 16:14:49)

quequotion · 2014-05-09 16:57:23

\hbar wrote:

quequotion wrote:
	@mystatus=$(STATUS_FULL)/status.$$$$.deleteme ; \
	$(RMV) "$$mystatus".* ; \
	@goods=; \
	bads=; \
Isn't this the problem? It seems that bash can't deal with '@' in a variable name. This is not a problem if @ is at the beginning of a line because Make removes it before having bash parse it, but @goods is not at the beginning of the line, since there is a '\' at the end of the previous line.
My guess is that either the previous '\' is misplaced, or there should be no '@' before 'goods'.

I tested without the @ first, since that would match the next line below, but build still fails:

      UObjectTest {
         testIDs {
         } OK:   testIDs  (19ms) 
         testUMemory {
         constructor used with placement new did not work right
Makefile:97: recipe for target 'check-local' failed
make[2]: *** [check-local] Segmentation fault (core dumped)
make[2]: Target 'check' not remade because of errors.

I'll try removing the '\' next. It also occurs to me that all the '\' may be out of place; is it necessary to have a '\' after a ';' ?

Another possibility is that removing the @ was the correct solution and now I have a different problem...

Last edited by quequotion (2014-05-09 16:58:34)

\hbar · 2014-05-09 17:41:34

The '\' are there in order to break the command over several lines (the newline character at the end of the line is escaped by the preceeding '\' character, so that make does not interpret it as a newline but bash does).

It does seem to be a problem with icu52 and not bash then, right?

Note that the error occurs during the testing phase, which you could bypass if you wanted to.

Last edited by \hbar (2014-05-09 17:42:10)

quequotion · 2014-05-09 18:19:17

\hbar wrote:

The '\' are there in order to break the command over several lines (the newline character at the end of the line is escaped by the preceeding '\' character, so that make does not interpret it as a newline but bash does).

Yes, and it was probably done to make the code more human-readable, but then the '\' all appear after a ';' which usually indicates end-of-line. Doesn't that make the slashes redundant?

It does seem to be a problem with icu52 and not bash then, right?

The problem is probably not in bash, but it's bash reporting the error, so I still can't rule out makepkg or autoconf feeding bash the wrong stuff. Hopefully, it's a problem with icu52, which would be easier to handle (I've already spent a day working the kinks out of my makepkg.conf).

Note that the error occurs during the testing phase, which you could bypass if you wanted to.

I'll see if I can get it to build without running the tests; although there's probably some reason not to casually skip them.

Edit: The package does build and install just fine without the testing phase, and even includes a handy ./configure option to do so... crossing fingers and proceeding to install geary-git.

Not ready to mark the thread as solved as the icu52 package still does not build from AUR and I still don't know how to fix it.

Last edited by quequotion (2014-05-09 18:29:34)

Arch Linux

#1 2014-05-06 16:19:45

Strange build failure; something wrong with bash parsing?

#2 2014-05-06 16:40:54

Re: Strange build failure; something wrong with bash parsing?

#3 2014-05-06 16:43:28

Re: Strange build failure; something wrong with bash parsing?

#4 2014-05-06 16:56:02

Re: Strange build failure; something wrong with bash parsing?

#5 2014-05-06 18:47:17

Re: Strange build failure; something wrong with bash parsing?

#6 2014-05-08 03:59:54

Re: Strange build failure; something wrong with bash parsing?

#7 2014-05-09 16:14:24

Re: Strange build failure; something wrong with bash parsing?

#8 2014-05-09 16:57:23

Re: Strange build failure; something wrong with bash parsing?

#9 2014-05-09 17:41:34

Re: Strange build failure; something wrong with bash parsing?

#10 2014-05-09 18:19:17

Re: Strange build failure; something wrong with bash parsing?

Board footer