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.
Related
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?
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.
After trying to build the latest MonoDevelop (MD) 3 like this ==>, I ran into some problems which I won't go into in this post, since right now I just want to get my original development environment back which was MD 2.8.8.4.
In trying to do my building I got the impression (likely after looking some things up on the internet) that I needed a more recent version of MDK, so I downloaded and installed MDK 2.10.10. After some struggle, I decided I'd give up (late at night) and I uninstalled my original MD 2.8.8.4, and cleaned out the trash, and of course I don't keep installer files around long on my Mac because I don't have a lot of extra space.
Ok, sorry about that detour! When I tried to reinstall MD 2.8.8.4, the application didn't launch, and I couldn't figure out why. I think it is related to libraries that it couldn't find. I tried to run some of my mono programs that worked before I started fooling around and lo and behold they couldn't find I think it was "glibsharpglue", so I did some hunting and found this, which agreed with my findings, but I couldn't quite work out what to do. I also found something on the internet which indicated that maybe my MRE install was hatched. That agreed with my recollection of not having too much trouble installing MD and dependencies the first time. I don't remember having to do any work with configuring where libraries were located in order for things to run. Hmm. Anyway, I thought I'd back off and try an earlier download (Documentation is still very sparse -or I can't seem to find it anyway- about what dependencies / versions system-wise, or even toolkit-wise (MRE, or MDK) are required to run a given version of MD.).
So, long story short, I downloaded MRE 2.10_5 which I found in the archives here. After uninstalling 2.10.10, I installed 2.10_5, and lo and behold my previous mono applications that I have made worked fine! So then I thought, "great, now I can get my MD environment working fine". Ha! When I installed MD 2.8.8.4, after of course, installing the MDK (2.10_5), a notice popped up nicely telling me that I needed a minimum MRE of 2.10.4. Ok, so back to the uninstall, download, re-install process only to find that the MRE does not seem to know where the libraries are again, and my programs don't run, so I didn't even bother with trying to install any further. Then, I had a brilliant idea to install MRE / MDK 3.0.2 (the latest)... figuring that this should install nicely and "you'd think it might know where the libraries are". Ah, but how wrong was I. After I installed this version and tried to run my programs, it gave an error like "dyld: unknown required load command 0x80000022 Trace/BPT trap". After looking this up, I discovered that I need Snow Leopard or >, (10.6 +).
Now my question is, what version of MRE, and MDK can I use on my system that properly sets up library referencing and that works on Mac (OSX 10.5.8), so that I can get back my original development system MonoDevelop 2.8.8.4? Or, if no one knows that, what do I need to let MRE/MDK know where the libraries are?
CHEERS
Ok, here's what worked to get me back. I decided I'd even downgrade my MD so I could get something working. Well, neither 2.8.6.5 nor MD 2.8.4.2 would work with MRE 2.10_5, so then I went back to older versions of MRE/MDK. I discovered that MRE 2.10.6_1 allowed my mono programs to run (it knew where to look for libraries), then I downloaded and installed MDK 2.10.6_1 and tried to run my mono programs ... ah failed to find libraries. So I thought maybe I'll go ahead and install the MRE again. And it my programs worked. Then I installed and ran MD 2.8.8.4, and it worked! So this appears to be what is needed to get MD 2.8.8.4 working on a Mac OSX 10.5.8: step 1) install MDK 2.10.6_1 2) install MRE 2.10.6_1 3) install MD 2.8.8.4
Does it have to be that complicated?
Are there other solutions (probably, but I've got what I need right now).
CHEERS!
I guess I'm a sucker for punishment. After I got everything working I thought, "now let's just try MRE 2.10.10 again ... and after installing it, again, my mono programs don't work. So, I uninstalled that, and got back to the above so I could do my work in MD 2.8.8.4 which appears to be the latest version I can run without stepping through the "dependency or library" issues in building my own. (It kind of reminds me of dependency "fun" I had when building X10 (or was is X11?) and Gnome back in 2000 or so with my slackware box.)
I'm wrote an application and I need to execute it on Gentoo,
but when I try run it, I get the following message:
/lib/libc.so.6: version `GLIBC_2.3.4' not found (required by /usr/local/myapp/lib/myapplib.so.1)
the current GLIBC version in this gentoo is 2.3.2.
I can't update this glibc, because I don't have permission, so I need to 'downgrade'
my glibc to the same version (2.3.2) ... how can I do it?
tks,
The "/lib/libc.so.6: version `GLIBC_2.3.4' not found" problem comes from trying to run a binary compiled against a newer glibc on a system with an old version of glibc. Downgrading glibc is strongly discouraged for this reason.
Since you say you wrote the application, it seems to me that the simplest solution is to recompile the application on the system where you plan to run it.
I'm actually wrestling with the same issue, so maybe I have some information that can help.
In short, your binary was compiled to look for libc.so.6. GLIBC_2.3.4 is in libc.so.5. As far as I know, if you downgrade your glibc on your dev machine some of your other programs may not work properly (because they were compiled to look for the current version). Somehow CentOS/RHEL have a compat-glibc package that can live along side of a current glibc without causing this error. If your dev box uses CentOS/RHEL, install that package/recompile and you should be good to go. You may need to use an older compiler for it to look for the older library. If you're not developing on CentOS/RHEL, continue on.
My plan of attack today is to compile glibc from source. This means using a compiler that was released around the same time as the older version of glibc. You may run into some stumbling blocks (such as needing an older version of buildutils, etc.), but my hope is once the libc.so.5 is compiled and installed into /usr/local/lib my application will find that before it finds libc.so.6 in /lib.
So there it is. It's not for the faint of heart, and it's definitely not a quick solution. Today I plan on testing this out, so I can't really say it's the right solution. Please, hivemind.. if I'm flat-out wrong correct me and save this poor soul from this winding torturous road :-)
EDIT: link to glibc sources
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.