Based on the bug report filed here, Gnash will not compile with the latest giflib. I assume that means that if I use an older giflib, it'll compile just fine. I'm not sure how to do this, though - my package manager (I'm on Manjaro, and have access to AUR) doesn't seem to help here, and I'm not sure what I would have to modify or do in such a case anyway.
Basically, after I get the code for Gnash from Savannah, what would I need to do/change to make it compile using an older giflib?
If you haven't already seen it, as Raydel notes there has been a reply to your request for a workaround on the bug report itself.
This is certainly the quicker solution, though there is nothing wrong with having two versions (or just the older, working) version of the GifLib library on your system.
To do that, you can download GifLib v4.2.3 here, a version older than the change that breaks gnash compilation.
Either place it in a different directory (you probably have v5.1 in /usr/local/lib?) and change the include/linker paths or replace v5.1 files in-place and you shouldn't need to change your compilation steps at all.
Trying the same steps myself, I have been unable to replicate your error.
Excluding sudo apt-get install-ing numerous packages (which aren't the cause of your troubles - and at every step I was told exactly what was missing) these were my steps on a fresh installation:
$ git clone git://git.sv.gnu.org/gnash.git
$ curl http://sourceforge.net/projects/giflib/files/giflib-4.x/giflib-4.2.3.tar.bz2/download
$ tar xvjf giflib-4.2.3.tar.bz2
$ cd giflib-4.2.3
$ ./configure
$ sudo make
$ sudo make install
$ cd ../gnash
$ ./autogen.sh
$ ./configure.ac
$ sudo make
$ sudo make install
I recommend you begin afresh, since these steps took care of everything for me - without any manual moving of files, specifying compiler/linker options or editing of makefiles which seems to be causing you problems.
Well I, just checked the bug report you have posted. And there is a workaround:
As a workaround, you can change line 123 of libbase/GnashImageGif.cpp file as follows:
GifInput::~GifInput()
{
// Clean up allocated data.
- DGifCloseFile(_gif);
+ DGifCloseFile(_gif, 0);
}
EDIT: According to my experience, it is better practice to apply the patch. If you use an older version of giflib you will miss any change made in the newer version. And those changes most of the time are for good, bug fixes, optimization ect ..
Related
my crystal version is 0.26.1
my amber version is 0.7.2
I would like to upgrade my amber framework installation to the latest stable version (currently 0.9.0). What is the best way to do it? Thanks
Upon further inspection, this looks like something the shard.yml would be good for:
crystal: 0.26.1
dependencies:
amber:
github: Amber-Crystal/amber
branch: BRANCH_HERE
BRANCH_HERE: being something like master, or stable
Also see :
SPEC.md on master
from commit
Where you can also use the version key.
However, without any shard/package management.
See where they are currently located:
which amber
which crystal
Upgrading amber:
export VERSION=0.10.0
wget "https://github.com/amberframework/amber/archive/v$VERSION.tar.gz"
tar xvfz $VERSION.tar.gz
cd amber-$VERSION
make
make install # perhaps sudo
It will build a dist and overwrite /usr/local/bin/amber with the new one.
Upgrading crystal:
export CRYSTAL_VERS=0.26.1
wget "https://github.com/crystal-lang/crystal/archive/$CRYSTAL_VERS.tar.gz"
tar xvfz $CRYSTAL_VERS.tar.gz
cd crystal-$CRYSTAL_VERS
make
ln -s [full path to bin/crystal] /usr/local/bin/crystal
There are pre-compiled versions targeting specific systems as well, which can be found here: https://github.com/crystal-lang/crystal/releases
With those you'll be able to skip the build/compile step.
As far as code migration, I'm not sure what sort of migration tools are currently available, but you'll want to check the changelogs for any breaking changes
I wish to use CTF conversion with perf. From the scarce information around, I've figured out that I need to recompile perf.
I've installed the epel repository and used yum to install
babeltrace and libbabeltrace
for the run time as well as
libunwind-devel slang-devel libbabeltrace-devel and asciidoc
for compilation.
I cloned git.kernel.org (as alternative I also tried github.com/torvalds) and used
LIBBABELTRACE=1 make
to build the perf with babeltrace support. However, I get the error:
Makefile.config:780: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
So I try adding LIBBABELTRACE_DIR with /usr but this, too, fails. Checking out the Makefile.conf, I see that the configuration is looking in the wrong places: it is set up to use a locally compiled babeltrace with well defined subdirectories (include and lib), but these are NOT used when installing from rpm (yum). The rpm places them in /usr/include/babeltrace and /usr/lib64.
Patching the Makefile also doesn't help.
So, short of being forced to use a locally compiled babeltrace, what options do I have?
This is for a cluster of 26 nodes and I really would prefer a simple 'yum install' as this simplifies restaging nodes when the get corrupted (we do research with them and regularily corrupt stuff) and does not require setting specific environments.
ADDENDUM:
I tried compiling babeltrace from https://github.com/efficios/babeltrace.git: this, too, fails with the error:
babeltrace-cfg-cli-args.c:2390:29: error: ‘POPT_ARG_LONGLONG’ undeclared (first use in this function)
and, surely enough, popt.h does not define POPT_ARG_LONGLONG.
Thanks in advance.
When trying to install shogun im getting this error. Can some one suggest a solution?
N: Ignoring file '50unattended-upgrades.ucf-dist' in directory '/etc/apt/apt.conf.d/' as it has an invalid filename extension
E: Unable to locate package libshogun17
Im using ubuntu operating system.
See this explanation of the origin and purpose of .ucf-dist files. This means you can either ignore the notice (that's what the N: prefix stands for) or remove said file.
sudo rm /etc/apt/apt.conf.d/50unattended-upgrades.ucf-dist
libshogun17 is not part of ubuntu by default. Currently we supply two different ppa's for xenial and trusty:
for nightly builds: https://launchpad.net/~shogun-toolbox/+archive/ubuntu/nightly
for stable releases: https://launchpad.net/~shogun-toolbox/+archive/ubuntu/stable
please follow the instruction either the given page or http://shogun.ml/install#ubuntu how to add the ppa to your system.
Note, as mentioned above those PPAs only supply packages for ubuntu trusty or xenial.
I need to install ocropus on Ubuntu 11.04.
I went through a long and painful process of trying ocropus 0.3 and 0.4 from the project's Downloads page, but to no avail - I could find no way of making it locate tesseract, which it recommended. I labored on Google and came across the page http://code.google.com/p/ocropus/wiki/InstallTranscript.
Great. Except when I issue the command:
hg clone $release https://ocropus.googlecode.com/hg/ ocropus
I get the error message:
abort: unknown revision 'ocropus-0.4.4'!
A post here http://aur.archlinux.org/packages.php?ID=13444 by the maintainer of the ocropus package for archlinux says
they have completely refactored ocropus and at the same time they have also completely removed the old repository so it's not possible to access the old "stable" versions. I suggest using the ocropus-hg package, at least for the time being.
I thought I would go ahead with this idea and issued the command:
hg clone https://ocropus.googlecode.com/hg/ ocropus #I deftly avoid any
mention of the release
The result is I get a folder with a file interestingly named ocroinst. I run it and it says I need to run the following commands:
sudo ./ocroinst packages #checks the dependencies
./ocroinst install #installs ocropus
sudo ./ocroinst dl #downloads models
I was glad and I issued the first command, which is when I got the message:
Package libjpeg8-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package libjpeg8-dev has no installation candidate
I think a certain Murphy may have had a point.
The situation, with an delicious added complication, is this:
(please correct me if I am wrong)
Ubuntu 11.04 comes with libjpeg62-dev. The required version for ocropus is libjpeg8-dev.
Ocropus requires libtiff4-dev, and libtiff4-dev depends on libjpeg62-dev. Therefore there is no way for me to uninstall libjpeg62-dev.
libjpeg62-dev conflicts with libjpeg8-dev. Therefore, I can have only one of libjpeg8-dev or libjpeg62-dev, and never both.
If libjpeg8-dev is installed, I will have no libjpeg62-dev, which means I must remove libtiff4-dev and therefore have no way to install ocropus.
If libjpeg62-dev is installed, I will have no libjpeg8-dev and thus I will have no way to install ocropus.
NOTE:
(An experiment description)
I had libjpeg62-dev installed on the system already. I figured I could take a chance and I went right ahead and changed every libjpeg8-dev I could find to libjpeg-dev, and ran the 3 commands.
It installed. No error.
This gave me great joy
until
I ran the command
ocropus <image-file-name>
and I was greeted by the charming:
ImportError: /usr/local/lib/python2.6/dist-packages/_iulib.so: undefined symbol: _ZN5iulib6dcloseEv
The more sophisticated
ocropus book2pages out image*
failed with the same error. A post on stack overflow indicates that this is caused by incorrectly versioned libraries.
THE QUESTION:
How should I proceed?
Thanks in advance.
You can consider this a follow-up question to How do I install the OpenSSL C++ library on Ubuntu?
I'm trying to build some code on Ubuntu 10.04 LTS that requires OpenSSL 1.0.0.
Ubuntu 10.04 LTS comes with OpenSSL 0.9.8k:
$ openssl version
OpenSSL 0.9.8k 25 Mar 2009
So after running sudo apt-get install libssl-dev and building, running ldd confirms I've linked in 0.9.8:
$ ldd foo
...
libssl.so.0.9.8 => /lib/i686/cmov/libssl.so.0.9.8 (0x00110000)
...
libcrypto.so.0.9.8 => /lib/i686/cmov/libcrypto.so.0.9.8 (0x002b0000)
...
How do I install OpenSSL 1.0.0 and the 1.0.0 development package?
Update: I'm writing this update after reading SB's answer (but before trying it), because it's clear I need to explain that the obvious solution of downloading and installing OpenSSL 1.0.0 doesn't work:
After successfully doing the following (recommended in the INSTALL file):
$ ./config
$ make
$ make test
$ make install
...I still get:
OpenSSL 0.9.8k 25 Mar 2009
...and:
$ sudo apt-get install libssl-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libssl-dev is already the newest version.
The following packages were automatically installed and are no longer required:
linux-headers-2.6.32-21 linux-headers-2.6.32-21-generic
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
...and (just to make sure) after rebuilding my code, ldd still returns the same thing.
Update #2: I added the "-I/usr/local/ssl/include" and "-L/usr/local/ssl/lib" options (suggested by SB) to my makefile, but I'm now getting a bunch of undefine reference compile errors, for example:
/home/dspitzer/foo/foo.cpp:86: undefined reference to `BIO_f_base64'
/home/dspitzer/foo/foo.cpp:86: undefined reference to `BIO_new'
/usr/local/ssl/include/ contains only an openssl directory (which contains numerous .h files), so I also tried "-I/usr/local/ssl/include/openssl" but got the same errors.
Update #3: I tried changing the OpenSSL includes from (for example):
#include <openssl/bio.h>
...to:
#include "openssl/bio.h"
...in the .cpp source file but still get the same undefined reference errors.
Update #4: I now realize those undefined reference errors are linker errors. If I remove the "-L/usr/local/ssl/lib" from my Makefile, I don't get the errors (but it links to OpenSSL 0.9.8). The contents of /usr/local/ssl/lib/ are:
$ ls /usr/local/ssl/lib/
engines libcrypto.a libssl.a pkgconfig
I added -lcrypto, and the errors went away.
Get the 1.0.0a source from here.
# tar -xf openssl-1.0.0a.tar.gz
# cd openssl-1.0.0a
# ./config
# sudo make install
Note: if you have man pages build errors on modern systems, use make install_sw instead of make install.
This puts it in /usr/local/ssl by default
When you build, you need to tell gcc to look for the headers in /usr/local/ssl/include and link with libs in /usr/local/ssl/lib. You can specify this by doing something like:
gcc test.c -o test -I/usr/local/ssl/include -L/usr/local/ssl/lib -lssl -lcrypto
EDIT DO NOT overwrite any system libraries. It's best to keep new libs in /usr/local. Overwriting Ubuntu defaults can be hazardous to your health and break your system.
Additionally, I was wrong about the paths as I just tried this in Ubuntu 10.04 VM. Fixed.
Note, there is no need to change LD_LIBRARY_PATH since the openssl libs you link against by default are static libs (at least by default - there might be a way to configure them as dynamic libs in the ./config step)
You may need to link against libcrypto because you are using some calls that are built and defined in the libcrypto package. Openssl 1.0.0 actually builds two libraries, libcrypto and libssl.
EDIT 2 Added -lcrypto to gcc line.
Instead of:
$ ./config
$ make
$ make test
$ make install
Do:
$ sudo ./config --prefix=/usr
$ sudo make
$ sudo make test
$ sudo make install
This will help you update to openssl 1.0.1g to patch for CVE-2014-0160 (Heartbleed).
OpenSSL Security Advisory [07 Apr 2014]
TLS heartbeat read overrun (CVE-2014-0160)
A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.
Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.
Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley and Bodo Moeller for
preparing the fix.
Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.
1.0.2 will be fixed in 1.0.2-beta2.
Source: https://www.openssl.org/news/secadv_20140407.txt
Here's what solved it for me:
Upgrade latest version OpenSSL on Ubuntu
Transcribing the main information:
Download the OpenSSL v1.0.0g source:
$ wget http://www.openssl.org/source/openssl-1.0.0g.tar.gz
Unpack the archive and install:
$ tar xzvf openssl-1.0.0g.tar.gz
$ cd openssl-1.0.0g
$ ./config
$ make
$ make test
$ sudo make install
All files, including binaries and man pages are install under the directory /usr/local/ssl. To ensure users use this version of OpenSSL instead of the previous version you must update the paths for man pages and binaries.
Edit the file /etc/manpath.config adding the following line before the first MANPATH_MAP:
MANPATH_MAP /usr/local/ssl/bin /usr/local/ssl/man
Update the man database (I honestly can't remember and don't know for sure if this command was necessary - maybe try without it and at the end when testing if the man pages are still the old versions come back and run mandb):
sudo mandb
Edit the file /etc/environment and insert the path for OpenSSL binaries (/usr/local/ssl/bin) before the path for Ubuntu's version of OpenSSL (/usr/bin). My environment file looks like this:
PATH="/usr/local/sbin:/usr/local/bin:/usr/local/ssl/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
Logout and login and test:
$ openssl version
OpenSSL 1.0.0g 18 Jan 2012
Also test the man pages by running man openssl and at the very bottom in the left hand corner it should report 1.0.0g.
Note that although the users will now automatically use the new version of OpenSSL, existing programs (e.g. Apache) may not as they are linked against the libraries from the Ubuntu version.