I had an issue building a gem on my Mac. To build a gem I needed to load an SSL library.
I found the answer right here but not quite like it was described. The answer said that I had to look for a folder
The library was built with homebrew and supposedly was in
/opt/homebrew/Cellar/openssl#1.1/1.1.1n/ Notice the weird n at the end?
Another comment said that it almost worked for him except
/opt/homebrew/Cellar/openssl#1.1/1.1.1q/
And in my case it was
/opt/homebrew/Cellar/openssl#1.1/1.1.1q/
It looked pretty weird for me. Is this a kind of internal versioning system from homebrew?
Related
I wanted to install caffe on openSuse.
Just for the record - it worked out for me, I just don't know what's the "exact" way to do this. The things I did maybe aren't really for someone who's new to this, and also it was kind of a "bad installation". My way was the following:
First, I did
make all
This worked, until it complained that some libraries weren't found (libclbas etc.). So I used
ccmake .
to change the paths to the libraries manually. I needed to manually type the paths to the snappy, boost_python, blas, cblas and lapack libs. After doing that I did
cmake .
and then
make
and everything worked. My problem now is - why doesn't make find the libs, and is there a way to fix this? I think the problem was that I didn't have /usr/lib/libcblas.so but /usr/lib/libcblas.so.3, and similar "problems" with the other libraries.
Another thing - when I tried using ccmake/cmake right from the beginning (without the make part first), there weren't any files in my build directory (like $CAFFE_ROOT/build/examples or $CAFFE_ROOT/build/tools were empty), so the mnist tutorial for example wasn't working. That's why I first called
make all
, what may seem strange to you.
Of course I know how to fix this stuff, but I would like to know how the correct way for a "clean and simple installation" is. Did is miss anything when using make/cmake, is this some kind of inconsistency in caffe or something else? And, what is the clean way to do this?
Maybe look at the Ubuntu installation guide? http://caffe.berkeleyvision.org/install_apt.html
It mentions all the different packages you might need. I couldn't find openSuse installation instructions - but you should be able to translate the apt-get commands for your platform.
So, I'm trying to add this library in an xcode project.
http://nuclear.mutantstargoat.com/sw/libdrawtext/
I used homebrew to install the library. It's now in /usr/local/Cellar/libdrawtext/
But, even after adding the dylib that is created in /usr/local/Cellar/libdrawtext/0.1/
I checked, and there's even an alias in the usr/local/bin folder.
But for the life of me, I can't seem to be able to include "drawtext.h" in my project.
The sample code here has no indication of how to do this.
Ideas, anyone?
Fixed it. Not sure exactly how, but I followed this tutorial http://mac-dev-env.patrickbougie.com/freetype/
After adding libdrawtext(from the homebrew installation), I also added the source of the library to my project. Works like a charm, though this is a VERY dirty solution.
I'll wait 24 hours, and if there're any better answers, I'll mark them correct.
I just installed homebrew and saw a message from the install script that said I should consider removing the following "evil" dylibs as they might break builds. Has anyone done this? And if so, did you later find out that you actually needed them?
Here's the dylib list:
/usr/local/lib/CHBrowserView.dylib
/usr/local/lib/libgnsdk_musicid_file.dylib
/usr/local/lib/libgnsdk_sdkmanager.dylib
/usr/local/lib/libjson.0.0.1.dylib
/usr/local/lib/libmusicid_osx.dylib
/usr/local/lib/libpcre.0.0.1.dylib
/usr/local/lib/libpcrecpp.0.0.0.dylib
/usr/local/lib/libpcreposix.0.0.0.dylib
NO. If you have something in /usr/local/lib, in all likelihood its because you built it and installed it.
It's an annoying and egotistical error message for Brew to assume that any libraries in /usr/local/lib are 'evil' simply because Brew doesn't know about them.
It is possible that you might have an 'older' version that conflicts with something Brew builds, but.. guh. It'll be painfully obvious when the program dies. And more likely than not if the application tries to dyload it, it also means that when Brew is building things it'll try to link against the old lib anyway. As long as it's arch / version compatible it's no biggie.
It'll also be painfully obvious when something you built pre-Brew can't find the shared library you removed. And given that you may not have the source laying around (or remember how you configured it in the first place..)
I strongly suggest keeping the old libraries around.
I just updated my Linux box from Debian Lenny to Debian Squeeze, and now when I use Nokogiri, I get a warning message:
WARNING: Nokogiri was built against LibXML version 2.6.32, but has dynamically loaded 2.7.8
I know I can eliminate the warning message by reinstalling Nokogiri, but for now I don't want to do that because the gem is in an NFS directory shared with machines that haven't been upgraded yet. I'll upgrade them all eventually, but for now I want to know: does this warning indicate that Nokogiri will behave incorrectly on the Squeeze system, or may I safely ignore it for the time being?
It should work OK, it's just telling you there's a conflict between the versions.
The developers are interested in the users of the gem having a good experience, so they let us know when there are things going on with the system that we should know about.
It's better to have the visual noise and know what it's about, then to have the situation hidden completely and be surprised if something bad were to happen.
You might want to run some unit test code on that particular machine that exercises Nokogiri to confirm. There's always a possibility Nokogiri will try to use a call that changed or didn't exist in one of the versions of LibXML2, so you should confirm that.
If you want more information about possible issues it could have then the Nokogiri-Talk mail list is a good source. The developers monitor it and can answer any questions you have.
In Mac OSX I had to pass the libraries dirs with:
gem install nokogiri -- --with-xml2-include=/usr/local/Cellar/libxml2/2.7.8/include --with-xml2-lib=/usr/local/Cellar/libxml2/2.7.8/lib --with-xslt-dir=/usr/local/Cellar/libxslt/1.1.26
Replace those dirs with your own after installing the development versions through apt or source.
I've got a ruby web app that uses lilypond to generate sheet music based on user input. I'd like to move the hosting to heroku (I've recently used heroku on a few projects and really liked it, plus my traffic is low enough that it'd be free host it on heroku, for a while at least). However, heroku's dyno architecture doesn't allow you to ssh in and install whatever packages you want...instead, you give it a gems manifest, and it will install the gems for you.
So, if I'm going to deploy to heroku, I'm going to need to package lilypond as a gem. I've released a few pure-ruby gems, but haven't dealt with native extensions or precompiled binaries, or anything like that.
Is it possible to take some precompiled binaries and package it inside a gem? Ideally, this would include binaries for OS X (which I develop on) and debian linux (which is what's running on heroku), and would install the proper binary when the gem was installed.
it is possible, since precompiled binary gems for windows are the norm. Take a look at rake compiler, perhaps.
also https://github.com/rdp/ruby_tutorials_core/wiki/gem (https://en.wikibooks.org/wiki/Ruby_Programming/RubyGems) might help
-r
I think you've got a few options here:
You could get the Lilypond source and package it into a gem with a native C extension. There are some useful guides on how to do that at http://guides.rubygems.org/c-extensions/ and http://patshaughnessy.net/2011/10/31/dont-be-terrified-of-building-native-extensions
There's also a gem called gitara but I haven't been able to find any information about using it on Heroku. It might be worth emailing the author and asking if he knows anything about that.
You could create a Heroku buildpack that installs Lilypond as part of your deployment. I wasn't able to find any for Lilypond, but there are plenty of examples that do similar things - for example, this one installs Imagemagick (which is included by default on Heroku, so probably not necessary anymore - but hopefully the code is helpful). More documentation at https://devcenter.heroku.com/articles/buildpack-api and https://devcenter.heroku.com/articles/buildpack-binaries
Based on my reading, I think the buildpack option is the best way to go.
Hopefully this helps!
Instead of precompiling, you should be able to just list the gem in your .gems file, see the Heroku documentation. Of course, this requires your gem builds the native code correctly - this is still a task, but hopefully an easier one.