Bug #11913: make fails when using a custom build directory

• Status: Feedback
• Priority: Normal
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -
• ruby -v: 2.4.0dev
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN

[mcmire (Elliot Winkler)]

Hi there. I've been trying to submit a bugfix, and in doing so I realized that I had to compile Ruby so that I could run all of the tests. I made a fresh clone of Ruby, and started following the Contributing document, but then ran into some issues.

These instructions have you run ./configure from another directory (build) that is not the root directory of the repo. Unfortunately, running make did not seem to work, and here was the output:

± make
        CC = clang
        LD = ld
        LDSHARED = clang -dynamic -bundle
        CFLAGS = -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Werror=pointer-arith -Werror=write-strings
 -Werror=declaration-after-statement -Werror=shorten-64-to-32 -Werror=implicit-function-declaration -Werror=division-by-zero -Werror=deprecated-declarations -Werror=extra-tokens   -pipe
        XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT -fPIE
        CPPFLAGS = -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT   -I. -I.ext/include/x86_64-darwin15 -I../include -I..
        DLDFLAGS = -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -fstack-protector -Wl,-u,_objc_msgSend -Wl,-pie -framework CoreFoundation
        SOLIBS =
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.2.0
Thread model: posix
compiling ../main.c
compiling ../dmydln.c
compiling ../miniinit.c
compiling ../array.c
compiling ../bignum.c
compiling ../class.c
compiling ../compar.c
compiling ../complex.c
compiling ../dir.c
compiling ../dln_find.c
compiling ../encoding.c
compiling ../enum.c
compiling ../enumerator.c
compiling ../error.c
compiling ../eval.c
compiling ../load.c
compiling ../proc.c
compiling ../file.c
compiling ../gc.c
compiling ../hash.c
compiling ../inits.c
compiling ../io.c
compiling ../marshal.c
compiling ../math.c
compiling ../node.c
compiling ../numeric.c
compiling ../object.c
compiling ../pack.c
compiling ../parse.c
compiling ../process.c
compiling ../random.c
compiling ../range.c
compiling ../rational.c
compiling ../re.c
compiling ../regcomp.c
compiling ../regenc.c
compiling ../regerror.c
compiling ../regexec.c
compiling ../regparse.c
compiling ../regsyntax.c
compiling ../ruby.c
compiling ../safe.c
compiling ../signal.c
compiling ../sprintf.c
compiling ../st.c
compiling ../strftime.c
compiling ../string.c
compiling ../struct.c
compiling ../symbol.c
compiling ../time.c
compiling ../transcode.c
compiling ../util.c
compiling ../variable.c
compiling ../version.c
compiling ../compile.c
compiling ../debug.c
compiling ../iseq.c
compiling ../vm.c
compiling ../vm_dump.c
compiling ../vm_backtrace.c
compiling ../vm_trace.c
compiling ../thread.c
compiling ../cont.c
compiling ../enc/ascii.c
error: unable to open output file 'enc/ascii.o': 'No such file or directory'
1 error generated.
make: *** [enc/ascii.o] Error 1

make generated this error, as I found out, because build did not contain an enc directory.

So after running make clean, then mkdir -p enc/trans from within build (as it turns out, enc/trans also needed to be present), I then ran make again, and got this:

± make
        CC = clang
        LD = ld
        LDSHARED = clang -dynamic -bundle
        CFLAGS = -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Werror=pointer-arith -Werror=write-strings
 -Werror=declaration-after-statement -Werror=shorten-64-to-32 -Werror=implicit-function-declaration -Werror=division-by-zero -Werror=deprecated-declarations -Werror=extra-tokens   -pipe
        XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT -fPIE
        CPPFLAGS = -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT   -I. -I.ext/include/x86_64-darwin15 -I../include -I..
        DLDFLAGS = -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -fstack-protector -Wl,-u,_objc_msgSend -Wl,-pie -framework CoreFoundation
        SOLIBS =
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.2.0
Thread model: posix
compiling ../enc/trans/newline.c
compiling ../missing/explicit_bzero.c
compiling ../missing/setproctitle.c
linking miniruby
clang: error: no such file or directory: 'dmyext.o'
clang: error: no such file or directory: 'miniprelude.o'
make: *** [miniruby] Error 1

I didn't know what to do with this. dmyext.o and miniprelude.o are present within the repo, but for some reason, make wants them to be present within build.

After running ./configure from within the root directory, then make worked successfully.

So what I suppose is that there's something inside of the makefiles that still makes the assumption that make is going to be run inside of the root directory. But that's just a hunch.

[mcmire (Elliot Winkler)]

• Description updated (diff)

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned
• Assignee set to nobu (Nobuyoshi Nakada)

I can reproduce this.

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Feedback

Elliot Winkler wrote:

error: unable to open output file 'enc/ascii.o': 'No such file or directory'
1 error generated.
make: *** [enc/ascii.o] Error 1

This happens when enc/trans/.time file exists under the source
directory.

clang: error: no such file or directory: 'dmyext.o'
clang: error: no such file or directory: 'miniprelude.o'
make: *** [miniruby] Error 1

Seems like these object files exist in the source directory, too.

Have you build in the source directory, but didn't clean there?

[ioquatix (Samuel Williams)]

I ran into this problem, and I think it was because I had tried building in the root directory. I did make clean and it seems to solve this issue. I think we can close this issue, but it might be worth adding to the Contributing document.