If we decide to make libjpeg a normal standard package, then I'd be +1 on using libjpeg-turbo. Debian also switched to it many years ago, and it only has to apply a small amount of patches (https://sources.debian.org/src/libjpeg-turbo/1%253A2.1.5-2/), which we could easily adopt.
On Friday, November 17, 2023 at 1:28:57 PM UTC-8 Michael Orlitzky wrote: > On Fri, 2023-11-17 at 10:49 -0800, Marc Culler wrote: > > I expect to receive lots of flak for saying this, but I support making > > libjpeg be a standard spkg using the source code from > > https://libjpeg.sourceforge.net. I just built version jpeg-9e on Ubuntu > > 18.04 and macOS 10.13. The standard ./configure ; make install method > > works flawlessly - not even any warnings. The build is fast and the > > package is small. Installing it in sage/local/lib will be simpler, > faster > > and more reliable than guessing where it might be found on any of the > > zillion systems that Sage runs on. Also, unlike the turbo alternatives, > > it does not depend on fancy features of Intel hardware which will not be > > available on old Intel CPUs or recent Arm CPUs. > > I was vague about this because I didn't want to go digging... > > We had to drop this from Gentoo a few years ago for several reasons. > The first is simply that it's not actively maintained. There are > roughly two years between versions, which isn't good enough when a new > clang is released every few months. Where's the bug tracker? Mailing > list? People can't quietly accept security issues or build failures for > that long. We could work around it by backporting enough patches, but > do we really want to maintain a sage fork of libjpeg for two years at a > time? (Are we going to write the patches ourselves if the other distros > quit doing it? Is any distro still shipping the IJG libjpeg?) > > The second is that it's no longer compatible with libjpeg-turbo, and > that's what most people target. Chromium and Qt, for example, only > build against libjpeg-turbo -- or at least did, back when we removed > libjpeg. Thus if you have to pick only one and ship it to your users, > the choice is obvious. You can't have both because they provide the > same API. This might not be a huge problem so long as pillow and every > other sage component support them both, but who knows what the future > holds. > > The libjpeg-turbo features degrade gracefully by the way. I'm certain > to have the oldest intel computer here, and I've been using libjpeg- > turbo for 9+ years, as far back as my git history goes. > > I'm not against adding jpeg support to sage per se, I just think it's > going to be a pain to add it to sage-the-distribution. I'm using my > system's copy of pillow that uses my system's copy of libjpeg-turbo, > nicely avoiding the entire problem, but only as a user. > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/78a8b8e2-9202-4708-9647-346c593c7625n%40googlegroups.com.
