As there is, again, a bug report against our rpm packages I propose
- to either give a recommendation for autopackage with reason near the rpm links on the download page,
- or to no longer provide rpms at all.
Regards, ralf
http://sourceforge.net/tracker/index.php?func=detail&aid=1374877&gro...
Ralf Stephan wrote:
As there is, again, a bug report against our rpm packages I propose
- to either give a recommendation for autopackage with reason near the rpm links on the download page,
The snapshot autopackages are mighty buggy right now. I think the release was fine but recognize it is easy to make little mistakes packaging and difficult to get the proper testing. The autopackages for 0.42 were rather buggy but I put in a bunch of time into fixing the process for 0.43. Bugs in the rpm are very easy to understand if this was a first time for the packager? (Didn't we switch rpm packagers this release?) So my vote would be to keep the rpms if we can get commitment from the packager to work on and test the packages during the development cycle. I think politics will prevent the autopackage from replacing the rpm for quite some time. Eliminating the rpm is a bad PR move for us. But I will continue insisting that every one I meet try an autopackage. :)
Aaron Spike
On Wednesday 7 December 2005 13:27, aaron@...749... wrote:
Ralf Stephan wrote:
As there is, again, a bug report against our rpm packages I propose
- to either give a recommendation for autopackage with reason near
the rpm links on the download page,
Bugs in the rpm are very easy to understand if this was a first time for the packager? (Didn't we switch rpm packagers this release?)
Yep, I've taken over as RPM packager. This is the first complaint about the "static" RPM I've heard about for this release, and this comes from a Mandriva user when a Mandriva-specific RPM is available. Maybe that one didn't install properly either.
So my vote would be to keep the rpms if we can get commitment from the packager to work on and test the packages during the development cycle. I think politics will prevent the autopackage from replacing the rpm for quite some time. Eliminating the rpm is a bad PR move for us. But I will continue insisting that every one I meet try an autopackage. :)
Agreed on all points. I'll investigate the issue.
On Wed, 07 Dec 2005 18:12:25 +0100, Jean-François Lemaire wrote:
Yep, I've taken over as RPM packager. This is the first complaint about the "static" RPM I've heard about for this release, and this comes from a Mandriva user when a Mandriva-specific RPM is available. Maybe that one didn't install properly either.
From the bug report I'd say it's a generic issue for any system that
hasn't got the compat-libstdc++ packages installed.
Ralf Stephan wrote:
From the bug report I'd say it's a generic issue for any system that
hasn't got the compat-libstdc++ packages installed.
Isn't this the same as 'dependency'? I propose to make it one.
ralf
If you build gcc from source yourself, use the --disable-shared flag, and even c++ will be built as a static linking lib.
1. From the toplevel, make objdir cd objdir
2. ../configure --enable-languages=c,c++ --disable-shared
3. make and make install
Now inkscape will link against the static version of libstdc++, and 'ldd' will no longer list it as a dep.
This is extra work for builders, but only for those who make the distros.
bob
Mike Hearn wrote:
On Mon, 12 Dec 2005 13:20:29 -0600, Bob Jamison wrote:
Now inkscape will link against the static version of libstdc++, and 'ldd' will no longer list it as a dep.
The risk is that this interferes with the system libstdc++.
Hi, Mike!
I'm not sure what you mean. Do you mean (pick one):
a) Installing Inkscape on someone's box might interfere with their normal use of libstdc++.so? I don't see how this is a problem. Only a statically-bound Inkscape would be bound permanently to static stdc++ objects. Other system objects that look for the .so's would continue to do so. The only confusion that I could see would be if we make a libinkscape.so with a statically-bound stdc++.... other clients that use the shared object might load the wrong symbols, but only if we screw it up. This is moot, however, since exposing Inkscape c++ objects would negate the value of statically linking the whole blob anyway.
b) Or do you mean the gcc "make install" itself damaging the development box? If so, just let it go to /usr/local like it wants, or use --prefix=something to put it in a safe place, then only set PATH and LD_LIBRARY_PATH for that build. ../configure --enable-languages=c,c++ --disable-shared --prefix=/usr/local/gcc402 would work nicely.
Earlier I made a practice of periodically uploading Linux builds with everything C++ statically linked, including stdc++, and also Boehm. I built them on FC3 and FC4 with various versions of g++, and never had a problem with running them on other gcc versions or distros.
Hopefully the c++ ABI might actually freeze soon. It's been gelling for a long time now. ;-)
bob
On Tue, 13 Dec 2005 11:57:29 -0600, Bob Jamison wrote:
a) Installing Inkscape on someone's box might interfere with their normal use of libstdc++.so?
b) Or do you mean the gcc "make install" itself damaging the development box?
Neither, I mean that it's got the same problem as loading two dynamic versions of libstdc++ into the same process image has got: it'll cause random undebuggable crashes. If it's dynamic then it can at least be diagnosed easily, otherwise it'll just show up as stack/heap corruption.
For instance, gtkspell loading aspell.
As the same problem occurs with dynamic binaries you could say, well, this doesn't matter. But in that case you may as well do what autopackage does and just put the right version of libstdc++ onto the system if it's missing: that way users who are on a distro using the "right" version get the standard performance benefits of dynamic linking.
thanks -mike
participants (5)
-
unknown＠example.com -
Bob Jamison -
Jean-François Lemaire -
Mike Hearn -
Ralf Stephan