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

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 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

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 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 <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

2010/11/5 Marcus Meissner <meissner@suse.de>:

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

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

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