I am trying to install ruby version manager on a g4 ibook running 10.4 but I receive two error messages right off the bat when I try to run the first command:
$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
bash: line 6: set: errtrace: invalid option name
bash: line 13: conditional binary operator expected
I am new to ruby, rails, and fairly inexperienced with the command line too. I've done a bit of searching and have seen other people having problems installing a specific version of ruby on a powerpc using rvm, but no other examples of someone having a problem installing rvm first of all.
Does this seem like a powerpc issue? Or is there something simple with the command line that I am missing here?
I have also searched on these specific error messages but haven't found any solutions yet. Oh and I should also add that I have xcode installed and I also installed macports because I thought that might help...but it hasn't.
The most probable cause of the error you're getting is your bash version is far too old to be used with any relatively new RVM version. Also, the likelihood of you being able to easily compile rubies on a G4 now is very low. You'll likely end up needing to compile many tools and libraries from source which you'll have to do from the command-line. Finding the right combination of library versions that both support your arch and are still available for download might not be as easy as it sounds. Much of the ruby compilation on OS X depends on libraries that come with Xcode. So, you might hit a wall there too with rubies now requiring newer libraries that can be provided with a version of Xcode that can be installed on your system.
You can try upgrading your bash version and/or use a much older version of RVM, although, I don't remember RVM ever working on 10.4. Or, you can try to compile everything from source, including Ruby. You'll might be able to get Ruby 1.8.6, maybe 1.8.7 working but anything higher is very unlikely.
Good luck =/
Related
I need to install SUMO 0.30.0 to be used with the VEINS_INET subproject in veins 4.6. I have tried following the instructions here and suggestions from forums but haven't had any luck being able to install sumo. I run ./configure (trying various tool/library options) then run sudo make but all I get is target marouter failed or nothing to be done for 'install-exec-am' 'install-data-am'.
Does anyone know how to install sumo-0.30.0 from source and/or make the veins_inet subproject work with the latest version of sumo-0.32.0?
Don't run sudo make.
Don't run sudo make.
Your problem is probably related to a dependency/packaging change in 16.04, which is explicitly pointed out in the veins tutorial:
Note that Ubuntu 16.04 no longer includes libproj0; this can be worked around by temporarily adding the packet repository of, e.g., Ubuntu Vivid when installing this package.
Short answer: Unfortunately this means that long-term, you're going to either have to package SUMO yourself, use the versions someone else compiled (see this launchpad for example) or rely on an old version.
Long answer:
In general, I would recommend building SUMO from source by building its' dependencies from source, since I've encountered this problem on various distributions. In particular, the fox, proj and gdal libraries tend to be packaged in different versions, and along with changes in the SUMO source code. I currently use this script (with the package versions downloaded) to compile SUMO -- but this is for 0.30.0, and it breaks if any of the referenced source packages are moved (which happens quite often). My general recommendation would be to either use a completely isolated version of SUMO (i.e., compiling by hand as much as possible) or relying on a pre-packaged version (see above), as long as that version is recent enough to work with VEINS.
I need to build the same set of shared objects (the OpenSSL support) for many platform and Perl version (4x4). Install works well with Perlbrew and I can install various packages with cpan on the different version I'v created. The problem is that they all fail with a PL_unitcheckav not found in DynLoader.pm
I've found lots of similar issues, but no solutione so far. Is this a debug symbol? It only fails when I add (cpan) a package from my brew install and then try to tun it on other system. It works fine when compile "natively" using my local Perl
Just found the answer. As #ikegami said, I was compiling w/o --multi, --64int and --thread and running it on a version with all these flags compiled (version number was correct). The "multi" option was really the problem
I'm trying to build emacs-25.1 from source on OSx. Everything goes fine until make install. When Emacs is trying to compile xml.c I get:
xml.c:23:10: fatal error: 'libxml/tree.h' file not found
#include <libxml/tree.h>
What is happening?
I'm not sure what your exact error is. However, there is an easier way to build emacs25 on OSX and macOS. Install homebrew is easy and once you have it, all you need to do is run
brew install emacs --with-cocoa --with-rsvg --with-ns
and then
brew linkapps emacs
and your done. Even if you want to do it by hand, you can get the recipe homebrew users to see how it does the build and install, which might help track down your error.
NOTE Check what the actual args are you can pass to the build environment. the ones I've listed are from memory and there are some others you may want to include.
A colleague was having the same problem and posted in the GNU emacs devel list right here. Daniel Suton provided the answer. Xcode is missing:
xcode-select --install
MacOS provides a libxml implementation (and headers) by default when you install xcode. Note that I had installed xcode already. But I've also upgraded from EL Captain to Sierra so my xcode installation must have been erased in the process.
Anyway, after installing xcode like described above and then after git clean -fxd I was able to rebuild emacs again.
I have a Perl module that handles localization tasks using the GNU gettext utilities xgettext, msgfmt, msginit, and msgmerge. I got some test failures from a SunOS system which, when I looked into it, seemed to be ancient. For now I am skipping tests when msgfmt and xgettext choke on a simple --version option. But I think it would be better to refuse to install unless a relatively modern version of the GNU Gettext utilities are installed.
So, what's the best way to do that? I'd like to just figure out what's installed and if it supports the options I need, and refuse to install the module if those dependencies are not met. Should I just run gettext --version and refuse to install if it exits with a non-0 value? Or might there be a more canonical solution?
Since "gettext --version" should always return a value on any "contemporary" version (for example, I just tried it on a circa 1997 Redhat ... and it worked!), that should be sufficient.
IMHO...
Im using sorl.thumbnail for django locally on my mac and have been having trouble with PIL, but today i finally managed to get it installed - was some trouble with libjpeg.
I can now upload and use images - but I cant resize them using sorl.thumbnail.
When i try i get the following error:
Wrong JPEG library version: library is 80, caller expects 62
Does anyone know a good solution for this.
I dont know wether whatever sorl uses requires an earlier version of libjpeg or wether there is some ghost install of something still left behind from all of my tries with various methods.
I have :
PIL 1.1.7
libjpeg 8.
anyone know an approach?
For the benefit of the people from the future who are encountering this error and don't know why, I'd like to post my findings. I hope to give a general understanding of what's gone wrong since the exact commands to fix it may be different on your machine than on my OSX Lion install.
First, since it's easy to get lost in the potential solutions, it's important to understand that the error message is correct when it says Wrong JPEG library version: library is 80, caller expects 62 or some other combination of 62, 70, and 80. These numbers correspond to the different incompatible versions of libjpeg. There are two moving pieces here, the dynamically loaded jpeg library, and the PIL (or Pillow) install. What the error message is saying is that your PIL install was compiled with headers from libjpeg version 6.2, but when it goes to load up the actual shared library, it's being linked to version 8.0.
The fix is to download, build, and install the libjpeg version you want (any will do, though the later versions build easier on OSX Lion):
wget http://www.ijg.org/files/jpegsrc.v8d.tar.gz
tar xzf jpegsrc*
cd jpeg-*
./configure
make
sudo make install
This should drop 2 files of note in '/usr/local/'. Namely /usr/local/lib/libjpeg.8.dylib and /usr/local/include/jpeglib.h. Now we just have to get PIL (or Pillow) to use these two files at install time, and we're home free. I know there's a better way to do this, but the hack (as recommended by the PIL docs) is to edit the setup.py file of the PIL distribution before you install it. You may get away with just setting JPEG_ROOT = libinclude('/usr/local') near the top of setup.py, though further directory manipulation may be necessary elsewhere in the file.
As you fiddle with the paths, you have to make sure PIL does a full rebuild before you test out whether it linked up to the right library or not. I used a command like rm -rf build && python setup.py install to make sure the library was always freshly linked to the current path I was testing.
I'm sorry this is a rambling answer, but it was very disheartening to have tried every other copy & paste solution out there and have none of them work. Hopefully this answer keeps at least a few folks from wasting numerous hours in search of a simplistic solution.
Good Luck!
If you have macports installed, you should do a:
$ sudo port selfupdate
$ sudo port install py27-pil
It's easier than the easy_install method since macports install the right dependencies.
I had a slightly different problem than the OP, but I wanted to share my solution here to help someone in the future.
OS: OSX El Capitan
I installed libjpeg-turbo from the precompiled binaries on their website. However, I did not know that I already had a different version of libjpeg installed on my mac. I was building my c file like this gcc myfile.c -o myfile.out -L /opt/libjpeg-turbo/lib -ljpeg. This got the library from the correct location, but the the linker was getting the included header file jpeglib.h from the pre-installed location. I changed my build command to this: gcc myfile.c -o myfile.out -I/opt/libjpeg-turbo/include/ -L /opt/libjpeg-turbo/lib -ljpeg and it worked. No more library is 80, caller expects 62!
Like a previous answer, I had a slightly different problem than the OP, but I wanted to share my solution here to help someone in the future.
The only thing that worked for me was forcing pip to build pillow from source after installing the dev version of the needed libraries (my code was editing a jpg and adding a label using a custom font). This was on a ARM based embedded device running Ubuntu Linux using Python 3.7.3
apt-get install -y libjpeg-dev libfreetype6-dev
pip3 install pillow --global-option="build_ext" --global-option="--enable-jpeg" --global-option="--enable-freetype"