On Fri, Oct 03, 2003 at 09:38:51AM +0200, Lars Gullik Bjønnes spake thusly: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Martin Vermeer wrote: > >> Undoubtedly can be made to work... but it is 'politically' wise? If we > >> go the way that Lars proposed and recommend people sticking to 2.95 to > >> install and use stlport, than even the little extra hassle of > >> writing/editing a configure_stlport script when a simple --use-stlport > >> option to configure would be the 'least surprise' expectation, is too > >> much. (And yes, I know this is for developers, not end users. But that > >> includes, e.g., distribution packagers handling hundreds of packages > >> and both unfamiliar with and uninterested in the LyX config/install > >> system's idiosyncrasies.) > > > | Let's see how this all pans out first. I suspect Lars will give in and > | commit a debugstream that works for you too... > > ...but now he has a LyX that works... > > -- > Lgb
My first question is: does this only concern developers, or end users too? i.e., do we have any reason to produce binaries for end users on an old compiler, or is it possible to produce such a binary on a modern system? If it is only a developer issue, then I would posit that STLport is preferable to kludges. I can write up a cookbook recipe to get other developers on 2.95 up in no time. Producing binaries for end users shouldn't be too hard either: the RPM will have to have dependencies on libpthread and STLport, which will be both installed into system directories in the library search path. So the end user doesn't even notice it except as a couple of extra dependencies. RPM's for STLport appear to exist (and we could even link statically if must be to avoid this issue altogether.) (BTW would STLport itself have a dependency on libpthread?) The only possible issue I see with this is having to support two different STL/iostreams implementations with each their curious curiosities. But surely that's still better than supporting an old and broken such in addition to the modern gcc3 one. - Martin
pgp00000.pgp
Description: PGP signature
