PDA

View Full Version : pointing to libtiff.so.3()



treefiddey
2nd October 2014, 11:02 PM
Hi,

I'm trying to install some software (Lumerical FDTD Solutions) and the installation fails because of a failed dependency:

libtiff.so.3()(64bit)

I manually installed tiff-3.9.7 (./configure; make) and copied libtiff.so.3 to /usr/lib64

but the installer still can't find it. How can I make it see libtiff.so.3?
Any help is appreciated.

PS: I'm a total linux newb. Sorry!

PabloTwo
3rd October 2014, 12:23 AM
First off, when asking questions about dependencies for rpm packages, please state which release of Fedora you are using. Which release you are using can greatly affect what versions of programs, or "resources", are available to you from the repositories. For now, I'll just assume, Fedora 20.

I manually installed tiff-3.9.7 (./configure; make) and copied libtiff.so.3 to /usr/lib64

but the installer still can't find it. How can I make it see libtiff.so.3?
You can't. Rpm packages contain metadata which describes both what that package provides, and what that package requires as dependencies, among other things. Rpm only knows what's in it's own database about each package. Rpm only knows about your installed rpm packages. Rpm doesn't know anything about something that was installed on your system by some other method outside of an rpm package. And why should it? Rpm also doesn't know how to find and install any missing dependencies to a package.

That's the job yum provides. Yum can look at missing dependencies and search for what package(s) provides those dependencies from all the enabled yum repositories you're using, and if it finds them, installs them along with the primary package you wanted installed in the first place. But again, yum is like rpm in that it doesn't know or care about anything on your system that wasn't installed from an rpm package or that resides in the repositories.

So if you are using F20 and have the libtiff package installed and updated to the latest available, then you will have installed:

/usr/lib64/libtiff.so.5
/usr/lib64/libtiff.so.5.2.0
Where libtiff.so.5 is just a symbolic link to the actual libtiff.so.5.2.0 binary. When you copied the libtiff.so.3 file to /usr/lib64, you need to insure that that is the actual binary, and not just a symlink file that points to the real libtiff.so.3.whatever binary file. If that were the case, then you'd also want to copy the real libtiff.so.3.whatever binary there also.

The alternative to that would be to simply create a libtiff.so.3 symlink that points to your installed libtiff.so.5.2.0 binary, and hope it's backwards compatible (may or may not be).

Now, you can't ask yum to install an rpm package with a missing dependency and to just forget about the missing dependency. But you can with rpm. And that's the only way to install your Lumerical rpm package, whatever it's actual rpm package name is.

# rpm --nosignature --nodeps -ivh <package_name>.rpm

P.S. - These are the kinds of issues you get when using non-Fedora rpm packages and/or outdated rpm packages to your current Fedora release. Also note, that by manually adding files that were not installed by rpm packages themselves, you'll see occasional warning when using yum, e.g.: "Warning, RPM database modified outside of yum". You can ignore those warnings but you can't make them go away except by removing the manually installed files that triggered the warning.

Skull One
3rd October 2014, 04:43 PM
Hi,

I'm trying to install some software (Lumerical FDTD Solutions) and the installation fails because of a failed dependency:

libtiff.so.3()(64bit)

I manually installed tiff-3.9.7 (./configure; make) and copied libtiff.so.3 to /usr/lib64

but the installer still can't find it. How can I make it see libtiff.so.3?
Any help is appreciated.

PS: I'm a total linux newb. Sorry!

See http://forums.fedoraforum.org/showpost.php?p=1691177&postcount=10 to build a compatibility package (tested with fc20).

PabloTwo
3rd October 2014, 04:49 PM
An elegant solution Skull One. I like it.

treefiddey
3rd October 2014, 05:21 PM
PabloTwo:
Thank you very much for taking the time to reply! This is all news to me, but it makes sense. One note - I am not using rpm or yum to install the FDTD Solutions package. It has its own install.sh script.

Anyway, simply creating a symbolic link libtiff.so.3 to point to my current version of libtiff did not satisfy the install script.

PabloTwo
3rd October 2014, 05:32 PM
One note - I am not using rpm or yum to install the FDTD Solutions package. It has its own install.sh script.
I see. The dependency failure led me to think it was in the form of an rpm package. Without seeing or knowing what the install.sh is or does, then it's hard to diagnose what steps to take to resolve your issue. You could try the solution Skull One posted a link to in his reply.

PabloTwo
3rd October 2014, 06:51 PM
An addendum: It could be that the install script has hard coded the files paths of where to expect to find the needed libs, and that those paths are geared towards the Debian flavored world of Linux. Though I am Fedora through and through, I have only somewhat recently installed Linux Mint so as to gain some knowledge of how things are done in the Debian/Ubuntu world.

I have run across several instances of install scripts that were written with only general debian/ubuntu conventions in mind that just do not work in Fedora, as Fedora does several things differently than from the debian/ubuntu ways. Such as where to insall library files. Ubuntu/Mint (based on Ubuntu) uses:

/lib/
/usr/lib/
/usr/lib/x86_64-linux-gnu/

Whereas Fedora uses:

/lib/
/usr/lib/
/usr/lib64/

In my 64 bit install of Mint, I find all of the libs installed in /usr/lib/ are actually 64 bit. In Fedora, only 32 bit libs will go into /usr/lib, and only 64 bit libs will go into /usr/lib64/. So it may be a matter of determining what directories the installer is checking for installed libs, and create your symlink there.

treefiddey
3rd October 2014, 06:51 PM
I take that back. install.sh eventually uses rpm to do the install.

treefiddey
3rd October 2014, 07:05 PM
See http://forums.fedoraforum.org/showpost.php?p=1691177&postcount=10 to build a compatibility package (tested with fc20).

SkullOne,
Thanks for this link!

I am using fc20 in VMWare player.

In this part:

rpm -ivh libtiff-3.9.7-2.fc17.src.rpm
sed 's/Name: libtiff/Name: libtiff_compat/' -i rpmbuild/SPECS/libtiff.spec
rpmbuild -bb rpmbuild/SPECS/libtiff.spec

when I run

rpm -ivh libtiff-3.9.7-2.fc17.src.rpm

I get the following warnings:

Updating / installing...
1:libtiff-3.9.7-2.fc17 ################################# [100%]
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root

Also, in the second line:

sed 's/Name: libtiff/Name: libtiff_compat/' -i rpmbuild/SPECS/libtiff.spec

is SPECS a variable that I should specify? That is, am I renaming
libtiff-3.9.7-2.fc17.src.rpm to libtiff_compat_3.9.7-2.fc20.x86_64.rpm ?

PabloTwo
3rd October 2014, 07:06 PM
I take that back. install.sh eventually uses rpm to do the install.
Then you can just ignore my last post above.

treefiddey
3rd October 2014, 07:08 PM
Nevertheless, good to know. thanks!

PabloTwo
3rd October 2014, 07:12 PM
You can ignore the warnings about mockbuild. When you install the src.rpm file, if not already created, it will create the rpmbuild directory with various sub-directories and install the source code package to ~/rpmbuild/SOURCES/ and the spec file to ~/rpmbuild/SPECS/.

What the sed command does is modify one line in the spec file (giving the package a different name). So, SPECS is not a variable, it is a directory.
You are not renaming the src.rpm package. The sed edit in the spec file will give the newly created libtiff package the new name once built, and found in ~/rpmbuild/RPMS/x86_64/.

Skull One
3rd October 2014, 07:13 PM
I get the following warnings:

Updating / installing...
1:libtiff-3.9.7-2.fc17 ################################# [100%]
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root

Don't worry about it.



Also, in the second line:

sed 's/Name: libtiff/Name: libtiff_compat/' -i rpmbuild/SPECS/libtiff.spec

is SPECS a variable that I should specify? That is, am I renaming
libtiff-3.9.7-2.fc17.src.rpm to libtiff_compat_3.9.7-2.fc20.x86_64.rpm ?

libtiff-3.9.7-2.fc17.src.rpm is the source package. The 'rpm -ivh' command installed it in your home directory, creating & populating the ~/rpmbuild tree.
rpmbuild/SPECS/libtiff.spec is the file edited by the sed command: we change the 'Name' entry, so rpmbuild will build the binary package libtiff_compat_3.9.7-2.fc20.x86_64.rpm which will not conflict with the newer libtiff package.

PabloTwo
3rd October 2014, 07:49 PM
Since I'm familiar with building rpm packages (and rebuilding from SRPM packages), it took me no more than 3 minutes to download the older F17 libtiff src.rpm, install it, do the spec file edit then do the rebuild. I think the OP is well on his way to having a successful conclusion to doing the SRPM rebuild himself (and a good learning experience in the process), but if push comes to shove, I use a file sharing site where I can post the newly minted libtiff_compat-3.9.7-2.fc20.x86_64.rpm if need be.

[paul@fettel SPECS]$ ll ../RPMS/x86_64/
total 1852
-rw-rw-r--. 1 paul paul 147484 Oct 3 14:40 libtiff_compat-3.9.7-2.fc20.x86_64.rpm
-rw-rw-r--. 1 paul paul 873236 Oct 3 14:40 libtiff_compat-debuginfo-3.9.7-2.fc20.x86_64.rpm
-rw-rw-r--. 1 paul paul 456328 Oct 3 14:40 libtiff_compat-devel-3.9.7-2.fc20.x86_64.rpm
-rw-rw-r--. 1 paul paul 153200 Oct 3 14:40 libtiff_compat-static-3.9.7-2.fc20.x86_64.rpm
-rw-rw-r--. 1 paul paul 253444 Oct 3 14:40 libtiff_compat-tools-3.9.7-2.fc20.x86_64.rpm

[paul@fettel x86_64]$ rpm -qpl libtiff_compat-3.9.7-2.fc20.x86_64.rpm
/usr/lib64/libtiff.so.3
/usr/lib64/libtiff.so.3.9.7
/usr/lib64/libtiffxx.so.3
/usr/lib64/libtiffxx.so.3.9.7
/usr/share/doc/libtiff_compat
/usr/share/doc/libtiff_compat/COPYRIGHT
/usr/share/doc/libtiff_compat/README
/usr/share/doc/libtiff_compat/RELEASE-DATE
/usr/share/doc/libtiff_compat/VERSION

[paul@fettel x86_64]$ rpm -qp --provides libtiff_compat-3.9.7-2.fc20.x86_64.rpm
libtiff.so.3()(64bit) <== The missing "resource" you need
libtiff_compat = 3.9.7-2.fc20
libtiff_compat(x86-64) = 3.9.7-2.fc20
libtiffxx.so.3()(64bit)

treefiddey
3rd October 2014, 08:50 PM
Thank you very much guys.

Once I understood what I was doing, I gave sed the appropriate path and it worked like a charm.

Again, I really appreciate you taking the time. This has been holding my work back this whole week!

Cheers!