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:




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.



David Lahn
DevOps Lead

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.