3 ms·

Just be warned that the incorporation of Rust into projects like librsvg means that some older instruction sets (specifically that lack SSE and SSE2, if I recal

Just be warned that the incorporation of Rust into projects like librsvg means that some older instruction sets (specifically that lack SSE and SSE2, if I recall) are no longer supported: https://github.com/rust-lang/rust/issues/14441 https://github.com/rust-lang/rust/issues/14441 As a consequence of this issue, I had to manually downgrade librsvg on a older machine in order to get Buster functional.

cbmuser 6y ago
If the librsvg package in Debian i386 crashes with SIGILL on a Pentium II or Pentium III, it’s a baseline violation and should be reported as a bug against src:librsvg with severity serious. What you describe here is a Debian Policy violation.
- merb 6y ago
  tbf. I still hope that at some point in time the i386 code will be completly removed in linux, even on debian. microsoft won't remove such code, they even keep some 16-bit stuff in windows even if it just does not work anymore. I mean yeah it's cool to run an old machine with top up to date linux, but at some point we still should move on.
  - deleted 6y ago
    [deleted]
gnu8 6y ago
I completely understand the desire to use the newer instructions and get the most performance possible out of the latest hardware, but we also should make it a priority to keep a portable C codepath in all of these libraries. Otherwise we’re going to find there are only two architectures left in the world because none of the software runs on anything else.
- CJefferson 6y ago
  There is a clean codepath, this is about setting the minimum CPU required for x86 -- there is a trade-off, we could make executables that will run on a 386, but it would be slow (particularly if multithreaded) due to later added instructions. Also, such old systems are little tested.
zozbot234 6y ago
> As a consequence of this issue, I had to manually downgrade librsvg on a older machine in order to get Buster functional. How old is your hardware? AIUI, this should only affect Pentium Pro to Pentium III hardware, which is often limited by other factors anyway (particularly RAM). Even old netbook CPU's ought to support SSE2. In fact, that bug report was closed with a suggestion to use i586 as a build target if you have an early i686 machine - would that be satisfactory for your use case?

cbmuser 6y ago

If the librsvg package in Debian i386 crashes with SIGILL on a Pentium II or Pentium III, it’s a baseline violation and should be reported as a bug against src:librsvg with severity serious. What you describe here is a Debian Policy violation.

merb 6y ago
tbf. I still hope that at some point in time the i386 code will be completly removed in linux, even on debian. microsoft won't remove such code, they even keep some 16-bit stuff in windows even if it just does not work anymore. I mean yeah it's cool to run an old machine with top up to date linux, but at some point we still should move on.
- deleted 6y ago
  [deleted]

gnu8 6y ago

I completely understand the desire to use the newer instructions and get the most performance possible out of the latest hardware, but we also should make it a priority to keep a portable C codepath in all of these libraries. Otherwise we’re going to find there are only two architectures left in the world because none of the software runs on anything else.

CJefferson 6y ago
There is a clean codepath, this is about setting the minimum CPU required for x86 -- there is a trade-off, we could make executables that will run on a 386, but it would be slow (particularly if multithreaded) due to later added instructions. Also, such old systems are little tested.

zozbot234 6y ago

> As a consequence of this issue, I had to manually downgrade librsvg on a older machine in order to get Buster functional. How old is your hardware? AIUI, this should only affect Pentium Pro to Pentium III hardware, which is often limited by other factors anyway (particularly RAM). Even old netbook CPU's ought to support SSE2. In fact, that bug report was closed with a suggestion to use i586 as a build target if you have an early i686 machine - would that be satisfactory for your use case?