Re: [opensuse-factory] libjpeg-turbo
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote:
It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or libjpeg-turbo.
Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't. This pixbuf loader bug is just one example. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 04/11/10 17:53, Andrew Jorgensen escribió:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote:
It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or libjpeg-turbo.
Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements.
Oh really ? the LSB is non-sense. what good reasons ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Really? - according to " http://www.desktoplinux.com/news/NS7478724750.html"Free Standards Group (FSG) and Linux Standard Base (LSB) The first LSB 3.1 certified desktop distribution is expected to come from _Xandros_ http://www.xandros.com/, on May 1st. Other major Linux distributors such as Red Hat, Novell, Ubuntu, the _DCC Alliance_ http://www.desktoplinux.com/news/NS6183381808.html members, and others also plan to certify their versions of Linux to LSB 3.1, FSG added. On 11/04/2010 04:06 PM, Cristian Rodríguez wrote:
El 04/11/10 17:53, Andrew Jorgensen escribió:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote:
It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or libjpeg-turbo. Thats correct, mainly due to LSB requirements, which we chose to ignore. I'm going to recommend that we stop ignoring LSB requirements. Oh really ? the LSB is non-sense. what good reasons ?
-- 73 de Donn Washburn 307 Savoy Street Email:" n5xwb@comcast.net " Sugar Land, TX 77478 LL# 1.281.242.3256 Ham Callsign N5XWB HAMs : " n5xwb@arrl.net " VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg BMW MOA #: 4146 - Ambassador " http://counter.li.org " #279316 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Donn,
That's from 2006. You might look for a more recent comment.
Greg
On Thu, Nov 4, 2010 at 5:24 PM, Donn Washburn
Really? - according to " http://www.desktoplinux.com/news/NS7478724750.html"Free Standards Group (FSG) and Linux Standard Base (LSB)
The first LSB 3.1 certified desktop distribution is expected to come from _Xandros_ http://www.xandros.com/, on May 1st. Other major Linux distributors such as Red Hat, Novell, Ubuntu, the _DCC Alliance_ http://www.desktoplinux.com/news/NS6183381808.html members, and others also plan to certify their versions of Linux to LSB 3.1, FSG added.
On 11/04/2010 04:06 PM, Cristian Rodríguez wrote:
El 04/11/10 17:53, Andrew Jorgensen escribió:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote:
It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or libjpeg-turbo.
Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements.
Oh really ? the LSB is non-sense. what good reasons ?
-- 73 de Donn Washburn 307 Savoy Street Email:" n5xwb@comcast.net " Sugar Land, TX 77478 LL# 1.281.242.3256 Ham Callsign N5XWB HAMs : " n5xwb@arrl.net " VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg BMW MOA #: 4146 - Ambassador " http://counter.li.org " #279316
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 04 November 2010, Andrew Jorgensen wrote:
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't. This pixbuf loader bug is just one example.
The same bug / crash happens with all qt4 based apps that (accidentally) load the system-installed libqt4 - as it is build against libjpeg.so.8, while binaries are usually build against libjpeg6, which causes a crash. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2010/11/4 Andrew Jorgensen
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote:
It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or libjpeg-turbo.
Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't.
That's OK as long as someone cares. And seeing the sorry state of the lsb package from openSUSE 11.3 I'm pretty sure nobody cares enough. - "libpng >= 1.2"? libpng14-14-1.4.3 provides that - What about libjpeg? Isn't just that we don't guarantee the soname will be correct, we don't even guarantee a jpeg library will be installed As always, any volunteers?
This pixbuf loader bug is just one example.
There are lots of libraries that aren't under LSB that also change sonames maintaining some symbols. Solve the problem only for LSB will not help with all the binaries out there that use extra libraries. Symbol versioning is the solution (but ideally upstream should do that). The pixbuf loader bug would have never happened in Debian because: - Debian version $ objdump -T libjpeg.so.62 | fgrep jpeg_mem_init 000000000001d230 g DF .text 0000000000000006 LIBJPEG_6.2 jpeg_mem_init - openSUSE 11.3 version $ objdump -T /usr/lib64/libjpeg.so.62 | fgrep jpeg_mem_init 000000000001cac0 g DF .text 0000000000000003 Base jpeg_mem_init -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 04/11/10 22:14, Cristian Morales Vega escribió:
There are lots of libraries that aren't under LSB that also change sonames maintaining some symbols. Solve the problem only for LSB will not help with all the binaries out there that use extra libraries.
..And that is one scenario when the ABI compatibility this LSB thing is marketing,goes straight to hell.
Symbol versioning is the solution (but ideally upstream should do that). The pixbuf loader bug would have never happened in Debian because:
- Debian version $ objdump -T libjpeg.so.62 | fgrep jpeg_mem_init 000000000001d230 g DF .text 0000000000000006 LIBJPEG_6.2 jpeg_mem_init
- openSUSE 11.3 version $ objdump -T /usr/lib64/libjpeg.so.62 | fgrep jpeg_mem_init 000000000001cac0 g DF .text 0000000000000003 Base jpeg_mem_init
Ok, now we have a clue, question is how we implement a solution like this... first step if to figure out why this symbol is exported(!) in the first place.. AFAICS it is a private function... and should be guarded with __visibility__("hidden") or I am missing something ? Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 05/11/10 00:00, Cristian Rodríguez escribió:
Ok, now we have a clue, question is how we implement a solution like this... first step if to figure out why this symbol is exported(!) in the first place.. AFAICS it is a private function... and should be guarded with __visibility__("hidden") or I am missing something ?
The fun doesnt end here ;) we have TWO different libraries exporting jpeg_mem_init... scanelf -lpqs +jpeg_mem_init jpeg_mem_init /usr/lib64/libjpeg.so.8.0.1 jpeg_mem_init /usr/lib64/libgs.so.8.70 objdump -T /usr/lib64/libgs.so.8.70| fgrep jpeg_mem_init 000000000012e980 g DF .text 0000000000000003 Base jpeg_mem_init objdump -T /usr/lib64/libjpeg.so.8.0.1| fgrep jpeg_mem_init 000000000002f320 g DF .text 0000000000000003 LIBJPEG_8.0 jpeg_mem_init at least the latter is versioned.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 05/11/10 08:28, Cristian Rodríguez escribió:
El 05/11/10 00:00, Cristian Rodríguez escribió:
Ok, now we have a clue, question is how we implement a solution like this... first step if to figure out why this symbol is exported(!) in the first place.. AFAICS it is a private function... and should be guarded with __visibility__("hidden") or I am missing something ?
The fun doesnt end here ;) we have TWO different libraries exporting jpeg_mem_init...
scanelf -lpqs +jpeg_mem_init
jpeg_mem_init /usr/lib64/libjpeg.so.8.0.1 jpeg_mem_init /usr/lib64/libgs.so.8.70
Submit request 52251 should "fix" this problem in jpeg8, now we have to tell ghostscript to stop exporting symbols of other libraries... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 04 November 2010 21:53:38 Andrew Jorgensen wrote:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote:
It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or libjpeg-turbo.
Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't. This pixbuf loader bug is just one example.
There are different ways to fullfill LSB. For LSB it suffices if we have libjpeg6 available so that applications build against it work. We can still use libjpeg8 as default jpeg library. I'm assuming that v6 and v8 have different sonames... Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Jaeger wrote:
On Thursday 04 November 2010 21:53:38 Andrew Jorgensen wrote:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote:
It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or libjpeg-turbo.
Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't. This pixbuf loader bug is just one example.
There are different ways to fullfill LSB. For LSB it suffices if we have libjpeg6 available so that applications build against it work. We can still use libjpeg8 as default jpeg library. I'm assuming that v6 and v8 have different sonames...
Both libraries may nevertheless end up in the same process if a binary is linked against libjpeg6 as well as another distro provided lib that links against libjpeg8. Result is a crash due to clashing symbol names. IOW the application no longer works even though it only links against LSB libraries. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 05 November 2010 08:44:19 Ludwig Nussel wrote:
Andreas Jaeger wrote:
On Thursday 04 November 2010 21:53:38 Andrew Jorgensen wrote:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote:
It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or libjpeg-turbo.
Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't. This pixbuf loader bug is just one example.
There are different ways to fullfill LSB. For LSB it suffices if we have libjpeg6 available so that applications build against it work. We can still use libjpeg8 as default jpeg library. I'm assuming that v6 and v8 have different sonames...
Both libraries may nevertheless end up in the same process if a binary is linked against libjpeg6 as well as another distro provided lib that links against libjpeg8. Result is a crash due to clashing symbol names. IOW the application no longer works even though it only links against LSB libraries.
Exactly. so, the question in this case should not be LSB compliance but what to do with libjpeg. From the previous discussion, it looks like going back to libjpeg6 or libjpeg-turbo might solve a couple of problems our users get with third party software - so let's do it. Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 5 Nov 2010, Andreas Jaeger wrote:
On Friday 05 November 2010 08:44:19 Ludwig Nussel wrote:
Andreas Jaeger wrote:
On Thursday 04 November 2010 21:53:38 Andrew Jorgensen wrote:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote:
It seems only Arch and openSUSE have 8.0, all of the rest uses v6 or libjpeg-turbo.
Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't. This pixbuf loader bug is just one example.
There are different ways to fullfill LSB. For LSB it suffices if we have libjpeg6 available so that applications build against it work. We can still use libjpeg8 as default jpeg library. I'm assuming that v6 and v8 have different sonames...
Both libraries may nevertheless end up in the same process if a binary is linked against libjpeg6 as well as another distro provided lib that links against libjpeg8. Result is a crash due to clashing symbol names. IOW the application no longer works even though it only links against LSB libraries.
Exactly.
so, the question in this case should not be LSB compliance but what to do with libjpeg. From the previous discussion, it looks like going back to libjpeg6 or libjpeg-turbo might solve a couple of problems our users get with third party software - so let's do it.
Adopting a symbol versioning scheme would also do the trick. The trick
is of course to choose one that matches what other distros do or
to convince upstream to provide one. It's really not _that_ hard.
Richard.
--
Richard Guenther
On Fri, Nov 05, 2010 at 10:59:07AM +0100, Richard Guenther wrote:
On Fri, 5 Nov 2010, Andreas Jaeger wrote:
On Friday 05 November 2010 08:44:19 Ludwig Nussel wrote:
Andreas Jaeger wrote:
On Thursday 04 November 2010 21:53:38 Andrew Jorgensen wrote:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote:
On Thursday 04 November 2010, Pavol Rusnak wrote: > It seems only Arch and openSUSE have 8.0, all of the rest uses > v6 or libjpeg-turbo.
Thats correct, mainly due to LSB requirements, which we chose to ignore.
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't. This pixbuf loader bug is just one example.
There are different ways to fullfill LSB. For LSB it suffices if we have libjpeg6 available so that applications build against it work. We can still use libjpeg8 as default jpeg library. I'm assuming that v6 and v8 have different sonames...
Both libraries may nevertheless end up in the same process if a binary is linked against libjpeg6 as well as another distro provided lib that links against libjpeg8. Result is a crash due to clashing symbol names. IOW the application no longer works even though it only links against LSB libraries.
Exactly.
so, the question in this case should not be LSB compliance but what to do with libjpeg. From the previous discussion, it looks like going back to libjpeg6 or libjpeg-turbo might solve a couple of problems our users get with third party software - so let's do it.
Adopting a symbol versioning scheme would also do the trick. The trick is of course to choose one that matches what other distros do or to convince upstream to provide one. It's really not _that_ hard.
libjpeg8 has at least started one. Not sure how Debian does implement the versioning for libjpeg6, it seems to do it at least. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2010/11/5 Marcus Meissner
On Fri, Nov 05, 2010 at 10:59:07AM +0100, Richard Guenther wrote:
On Fri, 5 Nov 2010, Andreas Jaeger wrote:
On Friday 05 November 2010 08:44:19 Ludwig Nussel wrote:
Andreas Jaeger wrote:
On Thursday 04 November 2010 21:53:38 Andrew Jorgensen wrote:
On Thu, 2010-11-04 at 21:16 +0100, Dirk Müller wrote: > On Thursday 04 November 2010, Pavol Rusnak wrote: > > It seems only Arch and openSUSE have 8.0, all of the rest uses > > v6 or libjpeg-turbo. > > Thats correct, mainly due to LSB requirements, which we chose to > ignore.
I'm going to recommend that we stop ignoring LSB requirements. There are some very good reasons to comply with LSB and we fail when we don't. This pixbuf loader bug is just one example.
There are different ways to fullfill LSB. For LSB it suffices if we have libjpeg6 available so that applications build against it work. We can still use libjpeg8 as default jpeg library. I'm assuming that v6 and v8 have different sonames...
Both libraries may nevertheless end up in the same process if a binary is linked against libjpeg6 as well as another distro provided lib that links against libjpeg8. Result is a crash due to clashing symbol names. IOW the application no longer works even though it only links against LSB libraries.
Exactly.
so, the question in this case should not be LSB compliance but what to do with libjpeg. From the previous discussion, it looks like going back to libjpeg6 or libjpeg-turbo might solve a couple of problems our users get with third party software - so let's do it.
Adopting a symbol versioning scheme would also do the trick. The trick is of course to choose one that matches what other distros do or to convince upstream to provide one. It's really not _that_ hard.
libjpeg8 has at least started one.
Not sure how Debian does implement the versioning for libjpeg6, it seems to do it at least.
I have been looking better at this. The http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps thing that I linked before isn't about versioning symbols as I misunderstood. It's just a way to map package versions with new symbols, so an automatic script looks at a binary, sees it requires a symbol that was introduced in version 1.2 of libA and so makes the package depend on "libA >= 1.2". It's basically the same than symbol versioning, but external and without the pixbuf bugfixing capabilities. The cause Debian's libjpeg62 package uses symbol versioning is because of http://www.mail-archive.com/debian-release@lists.debian.org/msg35322.html. They were more prudent than us with the libjpeg8 transition and made upstream release a new version, 6b1, with symbol versioning. The only problem is that I don't know where to obtain that 6b1 version anymore (http://www.ijg.org/files/ only has version 8). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (10)
-
Andreas Jaeger -
Andrew Jorgensen -
Cristian Morales Vega -
Cristian Rodríguez -
Dirk Müller -
Donn Washburn -
Greg Freemyer -
Ludwig Nussel -
Marcus Meissner -
Richard Guenther