arrow-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes McKinney <wesmck...@gmail.com>
Subject Re: Red-arrow Gem Hardcoding Paths in Compiled Library
Date Thu, 28 May 2020 18:50:17 GMT
hi David,

You may want to raise this on dev@arrow for more visibility or go
ahead and open a JIRA issue.

- Wes

On Thu, May 28, 2020 at 1:16 PM 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
>
> e: david.lahn@forwardpmx.com
> d: +44 (0)203 476 3725 (main office number)
> m: +1 519 573 1624
>
>
> 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