[ 
https://issues.apache.org/jira/browse/ARROW-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964070#comment-16964070
 ] 

Christian Hudon commented on ARROW-7033:
----------------------------------------

Yes. Confirming that the C++ build works with that SDKROOT export.

The two questions for me are: 1) was my environment broken in some weird way 
for the initial build to fail like this, and, if not 2) what's the best way to 
fix things so that they "just work"?

> [C++] Error in./configure step for jemalloc when building on OSX 10.14.6
> ------------------------------------------------------------------------
>
>                 Key: ARROW-7033
>                 URL: https://issues.apache.org/jira/browse/ARROW-7033
>             Project: Apache Arrow
>          Issue Type: Bug
>          Components: C++
>            Reporter: Christian Hudon
>            Priority: Major
>
> Hello. I'm trying to build the C++ part of Apache Arrow (as a first step to 
> possible contributions). I'm following the C++ Development instructions, but 
> running into an error early. I also looked at ARROW-4935, but the cause there 
> seems different, so I'm opening a new bug report.
> I'm on MacOS 10.14.6. I have the XCode cli tools installed (via 
> xcode-select), and installed the other dependencies with Homebrew, giving it 
> the cpp/Brewfile. I want to be able to run the tests, so I'm configuring a 
> debug build with:
>   cmake -DCMAKE_BUILD_TYPE=Debug -DARROW_BUILD_TESTS=ON ..
> from an out-of-source build, in a cpp/debug directory. Then, running make, I 
> get very quickly the following error:
> {{$ make}}
> {{[ 0%] Performing configure step for 'jemalloc_ep'}}
> {{CMake Error at 
> /Users/chrish/Code/arrow/cpp/debug/jemalloc_ep-prefix/src/jemalloc_ep-stamp/jemalloc_ep-configure-DEBUG.cmake:49
>  (message):}}
> {{ Command failed: 1}}{{'./configure' 
> 'AR=/Library/Developer/CommandLineTools/usr/bin/ar' 
> 'CC=/Library/Developer/CommandLineTools/usr/bin/cc' 
> '--prefix=/Users/chrish/Code/arrow/cpp/debug/jemalloc_ep-prefix/src/jemalloc_ep/dist/'
>  '--with-jemalloc-prefix=je_arrow_' 
> '--with-private-namespace=je_arrow_private_' '--without-export' 
> '--disable-cxx' '--disable-libdl' '--disable-initial-exec-tls'}}{{See 
> also}}{{/Users/chrish/Code/arrow/cpp/debug/jemalloc_ep-prefix/src/jemalloc_ep-stamp/jemalloc_ep-configure-*.log}}
> {{make[2]: *** 
> [jemalloc_ep-prefix/src/jemalloc_ep-stamp/jemalloc_ep-configure] Error 1}}
> {{make[1]: *** [CMakeFiles/jemalloc_ep.dir/all] Error 2}}
> {{make: *** [all] Error 2}}
> {{Looking into the log file as suggested, I see:}}
> configure: error: in 
> `/Users/chrish/Code/arrow/cpp/debug/jemalloc_ep-prefix/src/jemalloc_ep':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details 
> ... which seems a bit suspicuous. Running the ./configure invocation 
> manually, I get the same error:
> {{$ './configure' 'AR=/Library/Developer/CommandLineTools/usr/bin/ar' 
> 'CC=/Library/Developer/CommandLineTools/usr/bin/cc' 
> '--prefix=/Users/chrish/Code/arrow/cpp/debug/jemalloc_ep-prefix/src/jemalloc_ep/dist/'
>  '--with-jemalloc-prefix=je_arrow_' 
> '--with-private-namespace=je_arrow_private_' '--without-export' 
> '--disable-cxx' '--disable-libdl' '--disable-initial-exec-tls'}}
> {{checking for xsltproc... /usr/bin/xsltproc}}
> {{checking for gcc... /Library/Developer/CommandLineTools/usr/bin/cc}}
> {{checking whether the C compiler works... yes}}
> {{checking for C compiler default output file name... a.out}}
> {{checking for suffix of executables...}}
> {{checking whether we are cross compiling... configure: error: in 
> `/Users/chrish/Code/arrow/cpp/debug/jemalloc_ep-prefix/src/jemalloc_ep':}}
> {{configure: error: cannot run C compiled programs.}}
> {{If you meant to cross compile, use `--host'.}}
> {{See `config.log' for more details}}{{}}
> {{Digging into config.log, I see:}}
> configure:3213: checking whether we are cross compiling
> *configure:3221: /Library/Developer/CommandLineTools/usr/bin/cc -o conftest 
> conftest.c >&5*
> *conftest.c:9:10: fatal error: 'stdio.h' file not found*
> #include <stdio.h>
>  ^~~~~~~~~
> 1 error generated.
> configure:3225: $? = 1
> configure:3232: ./conftest
> ./configure: line 3234: ./conftest: No such file or directory
> configure:3236: $? = 127
> configure:3243: error: in 
> `/Users/chrish/Code/arrow/cpp/debug/jemalloc_ep-prefix/src/jemalloc_ep':
> configure:3245: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> (Relevant bit in bold.) Well, that would make more sense, at least. I create 
> a close-enough conftest.c by hand:
> {{#include <stdio.h>}}
> {{int main(void) \{ return 0; }}}
> and try to compile it with the same command-line invocation:
> {{$  /Library/Developer/CommandLineTools/usr/bin/cc -o conftest conftest.c}}
> {{I get that same error:}}
> conftest.c:1:10: fatal error: 'stdio.h' file not found
> #include <stdio.h>
>  ^~~~~~~~~
> 1 error generated.
> However, I also have a cc in /usr/bin. If I try that one instead, things 
> works:
> {{$ /usr/bin/cc -o conftest conftest.c}}
> {{$ ls -l conftest}}
> {{-rwxr-xr-x 1 chrish staff 4,2K oct 30 16:03 conftest*}}
> {{$ ./conftest}}
> {{(No error compiling or running conftest.c)}}
> The two executable seem to be the same compiler (or at least the exact same 
> version):
> {{$ /usr/bin/cc --version
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin}}
> {{$ /Library/Developer/CommandLineTools/usr/bin/cc --version
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.7.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin}}{{}}
> So... I guess at least for me, Apple's Clang works correctly only if invoked 
> from the /usr/bin path. Any reason why the configure, etc. scripts make a 
> special effort to invoke it from /Library/Developer/CommandLineTools/usr/bin, 
> if it's also available in /usr/bin (which is even in the path by default). 
> How do I fix this, so others don't run into that problem too? Thanks!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to