OS: macos with brew
Ruby version manager: rbenv
I am using bundler (2.1.4) to deploy my application with all the required gems.
I am currently on Ruby 2.2.4 and trying to update to Ruby 2.5.5. I am also updating the various gems to the latest versions.
I am having an issue with bundler introducing a dependency for compiled extensions on libruby.2.5.dylib. This library is in the local .rbenv folder in the local user's folder. This is causing the application to fail when it is launched on other users' machines because of course this file is not available.
Interestingly this was not happening with the previous version of Ruby (2.2.4). If you take sqlite3, for example, I have the following.
Ruby 2.2.4 and sqlite-ruby 1.3.13
otool -L /Users/dev-user/dev/MCTools/src/mct-tools/ext/gems/ruby/2.2.0/extensions/x86_64-darwin-19/2.2.0-static/sqlite3-1.3.13/sqlite3/sqlite3_native.bundle
/Users/dev-user/dev/MCTools/src/mct-tools/ext/gems/ruby/2.2.0/extensions/x86_64-darwin-19/2.2.0-static/sqlite3-1.3.13/sqlite3/sqlite3_native.bundle:
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 308.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
Ruby 2.5.5 and sqlite-ruby 1.4.2
otool -L /Users/dev-user/dev/MCTools/src/mct-tools/ext/gems/ruby/2.5.0/extensions/x86_64-darwin-19/2.5.0/sqlite3-1.4.2/sqlite3/sqlite3_native.bundle
/Users/dev-user/dev/MCTools/src/mct-tools/ext/gems/ruby/2.5.0/extensions/x86_64-darwin-19/2.5.0/sqlite3-1.4.2/sqlite3/sqlite3_native.bundle:
/Users/dev-user/.rbenv/versions/2.5.5/lib/libruby.2.5.dylib (compatibility version 2.5.0, current version 2.5.5)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 308.5.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
As you can see, there is now a dependency on
/Users/dev-user/.rbenv/versions/2.5.5/lib/libruby.2.5.dylib (compatibility version 2.5.0, current version 2.5.5)
that of course it is not available on other machines. This behaviour is common to all compiled gems (I have 5 of them).
I was hoping that bundle package would help, but I have the same results if I run it before bundle install.
Any idea on how I can remove this dependency or any other alternative solution?
When you compile Ruby you can pass --enable-load-relative flag to ./configure to remove (some?) of the absolute paths from compiled binaries. This might affect extensions also.
Related
I am trying to build a minimal easily transportable Ruby without relying on external projects, just for my own learning process.
I am using otool -L ruby to determine what libraries the Ruby binary is dynamically linking against as I am trying to minimize it.
Yesterday when i built Ruby it only dynamically linked against 3 libraries, however today when i build Ruby it is linking against 13. I have no idea what has changed between yesterday and today but I am thoroughly confused -- especially as many of the libraries it is linking against existed prior to yesterday's compilation.
On Yesterday's Ruby executable the result of otool -L was:
otool -L ruby
ruby:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.8.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 489.0.0)
But today it is:
otool -L ./ruby
./ruby:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.8.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
/usr/lib/libffi.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/gdbm/lib/libgdbm.4.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 489.0.0)
Does anyone know what is going on?
I am compiling Ruby 2.4.2 like so:
X="-arch i386 -mmacosx-version-min=10.5"
CFLAGS="$X" CXXFLAGS="$X" LDFLAGS="$X" ./configure --prefix=/tmp/ruby-deploy --with-openssl-dir=$(brew --prefix openssl) --disable-install-doc --without-gmp
The answer to this was that I had also run:
CFLAGS="$X" CXXFLAGS="$X" LDFLAGS="$X" ./configure --prefix=/tmp/ruby-deploy --with-openssl-dir=$(brew --prefix openssl) --with-static-linked-ext --disable-install-doc --without-gmp
at one point -- note the --with-static-linked-ext. This resulted in the other dynamically linked libs.
However because i had subsequently run ./configure again WITHOUT that option i assumed it would have reset the configuration, but it didn't.
I discovered the problem by wiping out the Ruby source folder and re-fetching from github. Running the initial ./configure (excluding the --with-static-linked-ext resolved the issue!
I'm afraid I have made a mess with the version (0.9.8zg) of OpenSSL which was installed on my Mac. While I was trying to update it, now I have some error and for some reasons applications like Apache or Google Drive do not work anymore and they don't even start.
I would like to know which would be the best way to restore openssl to a working version without re-installing the whole operating system.
How can I do that?
Up to know I have tried to download openssl-0.9.8zg and build it with ./config, make and make install but it did not solve the problem.
Please help me if possibile
Some command outputs:
$ file /usr/lib/libssl.0.9.8.dylib` --> `/usr/lib/libssl.0.9.8.dylib: Mach-O 64-bit dynamically linked shared library x86_64`
$ otool -L /usr/lib/libssl.0.9.8.dylib`--> `/usr/lib/libssl.0.9.8.dylib:
/usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/Cellar/openssl/1.0.2d_1/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)`
The output of nm /usr/lib/libssl.0.9.8.dylib is here.
I am running a homebrew version of python on OSX 10.9: Maverick.
Short version:
I am experiencing a Python segmentation fault 11 when I try to import an OpenNI module into python. I have tried renaming my readline.so file as suggested in the link below, so I am assuming this is a different problem:
Python crashing when running two commands (Segmentation Fault: 11)
I am wondering if this might be an issue with my homebrew boost install not linking to the correct version of python. Though I cannot seem to fix it and very well may be barking up the wrong tree.
Very long version:
I've been trying to to install the PyOpenNI python module following directions from this site:
http://www.justinfx.com/2012/06/21/getting-started-with-xbox-360-kinect-on-osx/
Instead of manually installing OpenNI, NITE, and the Sensor Kinect drivers as specified on that link, I used brew versions I found here:
https://github.com/totakke/homebrew-openni
Everything seems to have worked fine until I reached the last step, installing PyOpenNI. I ran into a CMake error when creating the make file; it did not find the OpenNI library and include directories. I manually put these in the CMakeCache.txt file and installation seemed to work fine after that.
Once I tried to to import the openni module in a python shell, I got:
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6
Googling this for a bit, some people suggested it was a Boost error, having installed to the Mac build of Python instead of the Homebrew version.
Homebrew + Python on mac os x 10.8: Fatal Python error: PyThreadState_Get: no current thread importing mapnik
Running otool -L $(brew list boost | grep 'python.*.dylib') output suggested this was the case:
Line of interest:
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.5)
Full output:
/usr/local/Cellar/boost/1.55.0/lib/libboost_python-mt.dylib:
/usr/local/lib/libboost_python-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/usr/local/Cellar/boost/1.55.0/lib/libboost_python.dylib:
/usr/local/lib/libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
I uninstalled boost and reinstalled it with brew install boost --build-from-source
Funny thing is, after installing, it gave this warning:
The Boost bottle's module will not import into a Homebrew-installed Python.
If you use the Boost Python module then please:
brew install boost --build-from-source
which is obviously funny since I just did that. Running otool again:
Line of interest:
/usr/local/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
Full output:
/usr/local/Cellar/boost/1.55.0/lib/libboost_python-mt.dylib:
/usr/local/lib/libboost_python-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/usr/local/Cellar/boost/1.55.0/lib/libboost_python.dylib:
/usr/local/lib/libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
So now it seems to point to a different python framework directory, but seems like it is still not the Homebrew python framework directory.
Am I correct in this assessment that boost is still not linking to the homebrew version of python? Could this be causing the Segmentation fault 11, or is that caused by something else entirely?
I know the answer is late but it might be helpful to someone as it was to me. Apparently the solution to this was posted by akakcolin as an answer to one of the issues related to PyOpenNI on Github.
Rebuild homebrew Python:
brew update then brew doctor
brew rm python
brew install python --force --install-lib --install-headers --install-data --verbose
Symlink:
ln -s /usr/local/Cellar/python/2.7.x/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib /usr/local/lib/ (pay attention to the version of python you are using)
cmake and make:
cmake ../PyOpenNI you might have to specify -D OPENNI_INCLUDE_DIR
make
This worked for me with Python 2.7.10 and boost (with boost-python) 1.58.0
I'm building qt 5 from source. I'm wondering what is the easiest way to copy-paste qt binaries under MacOS. If you run otool on any of the qt frameworks you'll see that all the dependencies are using absolute paths:
bash-3.2$ otool -L QtWidgets
QtWidgets:
/Users/../Qt/qt5/qtbase/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.1.0, current version 5.1.1)
/Users/../Qt/qt5/qtbase/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.1.0, current version 5.1.1)
/Users/../Qt/qt5/qtbase/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.1.0, current version 5.1.1)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 155.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 19.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 65.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.18.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 945.16.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 45.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1187.37.0)
When I copy qt binaries and link my application against that copy, it works but some dependent frameworks are taken from the old place. The things become even worse when I try to move the binaries to another machine. I know that the problems can be fixed using install_name_tool but it's a lot of error-prone manual work. I'm wondering if there is a script which could help me in that?
After a long search on the Internet. I discovered that Qt Installer Framework has necessary code to patch relocated Qt binaries under Mac OSX. There was small problem to run that code, it's written in C++ that was not that easy to compile since it depends on Qt4 while I'm using Qt5.1. Fortunately, it turned out that all the operations are available via command line.
To use that commands you need any installer created with Qt Installer Framework (Qt binary installer for Mac OSX is good enough) and to use the command below:
./qt-mac-opensource-5.1.0-clang-offline.app/Contents/MacOS/qt-mac-opensource-5.1.0-clang-offline --runoperation "QtPatch" "mac"
"/Path/to/Qt/binaries/which/need/to/be/patched" "qt5"
========================================
Operation was successfully performed.
In case you get an error message which says "qmake is not a program" or something like that try to chmod qmake:
chmod 777 qmake
Note: this works with any QtIFW installer. Play around with prebuilt version of QtIFW
OK, that's it, that's the most straight forward way I found so far.
If you are building QT5 from source anyways then static linking will solve some of your headaches.
The original link listed broke.
To build QT statically add -static to the arguments when you run ./configure e.g.
./configure -prefix /Developer/qt -qt-zlib -qt-libpng -qt-libjpeg -universal -sdk /Developer/SDKs/MacOSX10.4u.sdk -static -release
Compile with: make sub-src
Install with: sudo make install
I'm trying to compile a version of convert (one of the ImageMagick tools) for distribution with a Cocoa app I'm writing, and I've mistakenly bundled a version that relies on shared libraries my users don't have (twice, already). Thus, I'm trying to pare down the list. After stripping out everything I didn't need, running otool -L convert gives me the following list:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
and for another tool bundled with the same app, I'm also using:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
Is it safe to assume that any out-of-the-box installation of Leopard or above will have these libraries on board? (More generally, my google-fu has failed me, so if anyone can point me to a resource that would answer these questions for me, I'd be eternally grateful!)
If the library path is /usr/lib, it should be available on a vanilla OS X of the level you're running on (and presumably above). Third-party apps and installers should not be installing into /usr/lib.
Yes, on my Snow Leopard box that has no changes to /usr/lib, all of these libraries exist