I'd note that if Chromium had some sort of configuration step before compilation, it
could force a version of libjpeg to be present at build time.

For your binaries, I'd think the obvious option would be to build against libjpeg7,
and link it statically into your binary bits (unless something breaks when gtk is
built with libjpeg6, which is the case in all Fedora releases atm).

And for clarification, when I say "For your binaries", I mean "the Google Chrome
official builds". Please don't bundle libjpeg6 back into the chromium codebase just
for this.

I think even with a configure step we're screwed, since these systems seem to have 
libjpeg6 and 7 both installed (they have different sonames, after all).  What we 
really care about is which one GTK was compiled against.

(I have this nagging feeling I'm missing something here.  Is it really the case that 
code using two versions of the same library should cause problems like this?  I can't 
seen any technical reason why it *shouldn't* cause problems...)

For reference, this has been reported for Gentoo: http://bugs.gentoo.org/297159

We discussed this at great length -- investigating options like trying to make our 
code work with both ABIs simultaneously (we don't use obscure features of libjpeg) -- 
and concluded we should do #2 for Google Chrome-branded builds.

It also means that we can upgrade to libjpeg7 before distros do.  agl is a graphics 
compression master on the side and claims the arithmetic encoding they added in 7 
makes it compress as well as jpeg2000.

"The current version is release 8 of 10-Jan-2010"

http://www.ijg.org/files/jpegsrc.v8.tar.gz

Please don't use libjpeg.so.62 anymore, because if it's mixed with libjpeg.so.7 or
libjpeg.so.8 there will be a namespace collision. It will cause programs to
segmentation fault in decompress function. 

Also, it doesn't make sense to use jpeg-7 anymore either, it's deprecated, you should
go directly to jpeg-8, which is the current version and also the version Gentoo Linux
is already using, and from past experience, that's what Arch Linux is going to use
next, then followed by Debian.

In short: Please forget about jpeg-6b, forget about jpeg-7, and use the latest stable
upstream release, jpeg-8

Indeed, you could statically link jpeg-8 to the binary version, that would work for
everyone, and you'd be using the latest

Just leave the option to use system jpeg for non-binary version, :)

http://packages.debian.org/sid/libjpeg8

Using an automated filter to classify this issue into an area...gulp

Just a ping, I'm using a prebuilt 5.0.340.0 (40234) for linux x86_64 on Archlinux and 
it's still built with libjpeg.so.62 according to ldd. I have libjpeg.so.62, 
libjpeg.so.7 and libjpeg.so.8 on board and Chromium segfaults as soon as I select a 
JPEG in the file selector to upload.

I opened http://code.google.com/p/chromium/issues/detail?id=36739 when I was running
into this issue, which may be a duplicate of this bug.

 Issue 36739  has been merged into this issue.

I don't think we care about this for m5 unless it affects Debian users, which it 
might.  :(

This also affects Mandriva 2010, which Google Chrome doesn't officially support. 
They're shipping with libjpeg 7, which satisfies the lsb dependency the google-chrome 
rpm requires, but doesn't provide the lib we actually need.

I am punting this for m5. Most Linux users still have 6.2, so we are ok. We should fix 
this before the next milestone though. By then, more distros will have upgraded their 
libjpeg.

In fact, as soon as we drop hardy support, we might be able to just build only with 
libjpeg7.

FYI, ubuntu lucid (next LTS, soon to be released) doesn't support libjpeg7.

See https://bugs.launchpad.net/ubuntu/+source/libjpeg6b/+bug/537370

 Issue 32180  has been merged into this issue.

 Issue 34706  has been merged into this issue.

In the meantime, is there any workaround and/or hotfix?  I could go without an image 
preview in the file picker.  Removing libjpeg7, by contrast, requires substantially 
more effort.

We have only released binaries for Debian, Ubuntu, Fedora, and openSUSE.  If you're 
encountering problems on one of those systems, I'd like to hear more about it.  
Otherwise, please ask your distribution to build Chromium for you (or build it 
yourself).

I'm using 7.0.522.0 (Developer build 59187) from the nightly builds that seems compiled against libjpeg6 and my system also uses libjpeg6. However, it crashes when trying to upload a jpg image.

Switching to libjpeg-turbo ( issue 48789 ) will solve this problem for now since most Linux distros don't package libjpeg-turbo yet.

I'm on openSuSE 11.3 and I have this problem. The library shipped by SuSE is libjpeg8-8.0.1-2.1.1.i586.

Just want to chime in and say that this is a problem for the moonlight plugin as well on any system that uses a libjpeg other than v6.  Moonlight uses gdk-pixbuf, so we end up dying the same death as the file browser, although the death is limited to the plugin itself, not the browser.

Could you please at least disable the preview in the file selection dialog? Not having a preview is less problematic than crashing during a common task (on an officially suported platform, no less).

Since the bundled libjpeg (which we don't use by default on linux) already has mangled names (third_party/libjpeg/jpeglibmangler.h), I think we can fix this issue as per option 2 and probably fix  issue 30288  too by just defaulting use_system_libjpeg to 0.

Right?

jpeg_std_message_table and jpeg_natural_order appear not to be mangled but that shouldn't be hard to fix.

Comments?

When libjpeg-turbo lands we'll have to make sure to mangle that too of course...

Patch to use internal copy of libjpeg by default with mangled symbol names is here:

http://codereview.chromium.org/4994004/

(I've posted some debug stuff on  issue 30288  as well but I haven't tried out the above patch in a failing environment yet to see if it fixes things ... it seems likely that it will)

Thanks! I hope this can be fixed soon. It makes the browser unusable for most simple things (flickr, sending pictures with gmail, etc.).

Any news here? The browser is unusable with this...

Indeed, I just got bitten by it _again_

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=71326

------------------------------------------------------------------------
r71326 | craig.schlenter@chromium.org | Thu Jan 13 08:27:46 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/libjpeg_turbo/libjpeg.gyp?r1=71326&r2=71325&pathrev=71326

Remove workaround for gyp  issue 102  and use libjpeg_turbo on Linux.

Note that you still need use_libjpeg_turbo=1 to activate for now.

BUG= 31427 , 48789 
Review URL: http://codereview.chromium.org/6181005
------------------------------------------------------------------------

I think we've switched over to libjpeg-turbo, so this can be closed.

Agreed.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.