On Thu, 2005-02-10 at 10:34 -0800, Kees Cook wrote:
On Thu, Feb 10, 2005 at 12:21:34PM -0600, Jim Clark wrote:
Should I continue with the install? Should I remove the rpms? Next step?????? Here's the rpms I installed: glibmm-2.4.4-1.fc2.i386.rpm ...
Yeah, based on the email from Per Bjornsson, you're going to have problems. You'll need to remove the fc2 RPMs, I think.
Ah, yes, apparently our discussion after that ended up offline. Indeed, it seems easiest to just ditch all the old RPMs and install them from a repository made for FC3, such as the official Extras. Using a depsolver to install Inkscape will pull in all needed dependencies; 0.41 isn't there yet but will be and in the meantime
It's unfortunate that the GCC C++ ABI isn't stable yet, and also that libstdc++ gets bumped. It makes binary compatibility with C++ apps so hard... (Well, if you consistently build everything on one distro there are generally compatibility packages that fix things up, but using a mixed build environment is basically a one-way road to disaster currently.
I'd suggest either going the Extras route he described, or the static rpm route recommended by Josef Vybiral.
That should work as well of course, and shouldn't rely on much at all. Depending on the distro where it was compiled, the compat-libstdc++ RPM for Fedora might be needed, I don't think that libstdc++ is linked in statically in that RPM? In any case, that's fairly easy and Bob likely already has it installed since RPM was apparently happy to install the FC2 gtkmm et al RPMs which should also need compat-libstdc++ on FC3.
By the way, I sort of think that it would be nice to have the upstream Inkscape RPMs have a release tag that starts with "0." (so the 0.41 static RPM would have been named inkscape-0.41-0.static.i386.rpm etc) since that would make official distribution packages override them (I think all distros start their release numbering at 1, or more if they have gone through test versions that didn't work out - in any case more than 0). In the case where the distro does provide packages I think they are generally preferable since they might integrate better into the desktop environment. Normally the difference will be minor of course, but I think that it's sane do defer to the distribution if they want to distribute a stable version. (E.g. issues such as not needing the backwards compatibility libraries might be valued by some.)
Best regards, Per Bjornsson