My first foray into the world of Linux...help!

I apologize for the slow response; I have been too distracted lately to really keep up with this board.

That was careless wording on my part. Of course apt is a front-end to dpkg, but not in the way Synaptic is a front-end to apt. My point was that, as far as I am aware, you cannot use apt to install a .deb you have retrieved yourself.

I don’t think Debian will allow two versions of the same package installed at once. My feeling is that you would have to build a new package with a name like ‘libstdc+±oldversion’.

Yes it would, but I’m not going to recommend anything so drastic if I don’t have the program to experiment with myself. Mangetout, could you supply us with a link to the RPM you downloaded?

Never mind that; I just found the RPM under Mangetout’s link. (Their website apparently uses Javascript to display some information, and I was using a browser that doesn’t support it.) I will experiment with it tomorrow and see what I can discover.

OK, I just booted into the Hoary Live CD, and got Mangetout’s program to work with nothing fancy at all. I just had to enable universe in my sources.list, and then install the following two packages:

libstdc++2.10-glibc2.2
libpng2

With that, the program started right up, though not without a few obscure error messages displaying in the process. It does seem to work, nevertheless.

I apologize for my gross miscalculation of the difficulty of this situation.

. . . though on reflection, I realize Mangetout may not be using Hoary, which could render my experience irrelevant.

. . . but at the same time, I think it should work fine since some quick research shows that the needed packages are available for Warty, Hoary, and Breezy: C++ lib, PNG lib.

Wow, five posts in a row! I will try to plan my thoughts better next time.

Apt would remove the new library, yes. It would treat it as a downgrade since there was already a package installed by that name. (You would have to force it too because apt normally won’t downgrade a package even if you change your sources to an older branch.) Dpkg would probably just tell you it can’t install the older package until you removed the newer one. Now it would be possible to have two versions of one program installed as long as the package names were unique and they didn’t try to install any files with the same name in the same directory. I don’t know if Debian ever does this, but FreeBSD does often. I have two versions of gcc installed right now. The version in the base system is installed as /usr/bin/gcc and the one from ports is installed as /usr/local/bin/gcc34. If I want to compile a program using the newer gcc, I have to type “make CC=gcc34”. Similar concepts apply to libraries.

I think the most common method is to install one, if not both, of the sets of libraries into a directory named after the package and version. For instance, in /usr/local/include, I have both orbit-1.0/ and orbit-2.0/ directories. Typically when you’re compiling a program, you can pass options to configure to tell it where to find certain sets of libraries instead of just letting it use the first one it finds (if it even finds anything).

There you have it. Thanks rkts and snailboy. Now that I think about it, I was probably running RedHat when I used the separate versions of the libraries. Don’t even remember now if the package came with the software that needed it; I just remember that I had a minor issue to resolve. I have little need – actually none at all, these days – to venture outside of the Debian testing repository to satisfy my software needs, hence my ignorance regarding of how it works with apt.

Let me state things more clearly, if I can, in case there is any lingering ambiguity. Mangetout’s statement that “there are subtle differences in the version numbers” suggested that there was a problem due to a difference in minor versions, which was not the case; rather, the program only required that the library be version 3.something (as indicated by the ending of .so.3), and the loader could not find anything to satisfy this requirement. Your suggestion of manually setting the library path would only have been necessary if there had been two incompatible minor versions of the library. If Mangetout had, say, version 4 of the same library, it would reside in the same folder with a different name, with a symlink to it ending in .so.4, and would probably be installed as a different package, thus not interfering in any way.