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

Nolo Ogbirner edited comment on ARROW-9533 at 7/24/20, 1:12 PM:
----------------------------------------------------------------

[~kou] Under usage  
[https://github.com/apache/arrow/blob/maint-0.17.x/python/manylinux1/build_arrow.sh]
 there is the name of the image that fails. I understand the history now, 
thanks. The problem is that on 0.17.x if you don't specify LLVM 8 it pulls the 
latest version from the github release info of LLVM (which is 10) and then 
proceeds to fail, which means that the default arguments to the build fails 
which is quite confusing.

Yes, I understand that custom .whl is difficult to maintain and I would prefer 
not having to do this. I am planning to run my application in a serverless 
cloud application where I am limited to 250 MB of packages. I need Gandiva, 
pyarrow.csv and pyarrow.fs.S3FileSystem for my application. To my knowledge, 
there isn't a small whl that has all these components out right now?

Also, would you be able to point me to what flags dictate to not get a "no 
module named pyarrow.lib" error? Is there any documentation for this? It seems 
I can not import anything without getting this error.

Thanks for the help!


was (Author: lachrymatory):
[~kou] Under usage  
[https://github.com/apache/arrow/blob/maint-0.17.x/python/manylinux1/build_arrow.sh]
 there is the name of the image that fails. I understand the history now, 
thanks. The problem is that on 0.17.x if you don't specify LLVM 8 it pulls the 
latest version from the github release info of LLVM (which is 10) and then 
proceeds to fail, which means that the default arguments to the build fails 
which is quite confusing.

Yes, I understand that custom .whl is difficult to maintain and I would prefer 
not having to do this. I am planning to run my application in a serverless 
cloud application where I am limited to 250 MB of packages. I need Gandiva, 
pyarrow.csv and pyarrow.fs.S3FileSystem for my application. To my knowledge, 
there isn't a small whl that has all these components out right now?

Also, would you be able to point me to what flags dictate if I can use 
pyarrow.csv and not get a "no module named pyarrow.lib" error? Is there any 
documentation for this?

Thanks for the help!

> [Packaging][wheel] Could NOT Find LLVM_DIR Error when Building with Gandiva
> ---------------------------------------------------------------------------
>
>                 Key: ARROW-9533
>                 URL: https://issues.apache.org/jira/browse/ARROW-9533
>             Project: Apache Arrow
>          Issue Type: Bug
>          Components: C++ - Gandiva, Python
>    Affects Versions: 0.17.1
>            Reporter: Nolo Ogbirner
>            Priority: Major
>         Attachments: build_arrow.sh, error-build-with-llvmflag.txt, 
> error-log-build-docker.txt, errorlogbuild.txt
>
>
> The error mentioned in https://issues.apache.org/jira/browse/ARROW-3874 
> appears when trying to build with Gandiva on macOS, Amazon Linux and Ubuntu 
> 18.04. After running docker-compose run -e PYTHON_VERSION="3.7" 
> centos-python-manylinux1 I get the error
> {noformat}
> CMake Error at 
> /opt/_internal/cpython-3.7.6/lib/python3.7/site-packages/cmake/data/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
>  (message):
>   Could NOT find LLVMAlt (missing: LLVM_PACKAGE_VERSION CLANG_EXECUTABLE
>   LLVM_FOUND LLVM_LINK_EXECUTABLE)
>  Call Stack (most recent call first):
>   
> /opt/_internal/cpython-3.7.6/lib/python3.7/site-packages/cmake/data/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
>  (_FPHSA_FAILURE_MESSAGE)
>   cmake_modules/FindLLVMAlt.cmake:71 (find_package_handle_standard_args)
>   src/gandiva/CMakeLists.txt:28 (find_package)
> {noformat}
>  
> Attempting to set LLVM_DIR using export LLVM_DIR does not work. Also, setting 
> the -DLLVM_DIR flag for CMAKE by changing the build_arrow.sh file does not 
> seem to work either. Interesting to note is that there was a patch given for 
> a file called FindLLVM.cmake which does not exist and there is only 
> FindLLVMAlt.cmake now.
>  
>  



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

Reply via email to