0

I'm trying to build a C++ codebase. (The code happens to be Cap'n Proto 0.5.3, but I'm seeing this with other projects too.) I'm building with GCC in MinGW-w64 and running the build in MSYS2. GCC is 5.2.0. Make is 4.1.

I run Make, it goes along for a while. Then it stops because some command it tried to run failed with an error. OK fair enough. The error confuses me. I copy and paste the command from Make's output to the terminal, and try to run it manually, with no changes. I expect it to fail again in the same way, whereupon I will perhaps tinker with it to explore the problem... but it succeeds! (Well, I don't know anything about libtool... it produces its specified output file, anyway!)

Illustration of the actions described above:

MSYS /c/programmingstuff/capnproto-c++-0.5.3
$ make capnp.exe
C:/msys64/usr/bin/sh.exe ./libtool  --tag=CXX   --mode=link g++ -std=gnu++11 -I./src -I./src -DKJ_HEADER_WARNINGS -DCAPNP_HEADER_WARNINGS -DCAPNP_INCLUDE_DIR='"/usr/local/include"' -mthreads -static-libgcc -static-libstdc++ -mthreads -release 0.5.3 -no-undefined  -o libkj.la -rpath /usr/local/lib src/kj/common.lo src/kj/units.lo src/kj/memory.lo src/kj/refcount.lo src/kj/array.lo src/kj/string.lo src/kj/string-tree.lo src/kj/exception.lo src/kj/debug.lo src/kj/arena.lo src/kj/io.lo src/kj/mutex.lo src/kj/thread.lo src/kj/main.lo src/kj/parse/char.lo
libtool: link: you must specify an output file
libtool: link: Try `libtool --help --mode=link' for more information.
makefile:1405: recipe for target 'libkj.la' failed
make: *** [libkj.la] Error 1

MSYS /c/programmingstuff/capnproto-c++-0.5.3
$ C:/msys64/usr/bin/sh.exe ./libtool  --tag=CXX   --mode=link g++ -std=gnu++11 -I./src -I./src -DKJ_HEADER_WARNINGS -DCAPNP_HEADER_WARNINGS -DCAPNP_INCLUDE_DIR='"/usr/local/include"' -mthreads -static-libgcc -static-libstdc++ -mthreads -release 0.5.3 -no-undefined  -o libkj.la -rpath /usr/local/lib src/kj/common.lo src/kj/units.lo src/kj/memory.lo src/kj/refcount.lo src/kj/array.lo src/kj/string.lo src/kj/string-tree.lo src/kj/exception.lo src/kj/debug.lo src/kj/arena.lo src/kj/io.lo src/kj/mutex.lo src/kj/thread.lo src/kj/main.lo src/kj/parse/char.lo
libtool: link: ar cru .libs/libkj.a  src/kj/common.o src/kj/units.o src/kj/memory.o src/kj/refcount.o src/kj/array.o src/kj/string.o src/kj/string-tree.o src/kj/exception.o src/kj/debug.o src/kj/arena.o src/kj/io.o src/kj/mutex.o src/kj/thread.o src/kj/main.o src/kj/parse/char.o
libtool: link: ranlib .libs/libkj.a
libtool: link: ( cd ".libs" && rm -f "libkj.la" && cp -pR "../libkj.la" "libkj.la" )


After this I run Make again and it gets a little further, only to hang in this same way again. I copy and paste to kickstart it once more. This cycle repeats until either the project is fully built or a real error arises.

I don't think this is a problem with libtool; I've seen the same thing with several g++ commands while I was trying to build something else with this same setup. Maybe it's something wrong with Make or with my shell? I don't know.

How can I stop this from happening? Or, failing that--what's a good way to get further information about what IS happening? It perplexes me that the same command would fail when run by Make but succeed when run by me.

mjwach
  • 1,174
  • 2
  • 9
  • 25
  • Apparently `libtool` does not recognize the `-o libkj.la` option. Did you check your makefile against strange, non printable, characters? – Renaud Pacalet Oct 26 '15 at 11:54
  • No. I did just now, sort of. It's a huge automatically generated makefile so I just kinda poked around at the command that was failing and ignored the rest. Everything seemed fine, but no matter how I massaged it, the command still failed. Then I tried turning the c:/ in the sh.exe path to a /c/, and suddenly the command worked. It's a stupid Windows-UNIX file path style discrepancy at the root of this, I guess. One of the various programs in my processing chain was introducing the c:/, and another was choking on it... or something like that. – mjwach Oct 27 '15 at 05:29

1 Answers1

0

Now I have a stupid hacky answer that seems to have solved at least one instance of the problem, so I will post it here. It's way better than manually copying and pasting every failing command, anyway.

The problem in this instance seems to have been a Windows-UNIX file path discrepancy, where some of my UNIXy tools wanted paths to start with /c/ (or just /) and others were cool with paths starting with C:/. I don't know which tools in particular these were. I just know that this Makefile contained these lines:

LIBTOOL = $(SHELL) $(top_builddir)/libtool

...

SHELL = /bin/sh

which left $(LIBTOOL) expanding to

C:/msys64/usr/bin/sh.exe ./libtool

for whatever reason. Apparently the programs involved in my attempts to manually rerun the command (by pasting it into the terminal) were fine with the C:/, but at least one piece of the machinery working under Make was not fine with it. As a hack I changed the LIBTOOL line to this:

LIBTOOL = /bin/sh $(top_builddir)/libtool

and that fixed the problem. I'm mostly okay with that, though a more elegant solution would be preferable. And I expect that I'll have to manually figure out how to do something like this any other time this happens to me with this set of tools. :(

mjwach
  • 1,174
  • 2
  • 9
  • 25