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 <[email protected]> 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: [email protected] > 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. >
