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

On Thu, 2005-02-10 at 11:51 -0800, Kees Cook wrote:

The static RPMs are built on ... Debian unstable. ;) And no, libstdc++ isn't static in it. I wonder if this is going to cause problems for people with gcc3.4-compiled libstdc++? Debian unstable is using gcc 3.3.5.

I'd say at the moment you should absolutely build the static RPMs with gcc 3.3 (which should make it link against libstdc++.so.5), just as you are doing. That will give you broad compatibility with reasonably modern distros. Worst case people will have to install a compatibility library (on FC3 the package is called compat-libstdc++), I think all sane distros provide some similar mechanism (another possibility is to include the soversion of the libraries in the RPM name, so they relevant RPM would be called libstdc++5 or something similar - I think Mandrake might do this?).

In short, I think you should just keep doing what you're doing, especially with the 0-releasetag. Doing anything more "interesting" will just be messy (or fundamentally impossible without building tons of separate packages). I think it's better to sort those issues out in distro-specific packages, which are most easily distributed through the ordinary distribution update mechanisms.

Cheers, and thanks for all the good work, Per