We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1684 - SDL_image fails to load an image with libpng-compat installed
Summary: SDL_image fails to load an image with libpng-compat installed
Status: RESOLVED FIXED
Alias: None
Product: SDL_image
Classification: Unclassified
Component: misc (show other bugs)
Version: unspecified
Hardware: x86_64 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-09 13:38 UTC by David North
Modified: 2013-06-08 00:56 UTC (History)
2 users (show)

See Also:

Attachments
config.log with both libpng 1.2 and 1.6 installed, default configure options (30.86 KB, text/plain)
2013-06-07 13:13 UTC, Yaohan Chen 		Details
config.log with both libpng 1.2 and 1.6 installed, --disable-png-shared (30.82 KB, text/plain)
2013-06-07 13:15 UTC, Yaohan Chen 		Details
config.log with libpng 1.6 installed, and without libpng 1.2 installed (30.87 KB, text/plain)
2013-06-07 13:17 UTC, Yaohan Chen 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David North 2013-01-09 13:38:25 UTC 
Building SDL_image latest (from Mecurial) with libpng-compat installed under Fedora 17 causes PNG files (that worked perfectly well under SDL 1.2) to return NULL.

I am calling the method IMG_LoadTexture, but I believe the actual problem resides in IMG_Load

The error returned is 'undefined symbol: _png_set_longjmp_fn'

libpng-compat is installed with Google Chrome, and so it took a little bit of tracking down in order to find the offending package.

I've fixed it now by removing libpngt-compat and recompiling SDL_image, but if there is any other information you require, please let me know
Comment 1 Sam Lantinga 2013-06-03 01:57:38 UTC 
Can you download the source and send me the output of configure with and without libpng-compat installed?

My guess is that it's finding newer libpng headers, and finding the old png library and using that as the one to load.
Comment 2 Yaohan Chen 2013-06-07 13:13:23 UTC 
Created attachment 1182 [details]
config.log with both libpng 1.2 and 1.6 installed, default configure options
Comment 3 Yaohan Chen 2013-06-07 13:15:34 UTC 
Created attachment 1183 [details]
config.log with both libpng 1.2 and 1.6 installed, --disable-png-shared
Comment 4 Yaohan Chen 2013-06-07 13:17:44 UTC 
Created attachment 1184 [details]
config.log with libpng 1.6 installed, and without libpng 1.2 installed
Comment 5 Yaohan Chen 2013-06-07 13:32:20 UTC 
I also have this problem on Arch Linux. I have the following library files owned by the libpng 1.6 and 1.2 packages:

libpng 1.6
/usr/lib/libpng.so
/usr/lib/libpng16.so
/usr/lib/libpng16.so.16
/usr/lib/libpng16.so.16.2.0

libpng 1.2
/usr/lib/libpng.so.3
/usr/lib/libpng.so.3.50.0
/usr/lib/libpng12.so
/usr/lib/libpng12.so.0
/usr/lib/libpng12.so.0.50.0

With both packages installed, configure will by default generate both -lpng and -lpng.so.3. With both packages installed and --disable-png-shared, configure will generate only -lpng, which produces a working build for me. With libpng 1.2 removed, it also produces a working build.

The problem seems to be due to in lines 218 to 226 of configure.in:
                png_lib=[`find_lib "libpng.so.[0-9]"`]
                if test x$png_lib = x; then
                    png_lib=[`find_lib "libpng.so.[0-9]*"`]
                fi
                if test x$png_lib = x; then
                    png_lib=[`find_lib "libpng*.so.[0-9]"`]
                fi
                if test x$png_lib = x; then
                    png_lib=[`find_lib "libpng*.so.[0-9]*"`]
                fi
This matches libpng.so.3 but not ligpng.so. Maybe this is not even necessary since another part of configure uses pkg-config to get flags for libpng 1.6 correctly.
Comment 6 Sam Lantinga 2013-06-08 00:56:18 UTC 
Okay, this should be fixed.
http://hg.libsdl.org/SDL_image/rev/2608ba5feac1

Please let me know if this doesn't work or breaks something else.

Thanks!