Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 27 users
Status: WontFix
Owner: ----
Closed: May 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
Use our own copy of libjpeg with internal-only symbol names for Google Chrome binaries
Project Member Reported by evan@chromium.org, Jan 2 2010 Back to list
People are running our binaries built against the system libjpeg6 on 
systems with GTK built against libjpeg7.  This ends in tears (the symptom 
is crashing when GTK starts loading jpegs in the file picker).  See issue 
30288.

Options:
1) Start building a new second set of packages for the four configurations 
we currently support that rely on libjpeg7 instead.  This seems terrible, 
particularly since no users will understand how to install them, so I'm 
gonna title this bug with the only other option I see:

2) Make our binaries go back to bundling libjpeg6, being careful that 
there's no chance of getting these symbols mixed (I think visibility=hidden 
should cover it, but maybe we have to mangle them).

I'd like to be convinced of some better third option.


...hm, I just thought of one:
3) Add one more set of packages that are more heavily statically linked, 
for people who insist on running our binaries on systems we haven't tested 
on.  However, this libjpeg6/7 thing is gonna start screwing us on at least 
newer Debians so I don't think it'd really work.
 
Comment 1 by evan@chromium.org, Jan 2 2010
Labels: OS-Linux
Comment 2 by spo...@gmail.com, Jan 2 2010
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).
Comment 3 by spo...@gmail.com, Jan 2 2010
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.
Comment 4 by evan@chromium.org, Jan 2 2010
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
Comment 6 by evan@chromium.org, Jan 5 2010
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.
Labels: Mstone-5
Status: Available
Comment 8 by Deleted ...@, Jan 29 2010
"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
Comment 9 by Deleted ...@, Jan 29 2010
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, :)
Labels: -Area-Undefined autoclass Area-UI
Using an automated filter to classify this issue into an area...gulp
Comment 12 by evan@chromium.org, Feb 19 2010
Labels: -autoclass -Area-UI Area-Internals
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.
Comment 14 by sanda...@gmail.com, Mar 30 2010
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.
Comment 15 by evan@chromium.org, Apr 6 2010
 Issue 36739  has been merged into this issue.
Status: Assigned
Comment 17 by evan@chromium.org, Apr 7 2010
I don't think we care about this for m5 unless it affects Debian users, which it 
might.  :(
Labels: -Mstone-5 Mstone-6
Status: Available
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.
Comment 19 by evan@chromium.org, Apr 7 2010
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.
Comment 22 by e...@chromium.org, May 3 2010
 Issue 34706  has been merged into this issue.
Comment 23 by raev...@gmail.com, May 17 2010
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.
Comment 24 by evan@chromium.org, May 17 2010
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).
Labels: -Mstone-6 Mstone-X
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.
Comment 29 by tos...@gmail.com, Oct 26 2010
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...
Comment 35 by thkru...@gmail.com, Dec 13 2010
Indeed, I just got bitten by it _again_
Project Member Comment 36 by bugdroid1@chromium.org, Jan 13 2011
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.
Comment 38 by evan@chromium.org, May 12 2011
Status: WontFix
Agreed.
Project Member Comment 39 by bugdroid1@chromium.org, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
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.
Project Member Comment 40 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals Cr-Internals
Sign in to add a comment