Gimp JPEG error
Gimp JPEG error
I have downloaded two versions of gimp pets and both report errors reading jpg messages.
wrong JPEG Library version : library is 70, caller expect 62.
Which is a nonstarter as Digital camera images are JPG in most instances.
I would think that a later library 70 would be backword compatible with the 62 one, but apparently now I guess.
Any advise, direction, links for further information?
wrong JPEG Library version : library is 70, caller expect 62.
Which is a nonstarter as Digital camera images are JPG in most instances.
I would think that a later library 70 would be backword compatible with the 62 one, but apparently now I guess.
Any advise, direction, links for further information?
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
I had a similar error when I tried updating GTK+ to the latest version (2.18.5) on a machine on which I had previously updated libjpeg from libjpeg62 to libjpeg7. Gone was the desktop background image, and when I tried to drop the desired background image (from /usr/share/backgrounds) onto the drop window in the (right-click lock icon)-->backdrop utility, I saw that same error message.
Re-installing (i.e. recompiling) libjpeg62 (with both --enable-static and --enable-shared), and then reinstalling GTK+, brought back my desktop background, eliminating the error message.
Right now I'm experimenting with combinations of libjpeg7 and GTK+ 2.18.5 with a 2.18.3 patch from linuxfromscratch, to see if this patch eliminates the error message.
Be back when I have definite results. GTK+ takes awhile to compile.
Meanwhile...this same error message was reported in a different context at
http://bbs.archlinux.org/viewtopic.php?id=75992
The workaround found was to pre-load the correct libjpeg-- you would change the name of the binary from, say, "gimp" to "gimp-binary" and then in the same subdir create a bash script named "gimp" which pre-loads the right libjpeg, see the post in the above-mentioned Arch thread by Arch user hbekel --it for gimp would consist of
The suggestion was made, to place libjpeg.so.62.0.0 (and point the above LD_PRELOAD line) into some non-standard place, e.g. /usr/local/lib/libjpeg.so.62.0.0, so that libjpeg7 will ordinarily be found first. This way, apps which were compiled to expect libjpeg7 get it, and apps which expect libjpeg62 can be started with an LD_PRELOAD bash script.
But this is terribly clumsy...an individual start-script for every app which expects libjpeg62, yuk.
As I say, I'll be back when I've found the general solution. It could be that gimp needs simply to be compiled on a machine with the same GTK+ and libjpeg (and /lib/libc.so.6) as the target machine, in order to work, i.e. maybe the LD_PRELOAD trick won't work.
Re-installing (i.e. recompiling) libjpeg62 (with both --enable-static and --enable-shared), and then reinstalling GTK+, brought back my desktop background, eliminating the error message.
Right now I'm experimenting with combinations of libjpeg7 and GTK+ 2.18.5 with a 2.18.3 patch from linuxfromscratch, to see if this patch eliminates the error message.
Be back when I have definite results. GTK+ takes awhile to compile.
Meanwhile...this same error message was reported in a different context at
http://bbs.archlinux.org/viewtopic.php?id=75992
The workaround found was to pre-load the correct libjpeg-- you would change the name of the binary from, say, "gimp" to "gimp-binary" and then in the same subdir create a bash script named "gimp" which pre-loads the right libjpeg, see the post in the above-mentioned Arch thread by Arch user hbekel --it for gimp would consist of
Code: Select all
#!/bin/sh
LD_PRELOAD=/wherever-it-exists, probably /usr/lib/libjpeg.so.62.0.0 gimp-binary &
But this is terribly clumsy...an individual start-script for every app which expects libjpeg62, yuk.
As I say, I'll be back when I've found the general solution. It could be that gimp needs simply to be compiled on a machine with the same GTK+ and libjpeg (and /lib/libc.so.6) as the target machine, in order to work, i.e. maybe the LD_PRELOAD trick won't work.
Last edited by Sit Heel Speak on Tue 09 Feb 2010, 22:00, edited 1 time in total.
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
OK, further news. When I do the following:
1. Install libjpeg7
2. Install GTK+ 2.18.5 with the LFS 2.18.3 jpeg patch
the desktop background image no longer disappears, and attempts to replace the background image as described above, succeed.
The downsides are:
1. The patch does not automatically apply, i.e. I had to hand-edit the sourcefile gdk-pixbuf/io-jpeg.c because io-jpeg.c has changed too much from 2.18.3 to 2.18.5 for the patch utility to find the appropriate code-snippet to work on. The edit is fairly trivial though.
2. I don't know yet, whether this would be a general solution for apps which were compiled to expect libjpeg62.
Can you point me to the problematic gimp .pet, so I can try it?
1. Install libjpeg7
2. Install GTK+ 2.18.5 with the LFS 2.18.3 jpeg patch
the desktop background image no longer disappears, and attempts to replace the background image as described above, succeed.
The downsides are:
1. The patch does not automatically apply, i.e. I had to hand-edit the sourcefile gdk-pixbuf/io-jpeg.c because io-jpeg.c has changed too much from 2.18.3 to 2.18.5 for the patch utility to find the appropriate code-snippet to work on. The edit is fairly trivial though.
2. I don't know yet, whether this would be a general solution for apps which were compiled to expect libjpeg62.
Can you point me to the problematic gimp .pet, so I can try it?
Gimp Jpeg Error followup
Wow a complicated thing.
I downloaded from package 4
gimp-2.4.0-rc3.pet
I downloaded from package 4
gimp-2.4.0-rc3.pet
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
Hang on...the gimp .pet installs OK here, on my
upup-with-libjpeg7-plus-GTK+-2.18.5-with-the-2.18.3-BLFS-jpeg-patch...
...however, gimp fails to start. I get the error
gimp: symbol lookup error: /usr/lib/libX11.so.6: undefined symbol: xcb_take_sock
so I presume I will have to install libxcb and its dependencies first. Wait...
What Puppy are you running? Have you tried the LD_PRELOAD trick?
upup-with-libjpeg7-plus-GTK+-2.18.5-with-the-2.18.3-BLFS-jpeg-patch...
...however, gimp fails to start. I get the error
gimp: symbol lookup error: /usr/lib/libX11.so.6: undefined symbol: xcb_take_sock
so I presume I will have to install libxcb and its dependencies first. Wait...
What Puppy are you running? Have you tried the LD_PRELOAD trick?
Gimp Jpeg Error followup
I am using MyWolf-008. No I haven't tried the preload thing yet. Thanks for your efforts your detail is a bit beyond my pay grade at this stage, but I am learning from what you do.
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
After installing xcb-proto and then libxcb per the Linux From Scratch instructions, gimp from the .pet starts and runs just fine, on my
upup-with-libjpeg7-plus-GTK+-2.18.5-with-the-2.18.3-BLFS-jpeg-patch.
I can see that what I must do, in order to furnish a useful fix, is, I must find and download MyWolf-008 and try it. Have you modified it in any significant way, e.g. added libjpeg7, or was it supplied with same?
upup-with-libjpeg7-plus-GTK+-2.18.5-with-the-2.18.3-BLFS-jpeg-patch.
I can see that what I must do, in order to furnish a useful fix, is, I must find and download MyWolf-008 and try it. Have you modified it in any significant way, e.g. added libjpeg7, or was it supplied with same?
gimp preload
I tried the preload but the 62 file in my system points to the 70. No can do.
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
It'll be a few hours, I'm on only a 512kbps connection.
Based on the clues so far, I'm about 85% certain that the fix will turn out to be, to recompile gtk+ with the above-mentioned jpeg patch from BLFS.
Programs, libraries, and directories installed when you compile gtk+ total more than two dozen in number, scattered all over the filesystem, terribly time-consumptive to furnish as a .pet. It is do-able, but might take me a week.
So, if it turns out to require gtk+ to have the BLFS jpeg patch to work, then the best I can do is give you step-by-step instructions for a DIY compile. I hope you are using a frugal install or else live-CD with an on-disk savefile.
While waiting, grab the devx, if you don't already have it.
Based on the clues so far, I'm about 85% certain that the fix will turn out to be, to recompile gtk+ with the above-mentioned jpeg patch from BLFS.
Programs, libraries, and directories installed when you compile gtk+ total more than two dozen in number, scattered all over the filesystem, terribly time-consumptive to furnish as a .pet. It is do-able, but might take me a week.
So, if it turns out to require gtk+ to have the BLFS jpeg patch to work, then the best I can do is give you step-by-step instructions for a DIY compile. I hope you are using a frugal install or else live-CD with an on-disk savefile.
While waiting, grab the devx, if you don't already have it.
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
(composing, check back in an hour --***EDITED check back tomorrow afternoon; MyWolfe-008 is missing a few more parts besides just an adequate gtk+ and libjpeg7***)
- Attachments
-
- io-jpeg.c.gz
- io-jpeg.c patched for libjpeg7
- (10.44 KiB) Downloaded 360 times
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
Still here, check back tonight. Instead of having you do a DIY compile, I will just supply a gimp .sfs for MyWolfe-008.
There are 41 supporting packages needed, mostly to fill-in gaps in order to bring X up to snuff so that the combination of gimp + libjpeg7 can interface to X. Some unknown number of these supporting packages are no doubt present (maybe up-to-date, maybe not) in MyWolfe-008, but it would be too much bother to individually inspect to see which ones he left out or are not current. So, I will just install them all into a fresh frugal, then unsquash the savefile and convert its contents into an .sfs.
Minor complaint: he forgot to include Boot Manager and Resize Personal Storage File in the menu. Grrr...
Also there has been some delay due to the fact that the provider's website for one of the dependencies, libxml2, www.xmlsoft.org, is down. Perhaps due to the Atlantic Seaboard blizzards. Fortunately, I have the current libxml2 source on a backup CD.
***EDITED just using this post as a temporary scratchpad:
Memo to self: next time, when adding or upgrading X libraries on someone else's Puppy, first be sure to add the following three lines to /etc/profile:
XORGCONFIG=/etc/X11/xorg.conf
XORG_CONFIG='--prefix=/usr/X11R7 --sysconfdir=/etc --mandir=/usr/X11R7/share/man --localstatedir=/var'
XORG_PREFIX=/usr/X11R7
***
Back in 12.
There are 41 supporting packages needed, mostly to fill-in gaps in order to bring X up to snuff so that the combination of gimp + libjpeg7 can interface to X. Some unknown number of these supporting packages are no doubt present (maybe up-to-date, maybe not) in MyWolfe-008, but it would be too much bother to individually inspect to see which ones he left out or are not current. So, I will just install them all into a fresh frugal, then unsquash the savefile and convert its contents into an .sfs.
Minor complaint: he forgot to include Boot Manager and Resize Personal Storage File in the menu. Grrr...
Also there has been some delay due to the fact that the provider's website for one of the dependencies, libxml2, www.xmlsoft.org, is down. Perhaps due to the Atlantic Seaboard blizzards. Fortunately, I have the current libxml2 source on a backup CD.
***EDITED just using this post as a temporary scratchpad:
Memo to self: next time, when adding or upgrading X libraries on someone else's Puppy, first be sure to add the following three lines to /etc/profile:
XORGCONFIG=/etc/X11/xorg.conf
XORG_CONFIG='--prefix=/usr/X11R7 --sysconfdir=/etc --mandir=/usr/X11R7/share/man --localstatedir=/var'
XORG_PREFIX=/usr/X11R7
***
Back in 12.
Last edited by Sit Heel Speak on Thu 11 Feb 2010, 22:48, edited 1 time in total.
Boot manager personal file size manager
I thought so too initially but both are there in the control panel in MyWolfe-008.
The bootmanger in the system tab. and the personal file size manager in the utility tab.
You didn't have to go to all this effort on my behalf. Thanks.
The bootmanger in the system tab. and the personal file size manager in the utility tab.
You didn't have to go to all this effort on my behalf. Thanks.
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
Partial success.
The chronicle so far:
1. Installed libjpeg7 fresh.
2. Replaced all the X library dependencies of gtk+.
3. Installed the newest gtk+ 2.18.5, with the jpeg patch.
--The gimp .pet still would not open a jpeg. There is no error message when started from a console window, but it still produces that libjpeg62-libjpeg7 error message.
4. Uninstalled the gimp .pet and compiled gimp 2.4.3 from source.
--Same result as from the .pet. Gimp starts, but will not open a jpeg.
5. Tried compiling the last 2.4 gimp (2.4.7) from source.
--The preview on some jpeg's shows, on some doesn't. But it does open a jpeg for editing, as shown above, no matter whether the File-Open window shows the preview or not.
6. Tried compiling the newest stable gimp, 2.6.8.
--It has a new dependency, gegl, which will not make under MyWolfe's gcc.
My upup, heavily modified, is based on a December woof build, so it carries the same /lib/libc.so.6 (2.10.1) as MyWolfe. But both X and the gimp dependencies were compiled by me with a newer version of gcc (4.4.1) than MyWolfe carries (4.3.4). Both gimp 2.4rc3 from the .pet and gimp 2.6.8 do show all previews (and open all jpeg's) on my upup.
11:30 PM here now, too late to start the .sfs conversion. Back tomorrow afternoon, hopefully with an .sfs.
The chronicle so far:
1. Installed libjpeg7 fresh.
2. Replaced all the X library dependencies of gtk+.
3. Installed the newest gtk+ 2.18.5, with the jpeg patch.
--The gimp .pet still would not open a jpeg. There is no error message when started from a console window, but it still produces that libjpeg62-libjpeg7 error message.
4. Uninstalled the gimp .pet and compiled gimp 2.4.3 from source.
--Same result as from the .pet. Gimp starts, but will not open a jpeg.
5. Tried compiling the last 2.4 gimp (2.4.7) from source.
--The preview on some jpeg's shows, on some doesn't. But it does open a jpeg for editing, as shown above, no matter whether the File-Open window shows the preview or not.
6. Tried compiling the newest stable gimp, 2.6.8.
--It has a new dependency, gegl, which will not make under MyWolfe's gcc.
My upup, heavily modified, is based on a December woof build, so it carries the same /lib/libc.so.6 (2.10.1) as MyWolfe. But both X and the gimp dependencies were compiled by me with a newer version of gcc (4.4.1) than MyWolfe carries (4.3.4). Both gimp 2.4rc3 from the .pet and gimp 2.6.8 do show all previews (and open all jpeg's) on my upup.
11:30 PM here now, too late to start the .sfs conversion. Back tomorrow afternoon, hopefully with an .sfs.
- Sit Heel Speak
- Posts: 2595
- Joined: Fri 31 Mar 2006, 03:22
- Location: downwind
gimp 2.4.7 for MyWolfe-008
Download:
http://myfreefilehosting.com/f/d966acca8c_45.32MB
md5sum:
# md5sum gimp-2.4.7.sfs
41578da375e59a2a7c6fd397497a32ed gimp-2.4.7.sfs
size: 47,517,696 bytes.
The preview problem is solved, it was missing one additional dependency.
Announcement here.
http://myfreefilehosting.com/f/d966acca8c_45.32MB
md5sum:
# md5sum gimp-2.4.7.sfs
41578da375e59a2a7c6fd397497a32ed gimp-2.4.7.sfs
size: 47,517,696 bytes.
The preview problem is solved, it was missing one additional dependency.
Announcement here.
similar problem
I suddenly got the wrong libjpeg version error. I think i may have caused it by running ldconfig. What I found was for some reason /usr/lib/libjpeg.so.8 which is a link, pointed to an older version of libjpeg. I removed the link and recreated it with ln -s and everything seems normal again. Note that even though libjpeg.so was ok the libjeg.so.8 was not and was the source of the problem.
Thanks to previous posters, I was able to gather the clues i needed.
Thanks to previous posters, I was able to gather the clues i needed.