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 <[email protected]> "Red-arrow Gem Hardcoding Paths in Compiled Library" on Thu, 28 May 2020 18:16:32 +0000, 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 > > > > > 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. >
