Hi David, [...] > > Given that, according to the discussion in #156, some earlier version had > > apparently worked fine: couldn't the Debian package simply revert that > > "optimization" that requires GC_DONT_ADD_BYTE_AT_END? > > At the time this was implemented it was quite a significant change and > touched most aspects of the interpreter. I think this would be quite > hard to revert, and doing so would basically constitute a fork. However > I haven't tried to do it, so I can't really be sure. > > It's worth noting that the bundled version of libgc is also a CVS > version, as several bugs unrelated to the optimization were found in the > stable libgc. (I get the impression from upstream that this is because > Mosh uses the C++ wrapper, which is part of libgc but not as heavily > tested.) > Ok, it seems that unpatching mosh really isn't quite an option. May I thus suggest a different route? You could try to convince the Debian libgc maintainers to produce a -src package (see http://packages.debian.org/search?keywords=-src for examples thereof) that provides the source code of the Debian binary packages. I suppose the maintainers should also be more than happy to take all the bugfix patches and include them in the Debian package. Then re-build libgc with any options mosh requires and be happy :-) > > I must state that a package that only works under very specific compile-time > > settings of an external library makes me shiver. It seems that mosh has no > > safety checks and the necessity to rely on such low-level optimizations raises > > questions about the design of this software... > > Sure, I agree, and I will probably raise a question on the ML about this. > I think mosh maintainers should at least seek to include some run-time checks for the options required for correct operation. [...] > I didn't follow either of these routes yet as I wanted to make sure I > wasn't completely off track before working on one. Personally I agree > that the dual-build seems cleaner, so I would prefer to go with that. > I don't claim to be an expert on this, but it seems like a sane way to follow. > Another complication (hah) that I should have mentioned in my original > message was that the build script for the 'binary' that I'm referring to > here, which is fairly substantial human readable source code, was NOT > shipped with the upstream tarball. However, it is under a free license > and is in the git respository, for some reason it was just excluded when > releasing the tarball. As a result, to actually do this dual build, I > would have to patch in the build script, or repack. Are either of these > legally OK? Which do you think would be better? > If the build script is fine license-wise, then just patch it in - that seems much less work than repacking. Keep it simple... (it's complicated enough anyway :-) ). Best, Michael
Attachment:
pgpVhUcSUJBE3.pgp
Description: PGP signature