Django OS X Wrong JPEG library version: library is 80, caller expects 62 sorl.thumbnail - python-imaging-library

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"

Related

fix setuptools version when installing libraries using setup.py

This question is somewhat similar to the one here, but I cannot make it work.
So suppose that I have a set of packages (say 2) to install and I want to use pipenv. If I do pipenv install on the directory with a suitable Pipfile the installation fails because there is some metadata issue when installing one of the libraries (say libX) contained in install_requirements of one of the packages. It seems that the problem can be fixed by downgrading the version of setuptools to <=58.0.0.
OK. Now, if I first install that version of setuptools<=58.0.0 in the venv and then install my packages, everything works fine. The issue is that the Pipenvfile does not respect the order when installing, so something like
[packages]
setuptools = "<=58.0.0"
pckg1 = {<github path 1>}
pckg2 = {<github path 2>}
is not ensured to work. Also, by default the seed packages added to the venv include setuptools==65.6.3.
So the idea is to be able to restrict the version of setuptools that is used to check the metadata of the libraries in libX, to mimic the above scenario in which setuptools was installed first. Is there a way to do that?
I have tried placing setuptools<=58.0.0 at the top of the requirements.txt that defines the install_requirements of the problematic package, but it does not work.
If have also tried to fix or restrict the version of libX contained in that requirements.txt file but, surprisingly, pipenvdoes not seem to care: a verbose install shows that it keeps downgrading libX well below the restriction - "using cached libX-vX.X.X"- until it uses a version for which the metadata generation fails (why on earth does it do that, even if I call it with pipenv --clear install?).
I am a bit lost about what could be the best solution here. Any help would be very appreciated.

Variant Effect Predictor | DBD mysql failing to setup

I trying to get set up with Variant Effect Predictor (VEP) on the command line. I'm following the setup tutorial but I'm encountering some errors around dependencies. I'm also quite new to the command line so if anyone is able to break down the solution too then I'd be very grateful. Thanks!
Tutorial: https://www.ensembl.org/info/docs/tools/vep/script/vep_tutorial.html
VEP requirements: http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
I also have Perl v5.32.1.
What I've done:
I installed dependencies (listed in the requirements page) with the following commands:
- sudo -s cpanm DBI
- sudo -s cpanm Archive::Zip
- sudo -s cpanm DBD::mysql
For DBD:mysql, I got the follwoing message:
--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/D/DV/DVEEDEN/DBD-mysql-4.050.tar.gz ... OK
Configuring DBD-mysql-4.050 ... N/A
! Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
Trying it out anyway, I ran perl INSTALL.pl (from the tutorial page) and got the message below. I would like VEP to run in online mode too if possible.
`WARNING: DBD::mysql module not found. VEP can only run in offline (--offline) mode without DBD::mysql installed
http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
Hello! This installer is configured to install v104 of the Ensembl API for use by the VEP.
It will not affect any existing installations of the Ensembl API that you may have.
It will also download and install cache files from Ensembl's FTP server.
Checking for installed versions of the Ensembl API...done
Setting up directories
Destination directory ./Bio already exists.
Do you want to overwrite it (if updating VEP this is probably OK) (y/n)? y
- fetching BioPerl
- unpacking ./Bio/tmp/release-1-6-924.zip
ERROR: Unable to unpack file ./Bio/tmp/release-1-6-924.zip without Archive::Extract or tar/unzip/gzip`
You show us this error:
Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
So looking in there will give you more clues about what the problems are. Without that, we can only guess.
But we can make educated guesses. The DBD::mysql distribution comes with a file called DBD::mysql::INSTALL which will talk you through some of the problems you'll find while installing this module.
It's important to note that DBD::mysql is a wrapper around MySQL's client libraries. They are written in C, so you'll need a C compiler installed in order to build DBD::mysql. You'll also need the client libraries and the development versions of the client libraries (for the C header files that you'll need to compile the module). On Ubuntu, those packages are called "libmysqlclient" and "libmysqlclient-dev". If you don't have a C compiler, then you'll want to install "gcc" too.
But this is all getting a bit complicated. There's another, simpler, approach. If you're using the system version of Perl (the version that was installed as part of the operating system and probably lives in /usr/bin/perl) then I'd recommend using the pre-build Ubuntu version of the package, which you can install by running:
$ sudo apt-get install libdbd-mysql-perl
Installing that version uses the OS's own package manager, and the package manager knows which other packages are needed in order for it to work - so it will install those as well.
People will probably complain that you're better off installing the modules from CPAN as it gives you more flexibility and allows you to use more up-to-date packages than the versions from your OS repos. And they're right. But, honestly, if you're a non-Perl programmer who just wants to get an application up and running, this is by far the simplest approach.
(But, as I said above, this is all guesswork as you haven't shared the most important errors with us.)

Cannot use Swift on Ubuntu 18.04

After conscientiously following the install instructions on Linux from swift.org, I encounter an issue where it is not possible to compile anything on a Ubuntu 18.04 machine. The REPL seems to work but during compilation (when calling swift build) the following error appears:
/usr/bin/ld: cannot find -lstdc++
There are more details in the full bug report [SR-9093]. I don't know at all what to do to solve this issue, there are similar problems already mentioned in other bug reports, for instance on this really old one [SR-35].
What should I do?
Thank you
I am assuming that you had already installed the libstdc++ successfully and you have set the permissions properly. But I really doubt that it was installed correctly but it was installed with corruption of some sort. The corruption occurred because you didn't install libstdc++ via a package manager. Result was some form of weirdness in the package manager database which effected the overall functioning system. Exactly why adding something to a folder should change anything at all. I don't know why this happens, unless the folder is hot i.e symbolically linked to a program which doesn't have any tolerance for hacks like simply copying a file into the folder. So for now try to install the libstdc++ again. Below is the link to the file to again download the correct program and this is compatible with amd64.
http://security.ubuntu.com/ubuntu/pool/main/g/gcc-5/libstdc++6_5.4.0-6ubuntu1~16.04.10_amd64.deb
And below are some link to help
https://ubuntuforums.org/showthread.php?t=1425470
https://ubuntuforums.org/showthread.php?t=808045
https://ubuntuforums.org/showthread.php?t=808045
https://packages.ubuntu.com/search?keywords=libstdc%2B%2B
https://packages.ubuntu.com/xenial/amd64/libstdc++6
Install libstdc++
sudo apt install libstdc++6
It seems possible that the apt install did not run the ldconfig program, which should be run to add the library to the list of those which ld.so knows about.
It looks like you can do it manually:
sudo ldconfig
IMPORTANT CAVEAT: I don't have Ubuntu and haven't been able to test this. And it's a sudo command. Run at your own risk, YMMV, etc.
If this does not work, it's possible that a file called /etc/ld.so.conf is not set up to search the directory where libstdc++ ended up. I wouldn't dare try to describe how to fix that.
sudo apt install -f
The command above should install any missing dependencies.

Problems installing/compiling DBD::mysql on OpenSuSE 10

I am getting a bunch of compile errors when I try to install the MySQL DBD::mysql Perl library. I am trying to install this library on OpenSuse linux (SUSE Linux Enterprise server 10 (x86_64) version 10, patch level 4)
The install fails when trying to compile dbdimp.h. There are hundreds of complile errors but I have reason to believe they all stem from the first 3:
dbdimp.h:23:49: error: mysql.h: No such file or directory
dbdimp.h:24:45: error: mysqld_error.h: No such file or directory
dbdimp.h:26:49: error: errmsg.h: No such file or directory
I believe that the reason I am getting the errors above is that I have no MySql Client installed. I do not know how to install mysql client (I believe I am supposed to get some version of libmysqlclient).
I am brand new to opensuse and vaguely familar with installing packages on Linux in general have used yum, yast, apt-get on ubuntu + centOS previously but the only package manager tools that seem to be on OpenSuse 10 are rpm and zypper. I have not managed to install the required mysql client using either of these. If anyone knows how to install MySql Client to resolve my issue I would greatly appreciate any recomendations
Thanks
You need to install MySQL or the MySQL client libraries, either through your system's package manager or by following the installation instructions from the source code.
It sounds like your question is really "How do I install MySQL on OpenSuse", which would be more appropriate for one of the other StackExchange sites.
I was able to resolve this to a point. In my original question, I stated that I had tried using YAST but that it had not worked. In fact, I did not fully explore the YAST install option but when I did, I managed to download install the required librarys by following an article I found (http://adminramble.com/install-mysql-yast/#chitika_close_button)
I was able to open the YAST GUI in the terminal window (not an X-window display) and navigate through the "software management" section wherein I was able to do a search for MySql. Amoung the search results were mysql client libraries, which I then selected and hit "Accept". The installation started and completed successully.
In order to complile the PERL DBD::mysql module, I had to create a new makefile with the ccflags specified so that the header files could be found:
perl Makefile.PL --cflags -I/usr/include/mysql
I say "to a point" at the top of this comment because I then ran into further problems compiling but my original issue posted has been partially resolved and getting this far may help someone else who is experiencing the same problem. Will update if I get a solution to the compile problem.

rvm installation fails on powerpc ibook g4

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 =/