arrow-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sutou Kouhei <...@clear-code.com>
Subject Re: Red-arrow Gem Hardcoding Paths in Compiled Library
Date Thu, 28 May 2020 21:40:53 GMT
Hi,

This is a feature request for Ext++.
Could you open an issue on
https://github.com/red-data-tools/extpp/issues ?

Thanks,
--
kou

In <3ACCD3FD-19AD-429A-A7C8-2373CC23E63C@forwardpmx.com>
  "Red-arrow Gem Hardcoding Paths in Compiled Library" on Thu, 28 May 2020 18:16:32 +0000,
  David Lahn <david.lahn@forwardpmx.com> wrote:

> Hello,
> 
> We are noticing that when the red-arrow gem in Ruby is bundled, the resulting arrow.so
file has explicit paths for extpp, and thus, if the location changes (after a deployment),
those libraries can no longer be found:
> 
> Example:
> 
> bash-4.2# ldd bundle/ruby/2.7.0/gems/red-arrow-0.17.0/lib/arrow.so
>                 linux-vdso.so.1 (0x00007ffd703a4000)
>                 libruby.so.2.7 => /var/lang/lib/libruby.so.2.7 (0x00007f90ce6fe000)
>                 libarrow.so.17 => not found
>                 libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f90ce4ab000)
>                 libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f90ce195000)
>                 libarrow-glib.so.17 => not found
>                 /codebuild/output/src687471828/src/gsb/vendor/bundle/ruby/2.7.0/gems/extpp-0.0.8/ext/extpp/libruby-extpp.so
=> not found
>                 /codebuild/output/src687471828/src/gsb/vendor/bundle/ruby/2.7.0/gems/extpp-0.0.8/lib/libruby-extpp.so
=> not found
>                 libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f90cde13000)
>                 libm.so.6 => /lib64/libm.so.6 (0x00007f90cdad3000)
>                 libc.so.6 => /lib64/libc.so.6 (0x00007f90cd728000)
>                 libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f90cd512000)
>                 libz.so.1 => /lib64/libz.so.1 (0x00007f90cd2fd000)
>                 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f90cd0df000)
>                 librt.so.1 => /lib64/librt.so.1 (0x00007f90cced7000)
>                 libdl.so.2 => /lib64/libdl.so.2 (0x00007f90cccd3000)
>                 libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f90cca9c000)
>                 /lib64/ld-linux-x86-64.so.2 (0x00007f90ceec4000)
>                 libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f90cc838000)
>                 libffi.so.6 => /lib64/libffi.so.6 (0x00007f90cc630000)
> 
> Note that these have the full path.
> 
> Any ideas of how to avoid this? We are trying to get red-arrow working on AWS Lambda.
When we build, the directory has to change from where it currently is. The codebuild directory
being specified is something out of our control. When the code is deployed, it ends up in
/var/task. This is where vendor needs to be.
> 
> Dave
>     
> David Lahn
> DevOps Lead
> Development
>        
> ForwardPMX 
> Privacy Policy
> 
>  
>   
> 
> This e-mail is confidential to ForwardPMX intended for use by the recipient. If you received
this in error or are not the intended recipient, you are hereby notified that any review,
retransmission, copying or other use of, or taking of any action in reliance upon this information
is strictly prohibited.
> 

Mime
View raw message