This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch fixing several segfaults (sdl-image.patch, text/plain, 2006-07-22 00:37:49 +0000, 4889 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-07-19 08:30:52 +0000, Pierre Sarrazin wrote:

My code calls IMG_ReadXPMFromArray(char **xpm) to create an SDL_Surface from an XPM array in memory. That function calls load_xpm(xpm, NULL). That NULL is the 'src' argument, of type SDL_RWops. The first thing that load_xpm() does with 'src' is to call SDL_RWtell(src). SDL/SDL_rwops.h defines SDL_RWtell(ctx) as (ctx)->seek(ctx, 0, RW_SEEK_CUR). Since 'ctx' is null, the process crashes. This all happens in IMG_xpm.c.

This happens with SDL_image 1.2.5. Version 1.2.4 had a different implementation for load_xpm(): it called get_next_line(xpmlines, src, 0) instead of SDL_RWtell(src). get_next_line() did not use 'src' if 'xpmlines' was non-null.

On 2006-07-22 00:37:49 +0000, Michael Koch wrote:

Created attachment 150
Patch fixing several segfaults

I have got a patch for the same problem in Debian. Applications that worked with SDL_Image 1.2.4 segfaulted a lot with SDL_Image 1.2.5. The attached patch fixes this. I already use this patch in Debian and it looks okay.

On 2007-02-13 05:08:38 +0000, Ryan C. Gordon wrote:

This patch is now in Subversion (revision # 2970).

Thanks!

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• this conatins the complied binary and the source code (memleak.zip, application/x-zip-compressed, 2010-10-25 07:43:30 +0000, 2071433 bytes)

Reported in version: 1.2.10
Reported for operating system, platform: Windows 7, x86

Comments on the original bug report:

On 2010-10-25 07:43:30 +0000, Cannon wrote:

Created attachment 543
this conatins the complied binary and the source code

we have this program set up where every left click adds a ball and loads an image to the screen, they bounce around etc.

a right click deletes all the balls, however the memory footprint stays the same
have attached my project, the file classexamp.exe under Debug\bin should run and the behavior above should exist

we tried many things including explicitly calling the deconstructor and memory still wont fall

the functions that are called to create/destroy are in ball.h/ball.cpp (the Ball class )

anything further need please ask

On 2011-02-17 13:13:58 +0000, Sam Lantinga wrote:

That is a pretty cool demo!

How are you detecting the memory usage? It's possible that the OS is committing memory pages on behalf of your application and then not releasing them even though the memory has actually been freed.

I ran the test here, creating 200 balls and then deleting them, and the allocation counts seem correct:

First start:
Process 22374: 12314 nodes malloced for 9425 KB

After 200 balls created:
Process 22374: 13133 nodes malloced for 10986 KB

After the balls are deleted:
Process 22374: 12303 nodes malloced for 9438 KB

I ran this test on Mac OS X and used the "leaks" tool to detect memory leaks.

Cheers!

On 2011-12-31 09:33:48 +0000, Sam Lantinga wrote:

No response in over a year.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• A sample file (kiribati.bmp, application/octet-stream, 2006-05-13 16:10:24 +0000, 36664 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-05-13 16:06:32 +0000, Maurizio Monge wrote:

The palette of bmp files is loaded from a wrong offset in the bmp file.
I am attaching a test file (it is being loaded correcty by imagemagick, gdk-pixbuf and windows too, but not with current sdl-image).
Here is a very little patch to fix the problem:

diff -Nurb SDL_image-1.2.4-old/IMG_bmp.c SDL_image-1.2.4-new/IMG_bmp.c
--- SDL_image-1.2.4-old/IMG_bmp.c       2004-12-16 05:41:01.000000000 +0100
+++ SDL_image-1.2.4-new/IMG_bmp.c       2006-05-13 04:51:40.000000000 +0200
@@ -301,6 +301,13 @@
        /* Load the palette, if any */
        palette = (surface->format)->palette;
        if ( palette ) {
+
+                if ( SDL_RWseek(src, fp_offset+14+biSize, SEEK_SET) < 0 ) {
+                        SDL_Error(SDL_EFSEEK);
+                        was_error = 1;
+                        goto done;
+                }
+
                /*
                | guich: always use 1<<bpp b/c some bitmaps can bring wrong information
                | for colorsUsed

On 2006-05-13 16:10:24 +0000, Maurizio Monge wrote:

Created attachment 127
A sample file

On 2006-05-14 16:57:21 +0000, Sam Lantinga wrote:

This is fixed in subversion, thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Diff for libjpeg 8 (jpg.diff, application/octet-stream, 2011-04-07 07:24:58 +0000, 383 bytes)
• Fix compilation on Linux (jpeg-linux.diff, text/plain, 2011-09-25 17:09:34 +0000, 592 bytes)

Reported in version: unspecified
Reported for operating system, platform: Windows 7, x86_64

Comments on the original bug report:

On 2011-04-07 07:24:58 +0000, wrote:

Created attachment 599
Diff for libjpeg 8

libjpeg 8 has a different naming scheme for booleans:

boolean -> JPEG_boolean
FALSE -> JPEG_FALSE
TRUE -> JPEG_TRUE

I'm building SDL_image with MinGW, attached is a small change I've made to IMG_jpg.c to be able to compile it.

On 2011-04-07 08:01:37 +0000, Sam Lantinga wrote:

This is in, thanks!
http://hg.libsdl.org/SDL_image/rev/b1c1ec3a8d49

On 2011-09-25 17:09:34 +0000, Yury G. Kudryashov wrote:

Created attachment 708
Fix compilation on Linux

TRUE was renamed to JPEG_TRUE by mingw port maintainers, not by upstream developers.

So instead of testing for version number one should test whether JPEG_TRUE is defined.

The attached patch is against the latest hg version.

On 2011-12-31 09:36:49 +0000, Sam Lantinga wrote:

I like this patch, it's in, thanks!
http://hg.libsdl.org/SDL_image/rev/e0527402f476

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-05-11 15:14:18 +0000, Patrice Mandin wrote:

SDL_image' configure.in script assumes that zlib library is in the default compiler path. It may not be the case if zlib has been compiled by the user and/or installed to a different location.

The autoconf macro archive contains the CHECK_ZLIB macro to allow the user to specify the path to zlib (--with-zlib=, --without-zlib).
http://autoconf-archive.cryp.to/autoconf-archive-2007-05-10.tar.bz2

On 2007-07-12 20:52:35 +0000, Sam Lantinga wrote:

This has been added to SDL_image in revision 3243. Thanks!

On 2007-07-19 21:34:57 +0000, Sam Lantinga wrote:

The CHECK_ZLIB wasn't able to detect cross-compiled libz.

From the new SDL_image README:
If you have these libraries installed in non-standard places, you can
try adding those paths to the configure script, e.g.
sh ./configure CPPFLAGS="-I/somewhere/include" LDFLAGS="-L/somewhere/lib"

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.9
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2009-11-14 09:36:36 +0000, federico wrote:

I'm working on Gentoo Linux.
With version 1.2.9 (and only with it) IMG_Load() works correctly for the first two/three images and then starts to return NULL pointers.
Even the bundled showimage program has this problem if you give it multiple files as input.
I cannot confirm the bug on other systems.

On 2009-11-14 11:52:32 +0000, Sam Lantinga wrote:

This is fixed in subversion and I'm working on a 1.2.10 release.

Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• config log for error diagnostic (config.log, application/octet-stream, 2006-05-02 18:29:05 +0000, 35491 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-03-22 12:16:57 +0000, Samuel Owens wrote:

After successfully compiling SDL 1.2.9, I tried to compile SDL_image 1.2.4, but after successfully configuring, when I try to run make, I get this error:

IMG_png.c:72:17: error: png.h: No such file or directory
IMG_png.c: In function 'IMG_isPNG':
IMG_png.c:86: error: 'png_size_t' undeclared (first use in this function)
IMG_png.c:86: error: (Each undeclared identifier is reported only once
IMG_png.c:86: error: for each function it appears in.)
IMG_png.c:86: error: syntax error before numeric constant
IMG_png.c: At top level:
IMG_png.c:90: error: syntax error before 'ctx'
IMG_png.c: In function 'png_read_data':
IMG_png.c:94: error: 'ctx' undeclared (first use in this function)
IMG_png.c:95: error: 'area' undeclared (first use in this function)
IMG_png.c:95: error: 'size' undeclared (first use in this function)
IMG_png.c: In function 'IMG_LoadPNG_RW':
IMG_png.c:100: error: 'png_structp' undeclared (first use in this function)
IMG_png.c:100: error: syntax error before 'png_ptr'
IMG_png.c:101: error: 'png_infop' undeclared (first use in this function)
IMG_png.c:102: error: 'png_uint_32' undeclared (first use in this function)
IMG_png.c:109: error: 'png_bytep' undeclared (first use in this function)
IMG_png.c:109: error: syntax error before 'volatile'
IMG_png.c:112: error: 'png_color_16' undeclared (first use in this function)
IMG_png.c:112: error: 'transv' undeclared (first use in this function)
IMG_png.c:120: error: 'png_ptr' undeclared (first use in this function)
IMG_png.c:120: error: 'info_ptr' undeclared (first use in this function)
IMG_png.c:120: error: 'row_pointers' undeclared (first use in this function)
IMG_png.c:123: error: 'PNG_LIBPNG_VER_STRING' undeclared (first use in this function)
IMG_png.c:151: error: 'width' undeclared (first use in this function)
IMG_png.c:151: error: 'height' undeclared (first use in this function)
IMG_png.c:163: error: 'PNG_COLOR_TYPE_GRAY' undeclared (first use in this function)
IMG_png.c:169: error: 'PNG_INFO_tRNS' undeclared (first use in this function)
IMG_png.c:174: error: 'PNG_COLOR_TYPE_PALETTE' undeclared (first use in this function)
IMG_png.c:195: error: 'PNG_COLOR_TYPE_GRAY_ALPHA' undeclared (first use in this function)
IMG_png.c:237: error: syntax error before ')' token
IMG_png.c:246: error: syntax error before 'Uint8'
IMG_png.c:281: error: 'png_infopp' undeclared (first use in this function)
IMG_png.c:281: error: syntax error before numeric constant
make: *** [IMG_png.lo] Error 1

I don't know why that file isn't there in the "stable" source code. Especially since I compiled SDL, & SDL_image successfully on my machine at home (I'm on Computer Science lab computer now) last night

On 2006-03-22 12:23:08 +0000, Samuel Owens wrote:

When I tried the CVS build, I get the same error.

On 2006-03-25 04:24:37 +0000, Christian Walther wrote:

Looks like you don't have libpng? Although I'd expect configure to complain in that case...

On 2006-04-12 10:29:09 +0000, Sam Lantinga wrote:

What platform are you running on?
If it's a UNIX platform, what's the output of: sh configure

On 2006-05-01 05:19:14 +0000, Sam Lantinga wrote:

I think this may be fixed in subversion.
You can check out a snapshot here:
http://www.libsdl.org/tmp/SDL_image-1.2.5.tar.gz

Please reopen this bug if it's not fixed, and include the output of config.log

On 2006-05-02 18:29:05 +0000, Samuel Owens wrote:

Created attachment 109
config log for error diagnostic

same problem I'm afraid.
config.log is attached

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• the backtrace (sdl-image-convert-surface, text/plain, 2011-11-20 09:29:50 +0000, 11544 bytes)

Reported in version: 1.2.10
Reported for operating system, platform: Mac OS X 10.6, x86_64

Comments on the original bug report:

On 2011-11-20 09:29:10 +0000, Martin Gerhardy wrote:

I'm not sure whether it's a problem in SDL_image or SDL. But loading an image with SDL_image 1.2.10 on an intel mac 64 bit results in a segfault (bt full is attached)

The SDL version that was used was SDL 1.3 from Nov. 15th

------------------snip----------------------------------

SDL_Surface *surf = IMG_Load(file.getName());

SDL_PixelFormat format;
memset(&format, 0, sizeof(format));
format.BitsPerPixel = 32;
format.BytesPerPixel = 4;
#if SDL_BYTEORDER == SDL_BIG_ENDIAN
format.Rmask = 0xff000000;
format.Gmask = 0x00ff0000;
format.Bmask = 0x0000ff00;
format.Amask = 0x000000ff;
#else
format.Rmask = 0x000000ff;
format.Gmask = 0x0000ff00;
format.Bmask = 0x00ff0000;
format.Amask = 0xff000000;
#endif
format.Rshift = 24;
format.Gshift = 16;
format.Bshift = 8;
format.Ashift = 0;

// here comes the segfault
SDL_Surface * converted = SDL_ConvertSurface(surf, &format, 0);

------------------snap----------------------------------

On 2011-11-20 09:29:50 +0000, Martin Gerhardy wrote:

Created attachment 730
the backtrace

the backtrace

On 2012-11-06 11:44:49 +0000, Martin Gerhardy wrote:

this can be closed - it works with the latest sdl version.

On 2012-11-06 20:19:50 +0000, Sam Lantinga wrote:

Great, thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Changes the Xcode variable FRAMEWORK_VERSION from 1.3 to B (FrameworkB.diff, text/plain, 2011-11-30 15:37:35 +0000, 1660 bytes)
• Removes the underscore from SDL_image's product name (sdlimage-no-underscore.diff, text/plain, 2011-11-30 16:53:39 +0000, 1787 bytes)

Reported in version: 1.2.10
Reported for operating system, platform: Mac OS X 10.6, x86

Comments on the original bug report:

On 2011-08-16 13:08:21 +0000, Vern Jensen wrote:

Application Loader rejects any apps that include SDL_Image.framework, complaining that "SDL_Image is an invalid bundle identifier."

The solution is simple: rebuild the framework with "SDLImage" as the bundle identifier.

Apparently it doesn't like underscores.

On 2011-11-30 15:37:35 +0000, C.W. Betts wrote:

Created attachment 735
Changes the Xcode variable FRAMEWORK_VERSION from 1.3 to B

On 2011-11-30 15:43:04 +0000, C.W. Betts wrote:

(In reply to comment # 1)

Created attachment 735 [details]
Changes the Xcode variable FRAMEWORK_VERSION from 1.3 to B

Sorry, not used to this bugzilla: this patch is for a different issue.

As for renaming supporting SDL frameworks without an underscore, this could break linking with older apps. I think a static file link (e.g. ln -s SDLImage SDL_Image) might take care of it. If not, there's probably a linker flag that can be passed to make the framework be recognized as both SDL_Image and SDLImage, but default to SDLImage when built and linked to it.

On 2011-11-30 16:53:39 +0000, C.W. Betts wrote:

Created attachment 737
Removes the underscore from SDL_image's product name

On 2011-12-31 10:36:03 +0000, Sam Lantinga wrote:

Both of these fixes are in for all the SDL_* libraries I maintain.

Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• sdlimage-ilbm-amiga-modes.2.diff (sdlimage-ilbm-amiga-modes.2.diff, text/plain, 2006-01-24 01:20:38 +0000, 5984 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-24 01:19:19 +0000, Sam Lantinga wrote:

Date: Tue, 1 Apr 2003 11:43:04 +0200
From: David Raulo [email protected](by way of David Raulo [email protected])
Subject: [SDL] SDL_Image patch for ILBM Amiga images

Hi all,

Here's a patch for SDL_Image, adding support for classic Amiga ILBM formats:

• fixes a small bug with stencil (images with a transparent color but no
  stencil/mask plane could not be read)
• fixes colormap for EHB ("Extra Half Brite") mode (these images have 6
  bitplanes, but the colormap only contains 32 colors. The second half of the
  colormap has to be a copy of the first one, with brightness divided by 2)
• adds support for HAM ("Hold And Modify") and HAM8 modes. These are
  converted to 24bits images.

Detailed information about these formats can be found on
http://netghost.narod.ru/gff/graphics/summary/iff.htm

The attached patch is a unidiff against SDL_Image version 1.2.3.

On 2006-01-24 01:20:38 +0000, Sam Lantinga wrote:

Created attachment 31
sdlimage-ilbm-amiga-modes.2.diff

This diff doesn't apply cleanly anymore.

On 2006-01-27 11:23:22 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-05-01 04:03:06 +0000, Sam Lantinga wrote:

It looks like this functionality is already in SDL_image in subversion.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• config.log with both libpng 1.2 and 1.6 installed, default configure options (config.log.with-png12-enable-png-shared, text/plain, 2013-06-07 13:13:23 +0000, 31604 bytes)
• config.log with both libpng 1.2 and 1.6 installed, --disable-png-shared (config.log.with-png12-disable-png-shared, text/plain, 2013-06-07 13:15:34 +0000, 31560 bytes)
• config.log with libpng 1.6 installed, and without libpng 1.2 installed (config.log.without-png12, text/plain, 2013-06-07 13:17:44 +0000, 31610 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2013-01-09 13:38:25 +0000, David North wrote:

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

On 2013-06-03 01:57:38 +0000, Sam Lantinga wrote:

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.

On 2013-06-07 13:13:23 +0000, Yaohan Chen wrote:

Created attachment 1182
config.log with both libpng 1.2 and 1.6 installed, default configure options

On 2013-06-07 13:15:34 +0000, Yaohan Chen wrote:

Created attachment 1183
config.log with both libpng 1.2 and 1.6 installed, --disable-png-shared

On 2013-06-07 13:17:44 +0000, Yaohan Chen wrote:

Created attachment 1184
config.log with libpng 1.6 installed, and without libpng 1.2 installed

On 2013-06-07 13:32:20 +0000, Yaohan Chen wrote:

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.

On 2013-06-08 00:56:18 +0000, Sam Lantinga wrote:

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!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.12
Reported for operating system, platform: Mac OS X (All), All

Comments on the original bug report:

On 2012-11-16 01:13:08 +0000, wrote:

When compiling with the configure and makefile on Mountain Lion, libSDLmain.a and libSDL.a get somehow included in libSDL_image.a. This seems to confuse ld, as I ge tthe following message in the final linking with the application:

ld: warning: ignoring file lib/libSDL_image.a, file was built for archive which is not the architecture being linked (x86_64): lib/libSDL_image.a

otool and lipo still recognize the library as a x86_64 blob. It's only clang that seems to be upset at it.

The same happens with libSDL_mixer.a, but I won't report this bug twice.

I don't know whether this is related to # 1429.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2009-11-15 23:17:46 +0000, wrote:

The webpage at [http://www.libsdl.org/projects/SDL_image/] should use headings like

and

so that it is possible to link to [http://www.libsdl.org/projects/SDL_image/#changes] and [http://www.libsdl.org/projects/SDL_image/# 1.2.10].

And of course the page should be syntactically correct: http://validator.w3.org/

(this bugtracker does not seem to have a version 1.2.10 of SDL_image)

On 2009-12-14 13:23:32 +0000, Sam Lantinga wrote:

I added anchors so you can have links of that form. I also added the missing SDL_image version to the bug tracker. Thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2012-01-20 11:03:07 +0000, wrote:

After upgrade to the recent sdl_image 1.2.11, pygame.image reports error on img.get_palette():

import pygame
img = pygame.image.load('/usr/share/solarwolf/data/fire.png')
pal = img.get_palette()
Traceback (most recent call last):
File "", line 1, in
error: Surface has no palette to get

As a result the game solarwolf is no longer playable.

On 2012-01-20 17:05:09 +0000, Sam Lantinga wrote:

This is fixed in 1.2.12 which is being released shortly.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• xpm colors mapping table ! (xpm_color.c, text/x-csrc, 2012-11-11 13:19:53 +0000, 51531 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2012-11-11 13:19:53 +0000, Sylvain wrote:

Created attachment 987
xpm colors mapping table !

Here's a file to recognize lots colors for XPM format !
colors were found on internet, but I can't remember where ...

On 2012-11-22 13:11:13 +0000, Sam Lantinga wrote:

Added, thanks!
http://hg.libsdl.org/SDL_image/rev/2e4f9d95a8c8

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (All), All

Comments on the original bug report:

On 2009-06-10 06:29:45 +0000, Mason Wheeler wrote:

See http://lists.libsdl.org/pipermail/sdl-libsdl.org/2009-April/069705.html for the patch and the rationale for it.

On 2009-06-29 21:05:00 +0000, Mason Wheeler wrote:

After further testing, I've found that the patch needs to be revised a little. The "initialized & CONSTANT_VALUE" checks need to be removed from IMG_Init, as they make it impossible to nest initialization calls from different subsystems of the calling program.

Also, the line "initialized = result;" ought to read "initialized |= result;", again to allow for multiple calls to IMG_Init to work correctly.

On 2009-09-26 02:10:04 +0000, Sam Lantinga wrote:

This is in for the next release, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: FreeBSD, x86

Comments on the original bug report:

On 2008-04-15 07:22:09 +0000, Chad Whitacre wrote:

Is it possible to include /usr/local/include on the search path for header files by default? That's where libpng installs png.h by default on my system (FreeBSD 6).

On 2009-10-17 12:49:21 +0000, Sam Lantinga wrote:

Can you test with the latest pre-release snapshot?
http://www.libsdl.org/tmp/SDL_image-1.2.8.zip

Thanks!

On 2011-12-31 09:32:24 +0000, Sam Lantinga wrote:

No response in a few years. :)

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Other, All

Comments on the original bug report:

On 2006-11-16 05:16:57 +0000, Andrew Radford wrote:

Using 1.2.5 stable off the homepage
Compiling on RHEL4 x86 32bit Linux

I am using configure to set up a MIPS cross compile on a x86 box

Because of this, the SDL libs and headers are compiled for mips in a directory other than /usr/local. Configure should execute sdl-config with -prefix=<path/to/mips/sdl/installation> because supplied the correct --with-sdl-prefix parameter to configure. Instead sdl-config is called with no -prefix parameter, causing it to default to /usr/local - which contains either the wrong (x86) libs or none at all.

In configure, changing $SDL_CONFIG to pass $sdl_args instead of $sdlconf_args made this work. It seems $sdlconf_args or $sdl_config_args are empty.

Note I am no expert in configure & autotools, so this may not be a bug if configure can be rebuilt somehow to fix this.

On 2007-07-12 20:59:25 +0000, Sam Lantinga wrote:

This seems like a bug in your SDL installation. If I configure SDL with --prefix=/usr/local/cross-tools/i386-mingw32, and then do make install, an sdl-config will be generated and installed in /usr/local/cross-tools/i386-mingw32/bin, and running that with the --cflags and --libs arguments will yield:
-I/usr/local/cross-tools/i386-mingw32/include/SDL -D_GNU_SOURCE=1 -Dmain=SDL_main
-L/usr/local/cross-tools/i386-mingw32/lib -lmingw32 -lSDLmain -lSDL -mwindows

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Other, Other

Comments on the original bug report:

On 2009-06-14 22:05:14 +0000, Satya Surya Kiran Kumar wrote:

Hi

I am trying to load bmp images using SDL. I am trying to load png & jpg images for symbian O.S. Can any body please help me out how to configure "SDL_Image" for s60 symbian (using carbide c++).

Thanks in advance.

On 2009-09-26 02:13:04 +0000, Sam Lantinga wrote:

This is a good question for the SDL forums:
http://forums.libsdl.org/

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• libpng 1.5 support (libpng1.5-fix.diff, text/plain, 2011-02-16 16:11:05 +0000, 8887 bytes)

Reported in version: 1.2.10
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2011-02-16 16:09:28 +0000, Mikael Eriksson wrote:

Trying to build SDL_image with libpng 1.5 fails with:

/bin/sh ./libtool --tag=CC --mode=compile i486-mingw32-gcc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="SDL_image" -DVERSION="1.2.10" -DLOAD_JPG=1 -DLOAD_PNG=1 -DLOAD_TIF=1 -DLOAD_BMP=1 -DLOAD_GIF=1 -DLOAD_LBM=1 -DLOAD_PCX=1 -DLOAD_PNM=1 -DLOAD_TGA=1 -DLOAD_XCF=1 -DLOAD_XPM=1 -DLOAD_XV=1 -DLOAD_TIF_DYNAMIC="libtiff-3.dll" -DLOAD_PNG_DYNAMIC="libpng15-15.dll" -I. -I/usr/i486-mingw32/include/libpng15 -g -O2 -D_GNU_SOURCE=1 -Dmain=SDL_main -I/usr/i486-mingw32/include/SDL -MT IMG_png.lo -MD -MP -MF .deps/IMG_png.Tpo -c -o IMG_png.lo IMG_png.c
libtool: compile: i486-mingw32-gcc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="SDL_image" -DVERSION="1.2.10" -DLOAD_JPG=1 -DLOAD_PNG=1 -DLOAD_TIF=1 -DLOAD_BMP=1 -DLOAD_GIF=1 -DLOAD_LBM=1 -DLOAD_PCX=1 -DLOAD_PNM=1 -DLOAD_TGA=1 -DLOAD_XCF=1 -DLOAD_XPM=1 -DLOAD_XV=1 -DLOAD_TIF_DYNAMIC="libtiff-3.dll" -DLOAD_PNG_DYNAMIC="libpng15-15.dll" -I. -I/usr/i486-mingw32/include/libpng15 -g -O2 -D_GNU_SOURCE=1 -Dmain=SDL_main -I/usr/i486-mingw32/include/SDL -MT IMG_png.lo -MD -MP -MF .deps/IMG_png.Tpo -c IMG_png.c -DDLL_EXPORT -DPIC -o .libs/IMG_png.o
IMG_png.c: In function 'IMG_LoadPNG_RW':
IMG_png.c:350:7: error: dereferencing pointer to incomplete type
IMG_png.c:419:21: error: dereferencing pointer to incomplete type
IMG_png.c:421:28: error: dereferencing pointer to incomplete type
IMG_png.c:429:22: error: dereferencing pointer to incomplete type
IMG_png.c:477:25: error: dereferencing pointer to incomplete type
IMG_png.c:478:30: error: dereferencing pointer to incomplete type
IMG_png.c:479:23: error: dereferencing pointer to incomplete type
IMG_png.c:480:38: error: dereferencing pointer to incomplete type
IMG_png.c:481:38: error: dereferencing pointer to incomplete type
IMG_png.c:482:38: error: dereferencing pointer to incomplete type
make: *** [IMG_png.lo] Error 1

On 2011-02-16 16:11:05 +0000, Mikael Eriksson wrote:

Created attachment 575
libpng 1.5 support

The attached patch makes it build with libpng 1.5. I have also verified that it still works with libpng 1.4.

On 2011-02-16 16:26:09 +0000, Sam Lantinga wrote:

Have you tried SDL_image from Mercurial?
hg clone http://hg.libsdl.org/SDL_image

On 2011-02-16 16:46:26 +0000, Mikael Eriksson wrote:

The hg tip compiles fine. Guess I should have checked that before writing the patch.

On 2011-02-16 17:18:40 +0000, Sam Lantinga wrote:

Okay, thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• patch for configure.in (static-lib-check.patch, text/plain, 2008-01-13 08:00:33 +0000, 851 bytes)

Reported in version: 1.2.6
Reported for operating system, platform: Windows (All), PowerPC

Comments on the original bug report:

On 2008-01-13 07:59:42 +0000, Christian Walther wrote:

I'm trying to build a set of static SDL_* libraries in my Mingw cross-compilation setup on Mac OS X. I have only static (no dynamic) versions of libpng and libtiff installed and configure SDL_image using

cross-configure.sh --prefix=/usr/local/cross-tools/i386-mingw32 --disable-shared --disable-jpg-shared --disable-png-shared --disable-tif-shared

In this invocation, the checks for libpng and libtiff fail (even though the libraries are there, and are found) because of missing symbols from zlib. I can fix this using the attached patch. I assume this shouldn't interfere in the case that dynamic png/tiff libraries are around, but I'm reluctant to try it, and I'm not very familiar with autoconf in general. Perhaps someone who is can advise if this is the right thing to do...

On 2008-01-13 08:00:33 +0000, Christian Walther wrote:

Created attachment 245
patch for configure.in

On 2008-12-13 06:51:28 +0000, Patrice Mandin wrote:

I also encountered it on a different platform, where the only option is static linking. It fails to find the -lz dependency for libpng and libtiff the same way, and found the same fix :). Would be nice to have it commited.

On 2009-09-26 01:43:02 +0000, Sam Lantinga wrote:

Thanks, this is committed to subversion.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• 2-color grayscale PNG (whitePlain.png, image/png, 2012-05-23 08:57:54 +0000, 232 bytes)
• 8-bit greyscale (heightmap.png, image/png, 2012-05-25 11:04:24 +0000, 870 bytes)
• bug 1503 fix (IMG_png.diff, text/plain, 2013-03-06 10:05:16 +0000, 494 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2012-05-23 08:57:54 +0000, pelya wrote:

Created attachment 860
2-color grayscale PNG

Branch default, rev. 330:1230766039be
SDL_image will fail when trying to load the PNG file I've attached, it's in 2-color grayscale format.

I remember opening a very similar bug a while ago.

On 2012-05-25 11:04:24 +0000, Adam Olsen wrote:

Created attachment 861
8-bit greyscale

Here's an 8-bit greyscale that SDL_image also fails to load (reports "Out of memory").

SDL1.3 trunk of a few weeks ago, SDL_image trunk of today.

On 2012-05-25 11:47:57 +0000, Adam Olsen wrote:

I poked around and SDL_MasksToPixelFormatEnum only supports INDEX8 and RGB332, which isn't what IMG_LoadPNG_RW is asking for.

I'm not sure what the solution is here. I don't see any greyscale formats listed in SDL_PIXELFORMAT_*. Maybe the easiest is to pretend it's 8-bit indexed but with a no-op palette that can be ignored?

On 2013-03-06 10:05:16 +0000, q66 wrote:

Created attachment 1058
bug 1503 fix

Hello, just attaching a fix here (by Lee "eihrul" Salzman) to make it noticed :)

DK

On 2013-03-10 14:26:05 +0000, q66 wrote:

fixed in http://hg.libsdl.org/SDL_image/rev/9b6ceb2c4a3b

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-09-21 15:27:48 +0000, Donald Straney wrote:

I'm writing a program that's linked to SDL 1.2.9 and SDL_image 1.2.5 in Windows XP, and when I use IMG_Load to try to load PNG images, it returns NULL, and IMG_GetError returns "Unsupported image format". SDL.dll, SDL_image.dll, and libpng12.dll are all in the same directory as the program, and it works fine when loading BMPs (or when it's run in Windows ME, for some reason). If it matters, I'm using Dev-C++, which uses MinGW as a backend.

On 2006-09-25 13:33:00 +0000, Dmitry Yakimov wrote:

Hi,

Please try SDL_Image from SVN, I have fixed similar error in 2004 (http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL_image/IMG_png.c?view=log)

-- Dmitry Yakimov

On 2006-09-28 16:44:52 +0000, Donald Straney wrote:

Thanks, but when I try to compile in Dev-C++ I get these errors:

[Linker error] undefined reference to SDL_RWFromFile' [Linker error] undefined reference to SDL_SetError'

I've got the SDL 1.2.9 development libraries installed, and the extra commands passed to the compiler are "-lmingw32 -lSDLmain -lSDL". (I tried searching to see if there was something I was doing wrong, but couldn't find anything)

On 2007-09-19 19:43:00 +0000, Ryan McCann wrote:

With Dev-C++ you have to create a .a lib file for any dll's you want to call directly(Dev will occasionally let you get away without them, but the functionality involved is incredibly buggy). Anything using sdl_image needs a -lsdl_image flag.

To get a .a file from a dll DL the mingw_utils_0.3 package, use bin/pexports.exe to change the get a .def and bin/dlltool.exe to get a .a from the .def

This is a compiler issue and not a SDL_Image issue. The current version of image(and at least two previous releases) work with PNG files on winXP.

On 2009-01-01 12:26:48 +0000, BJ wrote:

Same problem under linux. When trying to load a png file i get a segmentation fault.

using netbeans 6.5, ubuntu 8.10, gcc, sdl 1.2.13

On 2009-10-17 12:47:41 +0000, Sam Lantinga wrote:

Can you test with the latest pre-release snapshot?
http://www.libsdl.org/tmp/SDL_image-1.2.8.zip

Thanks!

On 2011-12-31 09:32:03 +0000, Sam Lantinga wrote:

No response in a few years. :)

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• patch to add pkg-config for SDL_image (SDL_image-pkgconfig.diff, text/plain, 2009-07-07 03:35:39 +0000, 1077 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2009-07-07 03:35:39 +0000, Luca Bigliardi wrote:

Created attachment 338
patch to add pkg-config for SDL_image

Hi,
I'm attaching two patches to add pkg-config support to SDL_image.

pkg-config is used to retrieve information about installed libraries and
it's well integrated with build configurators (for instance
PKG_CHECK_MODULES autoconf macro).

Thank you,

Luca

On 2009-08-07 03:08:22 +0000, Sam Lantinga wrote:

Committed to subversion with revision 4670

Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• a png with alpha channel (gfxtest.png, image/png, 2009-03-26 00:04:24 +0000, 53397 bytes)

Reported in version: 1.2.6
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2009-03-26 00:04:24 +0000, peter wrote:

Created attachment 308
a png with alpha channel

Possible Memory Leak rendering PNG images,the parts code of a sample is belows:
//============================================================================
/* Initialize the SDL library */
if ( SDL_Init(SDL_INIT_VIDEO) < 0 ) {
fprintf(stderr, "Couldn't initialize SDL: %s\n",SDL_GetError());
return(255);
}

flags = SDL_SWSURFACE;
SDL_Surface* Surf_Temp = NULL;
/* Open the image file */
for(j=0;j<100;j++)
{
image[j] = IMG_Load(argv[1]);

    }


  /* Use the deepest native mode, except that we emulate 32bpp
     for viewing non-indexed images on 8bpp screens */

screen = SDL_SetVideoMode(720, 576, 16, flags);
if ( screen == NULL ) {
fprintf(stderr,"Couldn't set video mode: %s\n",
SDL_GetError());
return -1;
}
#if 0
/* Set the palette, if one exists */
if ( image[20]->format->palette ) {
SDL_SetColors(screen, image[20]->format->palette->colors,
0, image[20]->format->palette->ncolors);
}

  /* Draw a background pattern if the surface has transparency */
  if(image[20]->flags & (SDL_SRCALPHA | SDL_SRCCOLORKEY))
  		draw_background(screen);

#endif
/* Display the image */
SDL_BlitSurface(image[20], NULL, screen, NULL);
SDL_UpdateRect(screen,0,0,0,0);
sleep(5);
fprintf(stderr,"start free resource...................\n");

  for(j=0;j<100;j++)
  {
  	printf("before free:image[%d].refcount is %d\n",j,image[j]->refcount); 
  	SDL_FreeSurface(image[j]);
  	printf("after free:image[%d].refcount is %d\n",j,image[j]->refcount);
  	
  }

SDL_Quit();
...............

On 2009-03-26 00:05:48 +0000, peter wrote:

I don't know if it's a memory leak or something else. How can I fix it.
thanks for your help!

On 2009-09-26 01:39:52 +0000, Sam Lantinga wrote:

It's not legal to check the refcount on a surface after it was freed. :)

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• patch to mark said functions static (make-functions-static.patch, text/plain, 2008-06-06 11:49:16 +0000, 6119 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-06-06 11:48:45 +0000, Matt Turner wrote:

Quite a few functions in SDL_image can be marked as static, AFAICS. Such functions are IMG_Init* and IMG_Quit* functions.

On 2008-06-06 11:49:16 +0000, Matt Turner wrote:

Created attachment 255
patch to mark said functions static

On 2008-08-01 19:06:11 +0000, Matt Turner wrote:

Uhh, any reason this hasn't been applied yet? It's a simple patch.

On 2009-09-26 01:54:32 +0000, Sam Lantinga wrote:

Nope, this has been applied for the next release.

Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• sample image contributed by dulsi (USRSCR.LBM, application/octet-stream, 2007-07-14 10:51:44 +0000, 55686 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-03-04 13:15:42 +0000, Dennis Payne wrote:

I found some images used in a Bard's Tale Construction Set game that don't load properly. When the LBM is a packed bitmap the number of planes are set to one. This causes the number of colors in the palette to be set to 2. Here is a patch to fix the problem. I think it is correct but I don't have a lot of LBM files to test with. Some broken LBMs can be found in Bard's Lore I found at http://bardstale.brotherhood.de/talefiles/cs/files/index.html

--- IMG_lbm.c.orig 2007-03-04 15:56:51.000000000 -0500
+++ IMG_lbm.c 2007-03-04 15:58:45.000000000 -0500
@@ -297,7 +297,8 @@
Image->format->palette->colors[i].g = Image->format->palette->colors[i%nbcolors].g;
Image->format->palette->colors[i].b = Image->format->palette->colors[i%nbcolors].b;
}

• Image->format->palette->ncolors = nbrcolorsfinal;
  

• if ( !pbm )
  

• 	Image->format->palette->ncolors = nbrcolorsfinal;
  

  }

  /* Get the bitmap */

On 2007-07-12 20:21:52 +0000, Sam Lantinga wrote:

Can you attach a sample image?

On 2007-07-14 10:51:44 +0000, Sam Lantinga wrote:

Created attachment 226
sample image contributed by dulsi

On 2007-07-19 21:38:44 +0000, Sam Lantinga wrote:

I tried contacting the author of the previous patch that introduced this bug, but got no response.

Unless someone comes up with a problem with this, I'm checking this in as subversion revision 3341

Thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• correct behaviour (1.2.13) (screen-capture1.png, image/png, 2009-10-29 08:06:58 +0000, 109223 bytes)
• wrong behaviour (1.2.14 + 1,3) (screen-capture2.png, image/png, 2009-10-29 08:09:16 +0000, 74337 bytes)
• correct behaviour with background red channel as alpha (screen-capture3.png, image/png, 2009-10-29 08:10:41 +0000, 144395 bytes)
• another (more evident) screenshot of the wrong behaviour (screen-capture4.png, image/png, 2009-10-29 08:33:45 +0000, 72307 bytes)
• test image used in showimage to test ppc code (BlueWater.png, image/png, 2009-11-10 13:12:27 +0000, 2336 bytes)

Reported in version: unspecified
Reported for operating system, platform: Mac OS X (All), All

Comments on the original bug report:

On 2009-10-29 08:06:06 +0000, Vittorio Giovara wrote:

starting from 1.2.14 with the new ImageIO backend, some images (we use pngs) have problems in setting the alpha channel correctly. The surface is loaded and converted correctly, as the colors match the ones in the other OSes, but when blending an alpha area, the alpha color is completely ignored.

here is the correct behaviour (1.2.13) -> http://dl.getdropbox.com/u/24468/screen-capture1.png

here is the (weird) behaviour (1.2.14 and 1.3) -> http://dl.getdropbox.com/u/24468/screen-capture2.png

here is a (normal) behaviour with red as alpha color -> http://dl.getdropbox.com/u/24468/screen-capture3.png

we have a strong suspect that one area might be doing ABGR, and the other area expecting the alpha to be the last byte and reading the R as an A.

On 2009-10-29 08:06:58 +0000, Vittorio Giovara wrote:

Created attachment 435
correct behaviour (1.2.13)

On 2009-10-29 08:09:16 +0000, Vittorio Giovara wrote:

Created attachment 436
wrong behaviour (1.2.14 + 1,3)

On 2009-10-29 08:10:41 +0000, Vittorio Giovara wrote:

Created attachment 437
correct behaviour with background red channel as alpha

On 2009-10-29 08:33:45 +0000, Vittorio Giovara wrote:

Created attachment 438
another (more evident) screenshot of the wrong behaviour

On 2009-10-29 09:13:05 +0000, Sam Lantinga wrote:

Are you able to reproduce this with showimage, or is this a problem in your application?

There were a few color issues in some games that turned out to be the game assuming the order of the RGB channels, but once they started checking the masks in the screen->format, everything was fine.

On 2009-10-29 10:30:50 +0000, Vittorio Giovara wrote:

(In reply to comment # 5)

Are you able to reproduce this with showimage, or is this a problem in your
application?

There were a few color issues in some games that turned out to be the game
assuming the order of the RGB channels, but once they started checking the
masks in the screen->format, everything was fine.

We're quite sure that the order of the channels are correct because the other images are displayed correctly -- the problem only arise when images with alpha are blended.

a similar issue was found here http://forums.libsdl.org/viewtopic.php?p=19729 where opacity is applied in two different ways on OSX and win.

btw our application is located at http://www.hedgewars.org/ and you can read the source here http://fireforge.net/scm/viewvc.php/trunk/hedgewars/?root=hedgewars (the IMG_Load is in uStore.pas)

On 2009-10-29 13:13:06 +0000, Vittorio Giovara wrote:

hm we noticed that by stripping color profiles from the png helped with the background image.
perhaps our theory was wrong, but does sdlimage handles color profiles correcly in the new backend?

On 2009-10-29 13:47:03 +0000, Vittorio Giovara wrote:

Ok, dumping the first column of a buggy SDL surface, we noticed an interesting pattern:

A B G R

SDL on OSX
206 | 177 | 131 | 125

GIMP
206 | 220 | 163 | 155

SDL on OSX
14 | 8 | 5 | 4

GIMP
14 | 157 | 92 | 84

Pattern seems to be that if you take:
177 * (255/206) ~ 219

and
8 * (255/14) ~ 146

Now, that 2nd one is not so accurate. But.
157 / (255 / 14) = 8.58 which if truncated is 8.

220 / (255 / 206) = 177.72 = 177

So we could be dealing with some curious modification proportional to alpha and a floor operation to boot.

Fortunately the fix for that is fairly trivial, until SDL is fixed, we can ifdef DARWIN to reverse the damage.
The truncation means some accuracy is lost, but hopefully not too much.

On 2009-10-29 21:03:12 +0000, Sam Lantinga wrote:

From nemo:

Hey. Turns out the problem was a bit weirder than someone simply messing up RGBA vs ABGR.
http://forums.libsdl.org/viewtopic.php?p=20011# 20011

On 2009-10-29 21:55:37 +0000, Sam Lantinga wrote:

Eric, can you look into this?

On 2009-11-09 19:45:09 +0000, Vittorio Giovara wrote:

is there any update on this?
in the meantime i have updated the workaround code

{$IFDEF DARWIN}
tmpP := tmpsurf^.pixels;
for i:= 0 to (tmpsurf^.pitch shr 2) * tmpsurf^.h - 1 do
begin
{$IFDEF ENDIAN_LITTLE}
tmpA:= tmpP^[i] shr 24 and $FF;
tmpR:= tmpP^[i] shr 16 and $FF;
tmpG:= tmpP^[i] shr 8 and $FF;
tmpB:= tmpP^[i] and $FF;
{$ELSE}
tmpA:= tmpP^[i] and $FF;
tmpR:= tmpP^[i] shr 8 and $FF;
tmpG:= tmpP^[i] shr 16 and $FF;
tmpB:= tmpP^[i] shr 24 and $FF;
{$ENDIF}
if tmpA <> 0 then
begin
tmpR:= round(tmpR * 255/tmpA);
tmpG:= round(tmpG * 255/tmpA);
tmpB:= round(tmpB * 255/tmpA);
end;

  			if tmpR > 255 then tmpR:= 255;
  			if tmpG > 255 then tmpG:= 255;
  			if tmpB > 255 then tmpB:= 255;

{$IFDEF ENDIAN_LITTLE}
tmpP^[i]:= (tmpA shl 24) or (tmpR shl 16) or (tmpG shl 8) or tmpB;
{$ELSE}
tmpP^[i]:= (tmpA) or (tmpR shl 8) or (tmpG shl 16) or (tmpB shl 24);
{$ENDIF}
end;
{$ENDIF}

On 2009-11-09 20:38:05 +0000, Sam Lantinga wrote:

Oh, it looks like Mac OS X is just pre-multiplying the alpha. Thanks for the great workaround code!

On 2009-11-09 20:40:13 +0000, Sam Lantinga wrote:

And of course looking at the code, I see we're explicitly asking for that with kCGImageAlphaPremultipliedFirst.

On 2009-11-09 22:02:11 +0000, Sam Lantinga wrote:

It turns out that ImageIO only supports pre-multiplied alpha output. Ugh.
http://lists.apple.com/archives/mac-opengl/2007/may/msg00056.html

On 2009-11-09 23:33:52 +0000, Sam Lantinga wrote:

Out of curiosity, what does your workaround do to this image?
http://www.w3.org/Graphics/PNG/alphatest.png

On 2009-11-10 00:45:42 +0000, Sam Lantinga wrote:

Nevermind, this is fixed now, thanks!
http://www.libsdl.org/tmp/SDL_image/SDL_image-1.2.9.tar.gz

On 2009-11-10 10:24:36 +0000, Vittorio Giovara wrote:

ok now it works fine, thanks!
there is just one thing that worries me is that by looking at the code
Uint8 *p = (Uint8 *)surface->pixels;
Uint8 A = p[3];
so we are using 8 bits for Alpha, 8 for Red, 8 for Green and 8 for Blue; then we make a division and save it on an eight bit variable

if the result of the operation is something like 99.99 then the result stored would be 99, truncating the .99, making the color a little darker -- not noticable -- but different from an alpha-free surface; every computation on color value would be likely to fail with this code.

What do you think of this possibility?

On 2009-11-10 13:11:28 +0000, Vittorio Giovara wrote:

PowerPC loading is broken

normal pngs work fine but pngs with alpha segfault
showimage's output is

showimage(52993) malloc: *** error for object 0x837200: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

(attached BlueWater.png)

On 2009-11-10 13:12:27 +0000, Vittorio Giovara wrote:

Created attachment 448
test image used in showimage to test ppc code

On 2009-11-10 23:09:44 +0000, Sam Lantinga wrote:

The crash is fixed, thanks!

As for the inaccuracy in the multiplication, we might be able to solve it by using 256 instead of 255, although that might break things the other direction.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Sample image (bone.png, image/png, 2012-01-18 04:53:50 +0000, 1331 bytes)
• SDL_image-1.2.11-png_channels.patch (SDL_image-1.2.11-png_channels.patch, text/plain, 2012-01-18 14:21:26 +0000, 597 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2012-01-17 22:46:56 +0000, wrote:

see https://bugs.mageia.org/show_bug.cgi?id=4175

i fear this may have been the problematic change: (unsure)
http://hg.libsdl.org/SDL_image/rev/ea460af4ceff

On 2012-01-18 04:53:50 +0000, Sam Lantinga wrote:

Created attachment 781
Sample image

AL13N

i think this is the one

On 2012-01-18 14:21:26 +0000, wrote:

Created attachment 785
SDL_image-1.2.11-png_channels.patch

when looking a the differences between a patch we carried in the 1.2.10 and the 1.2.11; i noted a difference in it, and after fixing that, it seemed to work.

since this is about a 256c png image it should be 1byte, not 3, thus this solves it for me.

thanks alot of the assistance. since i'm a mageia packager, i'm adding the patch to our SDL_image build.

On 2012-01-19 20:20:17 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/7036dd36a22f

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch (SDL_image-SDL-1.2-compat.diff, text/plain, 2012-02-27 08:07:38 +0000, 1367 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2012-02-27 08:07:38 +0000, pelya wrote:

Created attachment 828
Patch

Just few #ifdefs around functions that use SDL_Texture

On 2013-06-03 01:48:41 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/e94321a2e752

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• sdl-image-find-lib-cross.patch (sdl-image-find-lib-cross.patch, text/plain, 2007-12-29 18:12:10 +0000, 925 bytes)
• libsdl-sdl-m4-pkg-config.patch (libsdl-sdl-m4-pkg-config.patch, text/plain, 2007-12-29 19:07:08 +0000, 4667 bytes)
• libsdl-sdl-m4-pkg-config.2.patch (libsdl-sdl-m4-pkg-config.2.patch, text/plain, 2009-10-03 00:24:03 +0000, 4836 bytes)
• sdl-image-pkg-config-png.patch (sdl-image-pkg-config-png.patch, text/plain, 2009-10-04 22:28:31 +0000, 838 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2007-12-10 16:47:36 +0000, Mike Frysinger wrote:

it's much easier to manage .pc files for cross-compiling setups than it is for random *-config scripts ... the cross-compiled pkg-config files can all be easily/tightly controlled and separate from the host pkg-config files. the *-config files however are to be found in $PATH and can easily pick the wrong one.

can we get the sdl.m4 macro updated so that it checks for libsdl.pc first via the standard PKG_CHECK_MODULES() m4 macro, and if that fails, fall back to the normal sdl-config voodoo.

along these lines, the png code in configure.in should be updated to use PKG_CHECK_MODULES() rather than parsing the headers/libs directly ... the current code can break easily when libpng requires other libs (like -lz and/or -lm).

On 2007-12-28 08:52:56 +0000, Sam Lantinga wrote:

I'm not very familiar with the pkg-config system. Can you supply a patch?

Thanks!

On 2007-12-29 18:12:10 +0000, Mike Frysinger wrote:

Created attachment 240
sdl-image-find-lib-cross.patch

sorry, i didnt see your reply

this patch makes it so find_lib() does not look in /usr/local/lib and /usr/lib when cross-compiling as that can easily cause troubles

On 2007-12-29 19:07:08 +0000, Mike Frysinger wrote:

Created attachment 241
libsdl-sdl-m4-pkg-config.patch

here's the fun one ... this updates libsdl's sdl.m4 so that it uses sdl.pc (and pkg-config) before sdl-config

the order preference is:

• use sdl configure options first from user
• try to use sdl.pc/pkg-config
• try to use sdl-config/SDL_CONFIG

so really all this does is insert pkg-config before the normal default logic

On 2009-10-02 05:32:45 +0000, Sam Lantinga wrote:

I applied your configure.in patch, thanks!

The sdl.m4 patch didn't cleanly apply though, can you update it for the latest SDL snapshot?
http://www.libsdl.org/tmp/SDL-1.2.zip

Thanks!

On 2009-10-03 00:24:03 +0000, Mike Frysinger wrote:

Created attachment 382
libsdl-sdl-m4-pkg-config.2.patch

applied rev 3493 and rev 3532 manually to get the patch to apply

On 2009-10-03 03:14:33 +0000, Sam Lantinga wrote:

Are you creating the diff against the current SDL_image in subversion?

sam-lantingas-mac-pro:SDL_image hercules$ patch -l -p2 <~/Downloads/libsdl-sdl-m4-pkg-config.2.patch
patching file acinclude/sdl.m4
Hunk # 1 FAILED at 19.

On 2009-10-03 08:06:20 +0000, Mike Frysinger wrote:

this bug started out as "SDL_image should do XXX", but the m4 problems SDL_image isnt specific to it. the problematic code comes from SDL itself, so the patch applies to trunk/SDL/sdl.m4. once the original version gets fixed, it'll propagate to all the other packages.

On 2009-10-03 21:42:33 +0000, Sam Lantinga wrote:

It doesn't quite work here...
./configure: line 20603: syntax error near unexpected token SDL,' ./configure: line 20603: PKG_CHECK_MODULES(SDL, sdl >= $min_sdl_version,'

On 2009-10-03 22:48:43 +0000, Mike Frysinger wrote:

do you not have pkg-config installed on your system ? it provides that m4 macro via its pkg.m4 ...

guess the AM_PATH_SDL should be updated like so:
@@ -10,5 +10,6 @@
dnl
AC_DEFUN([AM_PATH_SDL],
-[dnl
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+dnl
dnl Get the cflags and libraries from the sdl-config script
dnl

On 2009-10-03 22:57:19 +0000, Sam Lantinga wrote:

Okay, I tried that...

configure.in:87: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
acinclude/sdl.m4:203: AM_PATH_SDL is expanded from...
configure.in:87: the top level
configure.in:87: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
acinclude/sdl.m4:203: AM_PATH_SDL is expanded from...
configure.in:87: the top level
configure.in:87: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
acinclude/sdl.m4:203: AM_PATH_SDL is expanded from...
configure.in:87: the top level
configure.in:1: error: possibly undefined macro: dnl
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:20608: error: possibly undefined macro: AC_MSG_RESULT

On 2009-10-04 09:57:36 +0000, Mike Frysinger wrote:

adding the AC_REQUIRE wont fix your original problem (no pkg.m4 on your system), it'll only make the failure obvious at an earlier point (from a sometimes-syntax error to an autoconf error)

you still need to install the pkgconfig program and the associated pkg.m4:
http://pkgconfig.freedesktop.org/wiki/

i dont think it's unreasonable to expect developers who are running autotools to have this installed

On 2009-10-04 11:12:06 +0000, Sam Lantinga wrote:

Okay, I applied your changes to sdl.m4 to SDL 1.3 and the SDL_* libraries I maintain, and added pkg.m4 to the libraries.

I didn't want to make that change to SDL 1.2 because anyone who updates to the release will suddenly have an unexpected pkg.m4 dependency.

Can you provide a patch for the png support? It should fall back to the current system if pkg-config isn't available.

Thanks!

On 2009-10-04 22:28:31 +0000, Mike Frysinger wrote:

Created attachment 395
sdl-image-pkg-config-png.patch

i think the current handling of autotool files is broken ... but i guess it doesnt matter since i'm not the SDL maintainer. since you're including pkg.m4 in svn, no one who updates will have a dependency on pkg.m4.

at any rate, this patch should convert SDL_image's png lookup to pkg-config

On 2009-10-05 00:55:09 +0000, Sam Lantinga wrote:

Should there be equivalent changes for libjpeg and libtiff?

Do you have suggestions on improving the autotools support?

Thanks!

On 2009-10-05 09:28:43 +0000, Mike Frysinger wrote:

the jpeg/tiff packages dont provide .pc files, so they wouldnt work

imo, generated autotool files shouldnt be in svn. it does mean that people need more development packages installed in order to use the development svn, but i think that is how it should be. i dont imagine you want to impose these higher requirements on people which is why you copy so much to acinclude/ and such.

On 2009-10-05 21:54:17 +0000, Sam Lantinga wrote:

Yes, that's true. My general philosophy is to try to work on as many different environments as possible. :)

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• fixes the bug (SDL_image.diff, text/plain, 2011-06-12 10:18:12 +0000, 691 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2011-06-12 10:17:31 +0000, Dimitris Zenios wrote:

When building SDL_Image with mingw libjpeg-8 header files define SDL_TRUE,SDL_FALSE and SDL_boolean.The problem though occurs when building with gcc in linux where this flags are not defined in jpeglib

On 2011-06-12 10:18:12 +0000, Dimitris Zenios wrote:

Created attachment 622
fixes the bug

On 2011-08-10 11:30:15 +0000, Scott McCreary wrote:

Attached patch by Dimitris fixes this isssue on Haiku as well.
+1

On 2011-10-04 21:48:48 +0000, Ryan C. Gordon wrote:

This is now hg changeset a5d4daece235, thanks!

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.12
Reported for operating system, platform: Windows 7, x86

Comments on the original bug report:

On 2012-04-27 14:18:14 +0000, Pere wrote:

Hi, at Tux Paint there is this bug report [1], a quick test with fopen(fname, "r")) goes right, so the images are accesible at the path described by fname.

An additional test is -with the file manager inside W7- to drag a image over showimage.exe, the results are that the image only displays if the chars of the path to the image are all ASCII.

[1] http://sourceforge.net/tracker/?func=detail&aid=3473049&group_id=66938&atid=516295

On 2012-05-24 13:54:03 +0000, Pere wrote:

Well, I followed the trace of the filaname passed to IMG_Load() up to the win32_file_open() function in the SDL-1.2.15/src/file/SDL_rwops.c file, it is unchanged untill arriving there, then it is recoded in this function, thus changing the path and avoiding to load the file.

If in win32_file_open() I force the use of filename as it is passed to the function ( h = CreateFile(filename, (w_right|r_right).....) instead of the recoded filenameW (h = CreateFileW(filenameW, (w_right|r_right), .....), then it loads right the images with non ascii chars on their path.

I don't provide a patch as I don't know enouth the code to understand what side effects this change can have.

Hope this helps
Pere

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• bad looking image (img.png, image/png, 2012-04-10 13:25:09 +0000, 7484 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2012-04-10 13:25:09 +0000, Mikhail wrote:

Created attachment 843
bad looking image

I see only part of loaded image. It's happening when I compiling with -std=c++0x option.

CODE:

#include "SDL/SDL.h"
#include "SDL/SDL_image.h"

int main(int argc, char* args[])
{

SDL_Surface* hello = NULL;
SDL_Surface* screen = NULL;

SDL_Init(SDL_INIT_EVERYTHING);

screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE);

hello = IMG_Load("alien.png");
SDL_BlitSurface(hello, NULL, screen, NULL);
SDL_Flip(screen);
SDL_Delay(2000);
SDL_FreeSurface(hello);
SDL_Quit();

return 0;
}

COMPILER:

mike@mike-laptop:~/work/invdrs$ g++ --version
g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

SDL:

Source: libsdl1.2
Version: 1.2.14-6.1ubuntu4

On 2012-04-10 13:29:36 +0000, Mikhail wrote:

Sorry, it's a bug in my code, I set 24 bit depth in SDL_SetVideoMode and now it's all right.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2007-02-28 04:48:02 +0000, wrote:

Add MNG support to SDL_image. At [http://cryptology.org/research/SDL MNG Library/] there is SDL_mng-0.1.tar.bz2. I have tested it with the following result:
SDL_mng-0.1> ./autogen.sh
Generating aclocal.m4
/usr/share/aclocal/sdlmm.m4:12: warning: underquoted definition of AM_PATH_SDLMM
/usr/share/aclocal/sdlmm.m4:12: run info '(automake)Extending aclocal'
/usr/share/aclocal/sdlmm.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
Generating Makefile.in
configure.ac:6: installing ./config.sub' configure.ac:10: installing ./missing'
configure.ac:10: installing ./install-sh' configure.ac:6: installing ./config.guess'
Makefile.am: installing ./depcomp' configure.ac:14: required file ./ltmain.sh' not found
Generating configure file

I worked around the problem:
SDL_mng-0.1> ln -s /usr/share/libtool/ltmain.sh .
SDL_mng-0.1> ./autogen.sh
Generating aclocal.m4
/usr/share/aclocal/sdlmm.m4:12: warning: underquoted definition of AM_PATH_SDLMM
/usr/share/aclocal/sdlmm.m4:12: run info '(automake)Extending aclocal'
/usr/share/aclocal/sdlmm.m4:12: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
Generating Makefile.in
Generating configure file

Then configure works. But make ends with:
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -DLOAD_PNG -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -o libSDL_mng.la -rpath /usr/local/lib SDL_mng.lo @IMG_LIBS@ -lpng -lz -lSDL -lpthread
gcc -shared .libs/SDL_mng.o /usr/lib/libpng12.so -lz /usr/lib/libSDL.so -L/usr/lib -lpthread @IMG_LIBS@ -Wl,-soname -Wl,libSDL_mng.so.0 -o .libs/libSDL_mng.so.0.0.0
gcc: @IMG_LIBS@: No such file or directory
make: *** [libSDL_mng.la] Fel 1

I commented out the line "libSDL_mng_la_LIBADD = @IMG_LIBS@" in Makefile.am and did "./autogen.sh;configure;make" again. Then I could run ./mngtest and see the dancing panda.

On 2007-03-05 19:12:48 +0000, Dennis Payne wrote:

I was just looking at SDL_mng and I'm probably going use it. But I don't think it is a good idea to integrate as is. I'd prefer to see an interface more like SDL_anim (http://tamale.net/SDL_anim/). That interface isn't entirely to my liking either.

On 2007-07-12 20:17:09 +0000, Sam Lantinga wrote:

Yes, SDL_image is really meant for single images, not animation or image sets.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Test source/script, input image file and my result (sdlimagetest.tar.gz, application/x-gzip, 2012-02-07 18:17:06 +0000, 329878 bytes)
• Screenshot of SDLInvaders showing image corruption towards bottom of sprites. (SDLInvaders.png, image/png, 2012-12-31 06:20:13 +0000, 23144 bytes)
• Fix that can apply to changeset 292 and later. (IMG_ImageIO.m.srgbmapping.diff, text/plain, 2012-12-31 14:54:27 +0000, 639 bytes)

Reported in version: unspecified
Reported for operating system, platform: Mac OS X 10.5 (Intel), x86

Comments on the original bug report:

On 2012-02-06 19:38:31 +0000, wrote:

I was writing a simple image viewer with SDL. Everything was fine, until I switched to SDL_Image for image loading. The surface I was getting was of correct size, but all pixels were simply black (0,0,0,255).

I tried to compile from source, still no joy. showimage utility wasn't working either.

I started to debug with gdb. When I stepped into SDL_Image routines, I found it uses whatever ImageIO gives back: with that black SDL_Surface.

Since ImageIO routines were suspicious, I just configured with '--enable-imageio=no' to use default SDL backend.
Finally it works. I'm not sure which one is faulty, though. I'm filing this because someone might encounter this as well, unless it's something wrong only on my mac.

On 2012-02-06 19:39:39 +0000, wrote:

ADDED: SDL_image version is 1.2.12.

On 2012-02-06 19:40:23 +0000, wrote:

(In reply to comment # 1)
Sorry for confusion. The version is actually 1.2.15.

On 2012-02-07 16:06:32 +0000, Sam Lantinga wrote:

I built SDL_image with ImageIO and tested it on all the images I have here and didn't have any problems.
Can you post a link to an image that doesn't work?

Thanks!

On 2012-02-07 18:17:06 +0000, wrote:

Created attachment 817
Test source/script, input image file and my result

I'm attaching a test program and script with input image file.
I have MacPorts version (with ImageIO) in /opt/local/lib, and source-compiled version without ImageIO in /usr/local/lib.
wo_imageio.txt is the result when linked against the library in /usr/local/lib, and w_imageio.txt is the result when linked against the library in /opt/local/lib. The result was the same for the source compiled version before I manually disabled ImageIO through configure.

This is weird, if this is happening only to me. What would be a possible cause?

On 2012-02-27 08:24:48 +0000, Gabriel Jacobo wrote:

I tested image loading with ImageIO last week with the latest SDL_image and OS X 10.7, it worked fine for PNG files at least.

On 2012-12-31 06:19:11 +0000, Mark Scott wrote:

I can confirm this bug exists - MacOSX 10.5.8; XCode 3.1.4;

All SDL based games I've tried are impacted (widelands, SDLInvaders). I've seen both black images and image corruption. For example, the splash screen of SDLInvaders is black, and in-game it has corrupt graphics (see attachment)

I have traced the problem to be starting when changeset 292 was applied to the SDL_image library (changeset 289 works; 290 & 291 are not code updates) - so this is first seen with SDL_image 1.2.11. SDL_image 1.2.12 is also affected.

http://hg.libsdl.org/SDL_image/rev/5953114c0d27

I have a MacPorts issue open for downstream visibility: https://trac.macports.org/ticket/37453

Workaround: compile SDL_image with --disable-imageio.

Let me know if there's anything I can help check, though ImageIO is not an area I'm familiar with.

On 2012-12-31 06:20:13 +0000, Mark Scott wrote:

Created attachment 1003
Screenshot of SDLInvaders showing image corruption towards bottom of sprites.

On 2012-12-31 14:54:27 +0000, Mark Scott wrote:

Created attachment 1005
Fix that can apply to changeset 292 and later.

The attached diff fixes the library so ImageIO can be used and images are displayed again without corruption and black screens.

(Based on http://pastebin.com/T3s15UXF and http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html)

I suspect the matrix passed to CGColorSpaceCreateCalibratedRGB() as implemented in r292 is invalid and the CoreGraphics framework on 10.5 doesn't reject it, but later ones do. Unfortunately all the documentation I can find doesn't actually specify what the valid range of values of the arguments is.

On 2013-01-01 11:41:33 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/3999783ed889

On 2013-01-01 11:41:37 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/3999783ed889

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Simple test program (test.cpp, text/x-c++src, 2012-04-18 16:58:21 +0000, 1073 bytes)

Reported in version: unspecified
Reported for operating system, platform: Android (All), ARM

Comments on the original bug report:

On 2012-04-18 16:58:21 +0000, Dan Hatch wrote:

Created attachment 846
Simple test program

I'm using the most recent versions of sdl-1.3 and SDL_image from HG. My build environment is Ubuntu 11.10 x86_64.
I've built a simple test program which loads an image and displays it for 5 seconds. The image fails to load, and the app is just a black screen that remains open.
'adb logcat' displays the following:

(loads all .so files just fine)

V/SDL ( 785): pixel format RGB_565
I/SDL ( 785): SDL_Android_Init()
I/SDL ( 785): SDL_Android_Init() finished!
W/SDL/APP ( 785): **Setting up display
I/Process ( 80): Sending signal. PID: 785 SIG: 3
I/dalvikvm( 785): threadid=3: reacting to signal 3
W/SDL/APP ( 785): **Error::Video driver doesn't support changing display mode
V/SDL ( 785): Starting up OpenGL ES 1.1
D/libEGL ( 785): Emulator without GPU support detected. Fallback to software renderer.
D/libEGL ( 785): loaded /system/lib/egl/libGLES_android.so
I/dalvikvm( 785): Wrote stack traces to '/data/anr/traces.txt'
D/gralloc_goldfish( 785): Emulator without GPU emulation detected.
I/SDL ( 785): [STUB] GL_SetSwapInterval
I/SDL ( 785): [STUB] GL_GetSwapInterval
W/SDL/APP ( 785): **Loading Image /sdcard/data/images/test.jpg
W/SDL/APP ( 785): **Error::Image Failed to Load
W/SDL/APP ( 785): **Displaying Image
W/SDL/APP ( 785): **Error::Invalid texture
I/ActivityManager( 80): Displayed org.libsdl.app/.SDLActivity: +2s172ms
W/InputManagerService( 80): Starting input on non-focused client com.android.internal.view.IInputMethodClient$Stub$Proxy@41593c58 (uid=10013 pid=177)
W/NetworkManagementSocketTagger( 80): setKernelCountSet(10013, 0) failed with errno -2

The files exists inside the emulator:
$adb shell

ls /sdcard/data/images/

default.png
grass(old).png
grass.png
items.png
monster.png
objects.png
objectsheet.xcf
pirate.png
pog.png
stoneblock.png
test.jpg

I think I am having a similar problem as described in this post:
http://forums.libsdl.org/viewtopic.php?t=8037&sid=6e8774e5eb3b0e7b83be13d7bfe1fcf6

On 2012-04-19 13:25:07 +0000, Dan Hatch wrote:

I'm also getting an 'invalid renderer'

On 2012-04-20 14:28:59 +0000, Dan Hatch wrote:

Tested on 2.1 and 4.0.3 emulators and a 2.3 device. All platforms show same errors.

On 2012-05-11 11:32:25 +0000, Gabriel Jacobo wrote:

You are loading the image from an absolute path outside of the Android package. By default IMG_Load under Android will, iirc, load images using RWops and the paths have to be specified relative to the assets folder (ie, whatever you drop into the assets folder of the Android project you can load it as if it where in a "virtual root").

On 2012-05-16 00:24:46 +0000, Dan Hatch wrote:

(In reply to comment # 3)

You are loading the image from an absolute path outside of the Android package.
By default IMG_Load under Android will, iirc, load images using RWops and the
paths have to be specified relative to the assets folder (ie, whatever you drop
into the assets folder of the Android project you can load it as if it where in
a "virtual root").

Ok, cool thanks, I'll give it a try :)

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows (All), All

Comments on the original bug report:

On 2009-06-10 06:26:21 +0000, Mason Wheeler wrote:

This patch will allow PNG files to be saved.

Index: IMG_png.c

--- IMG_png.c (revision 4475)
+++ IMG_png.c (working copy)
@@ -76,17 +76,26 @@
png_infop (*png_create_info_struct) (png_structp png_ptr);
png_structp (*png_create_read_struct) (png_const_charp user_png_ver, png_voidp error_ptr, png_error_ptr error_fn, png_error_ptr warn_fn);
void (*png_destroy_read_struct) (png_structpp png_ptr_ptr, png_infopp info_ptr_ptr, png_infopp end_info_ptr_ptr);

• png_structp (*png_create_write_struct) (png_const_charp user_png_ver, png_voidp error_ptr, png_error_ptr error_fn, png_error_ptr warn_fn);
• void (*png_destroy_write_struct) (png_structpp png_ptr_ptr, png_infopp info_ptr_ptr);
  png_uint_32 (*png_get_IHDR) (png_structp png_ptr, png_infop info_ptr, png_uint_32 *width, png_uint_32 *height, int *bit_depth, int *color_type, int *interlace_method, int *compression_method, int *filter_method);
• void (*png_set_IHDR) (png_structp png_ptr, png_infop info_ptr, png_uint_32 width, png_uint_32 height, int bit_depth, int color_type, int interlace_method, int compression_method, int filter_method);
  png_voidp (*png_get_io_ptr) (png_structp png_ptr);
  png_uint_32 (*png_get_tRNS) (png_structp png_ptr, png_infop info_ptr, png_bytep *trans, int *num_trans, png_color_16p *trans_values);
  png_uint_32 (*png_get_valid) (png_structp png_ptr, png_infop info_ptr, png_uint_32 flag);
  void (*png_read_image) (png_structp png_ptr, png_bytepp image);
• void (*png_write_image) (png_structp png_ptr, png_bytepp image);
  void (*png_read_info) (png_structp png_ptr, png_infop info_ptr);
• void (*png_write_info) (png_structp png_ptr, png_infop info_ptr);
• void (*png_set_PLTE) (png_structp png_ptr, png_infop info_ptr, png_colorp palette, int num_palette);
• void (*png_write_end) (png_structp png_ptr, png_infop info_ptr);
  void (*png_read_update_info) (png_structp png_ptr, png_infop info_ptr);
  void (*png_set_expand) (png_structp png_ptr);
  void (*png_set_gray_to_rgb) (png_structp png_ptr);
• void (*png_set_bgr) (png_structp png_ptr);
  void (*png_set_packing) (png_structp png_ptr);
  void (*png_set_read_fn) (png_structp png_ptr, png_voidp io_ptr, png_rw_ptr read_data_fn);
• void (*png_set_write_fn) (png_structp png_ptr, png_voidp io_ptr, png_rw_ptr read_data_fn);
  void (*png_set_strip_16) (png_structp png_ptr);
  int (*png_sig_cmp) (png_bytep sig, png_size_t start, png_size_t num_to_check);
  } lib;
  @@ -120,6 +129,20 @@
  SDL_UnloadObject(lib.handle);
  return -1;
  }

• lib.png_create_write_struct =
  

• 	(png_structp (*) (png_const_charp, png_voidp, png_error_ptr, png_error_ptr))
  

• 	SDL_LoadFunction(lib.handle, "png_create_write_struct");
  

• if ( lib.png_create_write_struct == NULL ) {
  

• 	SDL_UnloadObject(lib.handle);
  

• 	return -1;
  

• }
  

• lib.png_destroy_write_struct =
  

• 	(void (*) (png_structpp, png_infopp))
  

• 	SDL_LoadFunction(lib.handle, "png_destroy_write_struct");
  

• if ( lib.png_destroy_write_struct == NULL ) {
  

• 	SDL_UnloadObject(lib.handle);
  

• 	return -1;
  

• }
  lib.png_get_IHDR =
  	(png_uint_32 (*) (png_structp, png_infop, png_uint_32 *, png_uint_32 *, int *, int *, int *, int *, int *))
  	SDL_LoadFunction(lib.handle, "png_get_IHDR");
  

@@ -127,6 +150,13 @@
SDL_UnloadObject(lib.handle);
return -1;
}

• lib.png_set_IHDR =
  

• 	(void (*) (png_structp, png_infop, png_uint_32, png_uint_32, int, int, int, int, int))
  

• 	SDL_LoadFunction(lib.handle, "png_set_IHDR");
  

• if ( lib.png_set_IHDR == NULL ) {
  

• 	SDL_UnloadObject(lib.handle);
  

• 	return -1;
  

• }
  lib.png_get_io_ptr =
  	(png_voidp (*) (png_structp))
  	SDL_LoadFunction(lib.handle, "png_get_io_ptr");
  

@@ -155,6 +185,13 @@
SDL_UnloadObject(lib.handle);
return -1;
}

• lib.png_write_image =
  

• 	(void (*) (png_structp, png_bytepp))
  

• 	SDL_LoadFunction(lib.handle, "png_write_image");
  

• if ( lib.png_write_image == NULL ) {
  

• 	SDL_UnloadObject(lib.handle);
  

• 	return -1;
  

• }
  lib.png_read_info =
  	(void (*) (png_structp, png_infop))
  	SDL_LoadFunction(lib.handle, "png_read_info");
  

@@ -162,6 +199,27 @@
SDL_UnloadObject(lib.handle);
return -1;
}

• lib.png_write_info =
  

• 	(void (*) (png_structp, png_infop))
  

• 	SDL_LoadFunction(lib.handle, "png_write_info");
  

• if ( lib.png_write_info == NULL ) {
  

• 	SDL_UnloadObject(lib.handle);
  

• 	return -1;
  

• }	
  

• lib.png_set_PLTE =
  

• 	(void (*) (png_structp, png_infop, png_colorp, int))
  

• 	SDL_LoadFunction(lib.handle, "png_set_PLTE");
  

• if ( lib.png_set_PLTE == NULL ) {
  

• 	SDL_UnloadObject(lib.handle);
  

• 	return -1;
  

• }
  

• lib.png_write_end =
  

• 	(void (*) (png_structp, png_infop))
  

• 	SDL_LoadFunction(lib.handle, "png_write_end");
  

• if ( lib.png_write_end == NULL ) {
  

• 	SDL_UnloadObject(lib.handle);
  

• 	return -1;
  

• }
  lib.png_read_update_info =
  	(void (*) (png_structp, png_infop))
  	SDL_LoadFunction(lib.handle, "png_read_update_info");
  

@@ -183,6 +241,13 @@
SDL_UnloadObject(lib.handle);
return -1;
}

• lib.png_set_bgr =
  

• 	(void (*) (png_structp))
  

• 	SDL_LoadFunction(lib.handle, "png_set_bgr");
  

• if ( lib.png_set_bgr == NULL ) {
  

• 	SDL_UnloadObject(lib.handle);
  

• 	return -1;
  

• }
  lib.png_set_packing =
  	(void (*) (png_structp))
  	SDL_LoadFunction(lib.handle, "png_set_packing");
  

@@ -197,6 +262,13 @@
SDL_UnloadObject(lib.handle);
return -1;
}

• lib.png_set_write_fn =
  

• 	(void (*) (png_structp, png_voidp, png_rw_ptr))
  

• 	SDL_LoadFunction(lib.handle, "png_set_write_fn");
  

• if ( lib.png_set_write_fn == NULL ) {
  

• 	SDL_UnloadObject(lib.handle);
  

• 	return -1;
  

• }
  lib.png_set_strip_16 =
  	(void (*) (png_structp))
  	SDL_LoadFunction(lib.handle, "png_set_strip_16");
  

@@ -505,6 +577,171 @@
return(surface);
}

+static void png_write_data(png_structp ctx, png_bytep area, png_size_t size)
+{

• SDL_RWops *src;
• src = (SDL_RWops *)lib.png_get_io_ptr(ctx);
• SDL_RWwrite(src, area, size, 1);
  +}
  +/* write a png file */
  +int IMG_SavePNG_RW(SDL_Surface *surface, SDL_RWops *src)
  +{
• png_structp png_ptr;
• png_infop info_ptr;
• png_colorp palette = NULL;
• int start;
• int colorType;
• int i;
• const char *error = NULL;
• SDL_Palette *sdlPalette;
• png_uint_32 height = surface->h;
• png_uint_32 width = surface->w;
• png_bytep *volatile row_pointers;
• int row;
• if ( !src ) {

• /* The error message has been set in SDL_RWFromFile */
  

• return -1;
  

• }
• start = SDL_RWtell(src);
• if ( IMG_InitPNG() < 0 ) {

• return -1;
  

• }
• /* Create and initialize the png_struct with the desired error handler
• • functions. If you want to use the default stderr and longjump method,
• • you can supply NULL for the last three parameters. We also check that
• • the library version is compatible with the one used at compile time,
• • in case we are using dynamically linked libraries. REQUIRED.
• */
• png_ptr = NULL; info_ptr = NULL;
• /* Create the PNG loading context structure */
• png_ptr = lib.png_create_read_struct(PNG_LIBPNG_VER_STRING,

• 			  NULL,NULL,NULL);
  

• if (png_ptr == NULL){

• error = "Couldn't allocate memory for PNG file or incompatible PNG dll";
  

• goto done;
  

• }
• /* Allocate/initialize the memory for image information. REQUIRED. */
• info_ptr = lib.png_create_info_struct(png_ptr);
• if (info_ptr == NULL) {

• error = "Couldn't create image information for PNG file";
  

• goto done;
  

• }
• /* Set error handling if you are using setjmp/longjmp method (this is
• • the normal method of doing things with libpng). REQUIRED unless you
• • set up your own error handlers in png_create_read_struct() earlier.
• */
• if ( setjmp(png_ptr->jmpbuf) ) {

• error = "Error reading the PNG file.";
  

• goto done;
  

• }
• /* Set up the output control */
• lib.png_set_write_fn(png_ptr, src, png_write_data);
• /* Set the image information here. Width and height are up to 2^31,

• * bit_depth is one of 1, 2, 4, 8, or 16, but valid values also depend on
  

• * the color_type selected. color_type is one of PNG_COLOR_TYPE_GRAY,
  

• * PNG_COLOR_TYPE_GRAY_ALPHA, PNG_COLOR_TYPE_PALETTE, PNG_COLOR_TYPE_RGB,
  

• * or PNG_COLOR_TYPE_RGB_ALPHA.  interlace is either PNG_INTERLACE_NONE or
  

• * PNG_INTERLACE_ADAM7, and the compression_type and filter_type MUST
  

• * currently be PNG_COMPRESSION_TYPE_BASE and PNG_FILTER_TYPE_BASE. REQUIRED
  

• */
  

• sdlPalette = surface->format->palette;
• if (sdlPalette)
• {

• colorType = PNG_COLOR_TYPE_PALETTE;
  

• } else if (surface->format->Amask)
• {

• colorType = PNG_COLOR_TYPE_RGB_ALPHA;
  

• } else
• {

• colorType = PNG_COLOR_TYPE_RGB;
  

• }
• lib.png_set_IHDR(png_ptr, info_ptr, surface->w, surface->h, surface->format->BitsPerPixel, colorType,

• PNG_INTERLACE_NONE, PNG_COMPRESSION_TYPE_BASE, PNG_FILTER_TYPE_BASE);
  

• /* set the palette if there is one. REQUIRED for indexed-color images */
• if (colorType == PNG_COLOR_TYPE_PALETTE)
• {

•    palette = (png_colorp) malloc(sdlPalette->ncolors * sizeof(png_color));
  

• for( i=0; i < sdlPalette->ncolors; ++i ) {
  

•     palette[i].blue = sdlPalette->colors[i].b;
  

•     palette[i].green = sdlPalette->colors[i].g;
  

•     palette[i].red = sdlPalette->colors[i].r;
  

• }
  

• lib.png_set_PLTE(png_ptr, info_ptr, palette, sdlPalette->ncolors);
  

• }
• else
• { //not sure how to handle this
  +// sig_bit.red = true_red_bit_depth;
  +// sig_bit.green = true_green_bit_depth;
  +// sig_bit.blue = true_blue_bit_depth;

• /* if the image has an alpha channel then */
  

+// sig_bit.alpha = true_alpha_bit_depth;
+// png_set_sBIT(png_ptr, info_ptr, sig_bit);

• }
• lib.png_set_bgr(png_ptr);
• /* Write the file header information. REQUIRED */
• lib.png_write_info(png_ptr, info_ptr);
• /* The easiest way to write the image (you may have a different memory

• * layout, however, so choose what fits your needs best).  You need to
  

• * use the first method if you aren't handling interlacing yourself.
  

• */
  

• row_pointers = (png_bytep*) malloc(sizeof(png_bytep)*height);
• if ( (row_pointers == NULL) ) {

• error = "Out of memory";
  

• goto done;
  

• }
• for (row = 0; row < (int)height; row++) {

• row_pointers[row] = (png_bytep)
  

• 		(Uint8 *)surface->pixels + row*surface->pitch;
  

• }
• if (height > PNG_UINT_32_MAX/sizeof(png_bytep))
• {

• error = "Image is too tall to process in memory";
  

• goto done;
  

• }
• /* Read the entire image in one go */
• lib.png_write_image(png_ptr, row_pointers);
• /* It is REQUIRED to call this to finish writing the rest of the file */
• lib.png_write_end(png_ptr, info_ptr);

+done: /* Clean up and return */

• if ( png_ptr ) {

• lib.png_destroy_write_struct(&png_ptr, &info_ptr);
  

• }
• if ( row_pointers ) {

• free(row_pointers);
  

• }
• if (palette)
• {

• free(palette);
  

• }
• if ( error ) {

• IMG_QuitPNG();
  

• IMG_SetError(error);
  

• return(-1);
  

• } else {

• IMG_QuitPNG();
  

• }
• return(0);
  +}

#else

/* See if an image is contained in a data source */
Index: SDL_image.h

--- SDL_image.h (revision 4475)
+++ SDL_image.h (working copy)
@@ -107,6 +107,8 @@

extern DECLSPEC SDL_Surface * SDLCALL IMG_ReadXPMFromArray(char **xpm);

+extern DECLSPEC int SDLCALL IMG_SavePNG_RW(SDL_Surface *surface, SDL_RWops src);
+
/ We'll use SDL for reporting errors */
#define IMG_SetError SDL_SetError
#define IMG_GetError SDL_GetError

On 2012-02-01 11:57:57 +0000, Rodrigo Cardoso wrote:

Will this patch be added?
Since plain SDL have Save BMP I think this patch for SDL_image makes much sense.

On 2013-06-03 01:32:23 +0000, Sam Lantinga wrote:

I added a separate implementation based on miniz.c by Rich Geldreich, which doesn't require libpng, so it's always available.
http://hg.libsdl.org/SDL_image/rev/cf211e9ff224

Cheers!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• A patch to fix that (sdl_image-fails-to-load-png-with-sdl-1.3.patch, text/plain, 2012-01-03 07:25:10 +0000, 1684 bytes)

Reported in version: 1.2.10
Reported for operating system, platform: Android (All), ARM

Comments on the original bug report:

On 2012-01-03 07:25:10 +0000, pelya wrote:

Created attachment 760
A patch to fix that

When compiled with SDL 1.3, the SDL_Image library cannot load monochrome .PNG images.

An example of such image: http://imagebin.org/191575

On 2012-01-03 18:38:51 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/b51a5e14a456

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Pocket PC Project (VisualCE.zip, application/x-zip-compressed, 2009-05-05 12:01:59 +0000, 8768 bytes)

Reported in version: 1.2.6
Reported for operating system, platform: Windows (CE)/PocketPC, x86

Comments on the original bug report:

On 2009-05-05 11:59:42 +0000, mosfet wrote:

Pocket PC Visual Project

On 2009-05-05 12:01:59 +0000, mosfet wrote:

Created attachment 325
Pocket PC Project

On 2009-10-02 05:36:45 +0000, Sam Lantinga wrote:

This has been added for the next release, thanks!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• PCX test image (Test_nocomp.pcx, image/x-pcx, 2009-10-04 12:43:58 +0000, 787329 bytes)

Reported in version: unspecified
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2009-10-04 12:43:58 +0000, Sam Lantinga wrote:

Created attachment 394
PCX test image

Attached file is PCX without RLE compression. PCX files should always be with
RLE compression, but it looks like some programs like XnView can create PCX
files without RLE compression and for example IrfanView seems to support decode
of them.

(from http://roundup.ffmpeg.org/roundup/ffmpeg/issue1411)

On 2009-10-04 13:16:54 +0000, Sam Lantinga wrote:

This is implemented for the next release.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Fix for sdl2-config line for static libs under OSX (osx.staticlibs.fix.diff, text/plain, 2012-02-24 04:26:53 +0000, 799 bytes)

Reported in version: 1.2.12
Reported for operating system, platform: Mac OS X (All), x86_64

Comments on the original bug report:

On 2012-02-23 10:48:46 +0000, Gabriel Jacobo wrote:

This happens at least in Lion, with CFLAGS="-arch i386" or CFLAGS="-arch x86_64"
The workaround I'm using is removing showimage from the Makefile

i386:

/bin/sh ./libtool --tag=CC --mode=link gcc -I/Users/gabo/ignifuga/dist/osx/include/libpng12 -g -O2 -mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -I/Users/gabo/ignifuga/dist/osx/include/SDL2 -D_THREAD_SAFE -o showimage showimage.o libSDL2_image.la -L/Users/gabo/ignifuga/dist/osx/lib /Users/gabo/ignifuga/dist/osx/lib/libSDL2.a -lm -liconv -Wl,-framework,OpenGL -Wl,-framework,ForceFeedback -lobjc -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,IOKit -Wl,-framework,CoreAudio -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit
libtool: link: gcc -I/Users/gabo/ignifuga/dist/osx/include/libpng12 -g -O2 -mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -I/Users/gabo/ignifuga/dist/osx/include/SDL2 -D_THREAD_SAFE -o showimage showimage.o -Wl,-framework -Wl,OpenGL -Wl,-framework -Wl,ForceFeedback -Wl,-framework -Wl,Cocoa -Wl,-framework -Wl,Carbon -Wl,-framework -Wl,IOKit -Wl,-framework -Wl,CoreAudio -Wl,-framework -Wl,AudioToolbox -Wl,-framework -Wl,AudioUnit ./.libs/libSDL2_image.a -L/Users/gabo/ignifuga/dist/osx/lib /Users/gabo/ignifuga/dist/osx/lib/libSDL2.a -lm -liconv -lobjc
ld: warning: ignoring file ./.libs/libSDL2_image.a, file was built for archive which is not the architecture being linked (i386)
Undefined symbols for architecture i386:
"_IMG_LoadTexture", referenced from:
_main in showimage.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
make: *** [showimage] Error 1

x86_64:

/bin/sh ./libtool --tag=CC --mode=link gcc -I/opt/local/include/libpng14 -g -O2 -mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 -I/Users/gabo/ignifuga/dist/osx/include/SDL2 -D_THREAD_SAFE -static-libgcc -o showimage showimage.o libSDL2_image.la -L/Users/gabo/ignifuga/dist/osx/lib /Users/gabo/ignifuga/dist/osx/lib/libSDL2.a -lm -liconv -Wl,-framework,OpenGL -Wl,-framework,ForceFeedback -lobjc -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,IOKit -Wl,-framework,CoreAudio -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit
libtool: link: gcc -I/opt/local/include/libpng14 -g -O2 -mmacosx-version-min=10.6 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 -I/Users/gabo/ignifuga/dist/osx/include/SDL2 -D_THREAD_SAFE -static-libgcc -o showimage showimage.o -Wl,-framework -Wl,OpenGL -Wl,-framework -Wl,ForceFeedback -Wl,-framework -Wl,Cocoa -Wl,-framework -Wl,Carbon -Wl,-framework -Wl,IOKit -Wl,-framework -Wl,CoreAudio -Wl,-framework -Wl,AudioToolbox -Wl,-framework -Wl,AudioUnit ./.libs/libSDL2_image.a -L/Users/gabo/ignifuga/dist/osx/lib /Users/gabo/ignifuga/dist/osx/lib/libSDL2.a -lm -liconv -lobjc
ld: warning: ignoring file ./.libs/libSDL2_image.a, file was built for archive which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"_IMG_LoadTexture", referenced from:
_main in showimage.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [showimage] Error 1

On 2012-02-23 19:37:16 +0000, Gabriel Jacobo wrote:

I'm seeing this in SDL_image's showimage as well as in my own projects...I think I've managed to reduce the problem to the sdl2-config --libs line, that gives me:

-L/Users/gabo/ignifuga/dist/osx32/lib /Users/gabo/ignifuga/dist/osx32/lib/libSDL2.a -lm -liconv -Wl,-framework,OpenGL -Wl,-framework,ForceFeedback -lobjc -Wl,-framework,Cocoa -Wl,-framework,Carbon -Wl,-framework,IOKit -Wl,-framework,CoreAudio -Wl,-framework,AudioToolbox -Wl,-framework,AudioUnit

Note that instead of -lSDL2 it's giving out the full path without -l, so it will be statically linked!

This in turns makes the static library generation for SDL_ttf (and SDL_image) look something like:

libtool: link: ar cru .libs/libSDL2_ttf.a /Users/gabo/ignifuga/dist/osx32/lib/libSDL2.a SDL_ttf.o

So, instead of only archiving SDL_ttf.o it's trying to archive libSDL2.a as well...THIS is the actual problem...removing libSDL2.a by hand from the Makefile solves the issue...

However, if I apply the fix in sdl2-config (changing /Users/gabo/ignifuga/dist/osx32/lib/libSDL2.a by -lSDL2), the configure script for SDL_image halts at "checking for SDL - version >= 2.0.0..."

On 2012-02-24 04:26:53 +0000, Gabriel Jacobo wrote:

Created attachment 827
Fix for sdl2-config line for static libs under OSX

Sorry for the brain fart yesterday, it turns out that sleeping on a problem is always a good idea. Anyway, replacing the whole library path for -lSDL2 actually solves the problem, so this patch should solve the issue. SDL_ttf and SDL_image compile statically without issue now.

On 2012-02-28 18:59:18 +0000, Sam Lantinga wrote:

I don't think we need that hack anymore, thanks!
http://hg.libsdl.org/SDL/rev/6bb657898f55

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2012-12-10 19:16:47 +0000, SwordBearer wrote:

I used libSDL_image.a in my SDL codes,and call IMG_Load()method,
then Code:Block said this error:

/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function IMG_InitJPG':| (.text+0xff)||undefined reference to jpeg_calc_output_dimensions'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function IMG_InitJPG':| (.text+0x109)||undefined reference to jpeg_CreateDecompress'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function IMG_InitJPG':| (.text+0x113)||undefined reference to jpeg_destroy_decompress'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function IMG_InitJPG':| (.text+0x11d)||undefined reference to jpeg_finish_decompress'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function IMG_InitJPG':| (.text+0x127)||undefined reference to jpeg_read_header'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function IMG_InitJPG':| (.text+0x131)||undefined reference to jpeg_read_scanlines'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function IMG_InitJPG':| (.text+0x13b)||undefined reference to jpeg_resync_to_restart'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function IMG_InitJPG':| (.text+0x145)||undefined reference to jpeg_start_decompress'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_jpg.o)||In function IMG_InitJPG':| (.text+0x14f)||undefined reference to jpeg_std_error'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0x53)||undefined reference to png_create_info_struct'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0x5d)||undefined reference to png_create_read_struct'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0x67)||undefined reference to png_destroy_read_struct'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0x71)||undefined reference to png_get_IHDR'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0x7b)||undefined reference to png_get_channels'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0x85)||undefined reference to png_get_io_ptr'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0x8f)||undefined reference to png_get_PLTE'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0x99)||undefined reference to png_get_tRNS'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xa3)||undefined reference to png_get_valid'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xad)||undefined reference to png_read_image'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xb7)||undefined reference to png_read_info'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xc1)||undefined reference to png_read_update_info'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xcb)||undefined reference to png_set_expand'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xd5)||undefined reference to png_set_gray_to_rgb'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xdf)||undefined reference to png_set_packing'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xe9)||undefined reference to png_set_read_fn'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xf3)||undefined reference to png_set_strip_16'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_png.o)||In function IMG_InitPNG':| (.text+0xfd)||undefined reference to png_sig_cmp'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In function IMG_InitTIF':| (.text+0x12f)||undefined reference to TIFFClientOpen'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In function IMG_InitTIF':| (.text+0x139)||undefined reference to TIFFClose'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In function IMG_InitTIF':| (.text+0x143)||undefined reference to TIFFGetField'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In function IMG_InitTIF':| (.text+0x14d)||undefined reference to TIFFReadRGBAImage'|
/usr/lib/i386-linux-gnu/libSDL_image.a(IMG_tif.o)||In function IMG_InitTIF':| (.text+0x157)||undefined reference to TIFFSetErrorHandler'|
||=== Build finished: 32 errors, 0 warnings ===|

================================================================================================================================================================
so ,I delete the libSDL_image.a lib，and add the libSDL_image.so lib(they are both in the '/usr/lib/i386-linux-gnu' directory ).
it compiled success!

On 2013-05-01 19:46:37 +0000, wrote:

I would say to broaden this as I have dynamic loading of libjpeg and I am also getting failures. The issue is on IMG_jpg.c:66, dlopen fails to find the .so for libjpeg even though I can access it fine. I had a previous version of SDL_image and it worked just fine.

I will try to find out what is causing this later today.

On 2013-06-03 01:51:00 +0000, Sam Lantinga wrote:

Any luck finding the issue with the RC snapshot?
http://www.libsdl.org/tmp/SDL_image/

On 2013-06-03 08:34:55 +0000, wrote:

I just built the latest source and it does find and use the right version of libjpeg and libpng and links nicely. I just tested it and I am seeing images loading just fine, thanks. I did force what libpng and libjpeg were found for my previous builds of SDL_image, so I don't know 100% if the successful build is influenced at all from my previous efforts. Otherwise, I would say it is fixed.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Windows 7, x86_64

Comments on the original bug report:

On 2013-01-01 04:24:01 +0000, wrote:

The configure script for my mingw setup failed due to the issue that "sdl-config" is missing.
SDL 2 only sets the SDL2-config. Although its probably only temporary ( is it? ), it will be helpful to provide an SDL2 compatible makefile.

On 2013-06-03 01:51:40 +0000, Sam Lantinga wrote:

This is fixed with the SDL_image 2.0 release candidate:
http://www.libsdl.org/tmp/SDL_image/

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Test program (example.c, application/octet-stream, 2011-06-24 00:41:23 +0000, 1687 bytes)
• valgrind logfile - on current (1.2.10) version (logfile-libsdlimage1.2.10, text/plain, 2011-06-24 00:44:42 +0000, 18781 bytes)
• valgrind logfile for patched libSDL_image (logfile-libsdlimage1.2.10-patch, text/plain, 2011-06-24 00:45:23 +0000, 16291 bytes)

Reported in version: 1.2.10
Reported for operating system, platform: Mac OS X 10.6, x86_64

Comments on the original bug report:

On 2011-06-24 00:41:23 +0000, Mike wrote:

Created attachment 633
Test program

CGDataProviderRef must be cleaned after usage.

Here is a proposed patch:
{{{
diff -r b1c1ec3a8d49 IMG_ImageIO.c
--- a/IMG_ImageIO.c Thu Apr 07 07:50:52 2011 -0700
+++ b/IMG_ImageIO.c Fri Jun 24 13:45:18 2011 +0700
@@ -103,6 +103,7 @@
// Get the CGImageSourceRef.
// The dictionary can be NULL or contain hints to help ImageIO figure out the image type.
source_ref = CGImageSourceCreateWithDataProvider(data_provider, hints_and_options);

• CGDataProviderRelease(data_provider);
  return source_ref;
  }

}}}

Attached are test program and valgrind's logfiles

On 2011-06-24 00:44:42 +0000, Mike wrote:

Created attachment 634
valgrind logfile - on current (1.2.10) version

On 2011-06-24 00:45:23 +0000, Mike wrote:

Created attachment 635
valgrind logfile for patched libSDL_image

On 2011-12-31 09:39:09 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/ec183abd5996

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.10
Reported for operating system, platform: Mac OS X 10.6, x86

Comments on the original bug report:

On 2011-10-27 11:08:25 +0000, wrote:

NOTE: This is using the latest version of SDL_image (1.2.11) from Mercurial.

The configure script for SDL_image fails to detect libpng if a –build argument is specified for i386.

Repro Steps:

• get libpng-1.5.5.tar.gz from http://www.libpng.org/pub/png/libpng.html

• compile libpng from i386

  open console window and cd to libpng source folder
  ./configure –build=i386-apple-darwin10.8.0
  make CFLAGS="-arch i386" LDFLAGS="-arch i386"
  make install
  lipo –info /usr/local/lib/libpng.dylib
  Non-fat file: /usr/local/lib/libpng.dylib is architecture: i386

• then, configure SDL_image

  cd _SDL_image_1.2.11
  ./configure –build=i386-apple-darwin10 –disable-sdltest

BUG:

configure: WARNING: *** Unable to find PNG library (http://www.libpng.org/pub/png/libpng.html)
configure: WARNING: PNG image loading disabled

However, if you compile libpng without the –build argument (i.e. building for x86_64) :

./configure
make
make install

And then invoke SDL_image's configure script without the –build argument, then the libpng library is found:

./configure –disable-sdltest

The work-around is to invoke SDL_image's configure script with the i386 build argument, and then modify the Makefile to add the missing info to the DEFS entry:

-DLOAD_PNG=1
-DLOAD_PNG_DYNAMIC="\libpng.dylib"

I hope this helps!

Regards,
Alain

On 2013-06-03 01:35:34 +0000, Sam Lantinga wrote:

This is probably a general problem with all dependency library detection. Please let me know if you find a fix!

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• strace on pingus (pingus.strace, application/octet-stream, 2010-03-05 19:56:51 +0000, 197303 bytes)
• strace on supertux (supertux.strace, application/octet-stream, 2010-03-05 19:58:15 +0000, 447128 bytes)

Reported in version: unspecified
Reported for operating system, platform: Linux, PowerPC

Comments on the original bug report:

On 2010-03-05 19:54:38 +0000, wrote:

I posted this bug against supertux on bugs.debian.org because I wasnt sure if it was in supertux or libsdl.

I believe its in libsdlimage, I dont knoe if this is a compile flag bug or an SDL bug.

I dont know how to further troubleshoot this issue but I cannot run a single SDL app. They all get illegal instruction.

The original report is here

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572420

0000:00:0b.0 Host bridge [0600]: Apple Computer Inc. UniNorth AGP [106b:0020]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 16, Cache Line Size: 32 bytes
Capabilities:
Kernel driver in use: agpgart-uninorth

0000:00:10.0 Display controller [0380]: ATI Technologies Inc Rage 128 RL/VR AGP [1002:524c]
Subsystem: ATI Technologies Inc Rage 128 RL/VR AGP [1002:524c]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 255 (2000ns min), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 48
Region 0: Memory at 94000000 (32-bit, prefetchable) [size=64M]
Region 1: I/O ports at 0400 [size=256]
Region 2: Memory at 90000000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at 90020000 [size=128K]
Capabilities:
Kernel driver in use: aty128fb

0001:10:0b.0 Host bridge [0600]: Apple Computer Inc. UniNorth PCI [106b:001f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 16, Cache Line Size: 32 bytes

0001:10:12.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB12LV23 IEEE-1394 Controller [104c:8019] (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 16 (500ns min, 1000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 52
Region 0: Memory at 80082000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at 80084000 (32-bit, non-prefetchable) [size=16K]
Capabilities:
Kernel driver in use: firewire_ohci

0001:10:17.0 Class [ff00]: Apple Computer Inc. KeyLargo Mac I/O [106b:0022] (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 16, Cache Line Size: 32 bytes
Region 0: Memory at 80000000 (32-bit, non-prefetchable) [size=512K]
Kernel driver in use: macio

0001:10:18.0 USB Controller [0c03]: Apple Computer Inc. KeyLargo USB [106b:0019] (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 16 (750ns min, 21500ns max)
Interrupt: pin A routed to IRQ 27
Region 0: Memory at 80081000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd

0001:10:19.0 USB Controller [0c03]: Apple Computer Inc. KeyLargo USB [106b:0019] (prog-if 10 [OHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 16 (750ns min, 21500ns max)
Interrupt: pin A routed to IRQ 28
Region 0: Memory at 80080000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd

0002:20:0b.0 Host bridge [0600]: Apple Computer Inc. UniNorth Internal PCI [106b:001e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 16, Cache Line Size: 32 bytes

0002:20:0f.0 Ethernet controller [0200]: Apple Computer Inc. UniNorth GMAC (Sun GEM) [106b:0021]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- <TAbort- SERR- <PERR+ INTx-
Latency: 16 (16000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 41
Region 0: Memory at f5200000 (32-bit, non-prefetchable) [size=2M]
Expansion ROM at f5000000 [disabled] [size=1M]
Kernel driver in use: gem

$ cat /proc/cpuinfo
processor : 0
cpu : 740/750
temperature : 48-51 C (uncalibrated)
clock : 400.000000MHz
revision : 131.0 (pvr 0008 8300)
bogomips : 49.93
timebase : 24967850
platform : PowerMac
model : PowerMac2,1
machine : PowerMac2,1
motherboard : PowerMac2,1 MacRISC Power Macintosh
detected as : 66 (iMac FireWire)
pmac flags : 00000014
L2 cache : 512K unified
pmac-generation : NewWorld
Memory : 256 MB

$ dpkg -l | grep sdl
ii libguichan-sdl-0.8.1-1 0.8.2-1 small, efficient C++ GUI library (SDL integration)
ii libsdl-gfx1.2-4 2.0.20-1 drawing and graphical effects extension for SDL
ii libsdl-gfx1.2-dev 2.0.20-1 development files for SDL_gfx
ii libsdl-image1.2 1.2.10-2 image loading library for Simple DirectMedia Layer 1.2
ii libsdl-image1.2-dev 1.2.10-2 development files for SDL 1.2 image loading libray
ii libsdl-mixer1.2 1.2.8-6+b1 mixer library for Simple DirectMedia Layer 1.2
ii libsdl-mixer1.2-dev 1.2.8-6+b1 development files for SDL1.2 mixer library
ii libsdl-net1.2 1.2.7-2 network library for Simple DirectMedia Layer
ii libsdl-net1.2-dev 1.2.7-2 Development files for SDL network library
ii libsdl-pango-dev 0.1.2-4 text rendering with Pango in SDL applications (developm
ii libsdl-pango1 0.1.2-4 text rendering with Pango in SDL applications (shared l
ii libsdl-sound1.2 1.0.3-3+b1 Decoder of several sound file formats for SDL
ii libsdl-ttf2.0-0 2.0.9-1 ttf library for Simple DirectMedia Layer with FreeType
ii libsdl1.2-dev 1.2.14-4 Simple DirectMedia Layer development files
ii libsdl1.2debian 1.2.14-4 Simple DirectMedia Layer
rc libsdl1.2debian-alsa 1.2.13-5 Simple DirectMedia Layer (with X11 and ALSA options)
ii libsdl1.2debian-oss 1.2.14-4 Simple DirectMedia Layer (with X11 and OSS options)

On 2010-03-05 19:56:51 +0000, wrote:

Created attachment 496
strace on pingus

On 2010-03-05 19:58:15 +0000, wrote:

Created attachment 497
strace on supertux

On 2010-03-10 06:39:28 +0000, Sam Lantinga wrote:

Can you run them in the debugger and see where they are crashing?

Thanks!

On 2011-12-31 09:33:06 +0000, Sam Lantinga wrote:

No response in a few years. :)

This bug report was migrated from our old Bugzilla tracker.

Reported in version: unspecified
Reported for operating system, platform: Haiku, x86

Comments on the original bug report:

On 2012-01-03 16:12:04 +0000, Scott McCreary wrote:

/boot/develop/haikuports/media-libs/sdl-image/work/sdl-image-1.2-hg> make
source='IMG_ImageIO.m' object='IMG_ImageIO.lo' libtool=yes
DEPDIR=.deps depmode=gcc /bin/sh ./depcomp
/bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="SDL_image" -DVERSION="1.2.11" -DLOAD_JPG=1 -DLOAD_PNG=1 -DLOAD_TIF=1 -DLOAD_BMP=1 -DLOAD_GIF=1 -DLOAD_LBM=1 -DLOAD_PCX=1 -DLOAD_PNM=1 -DLOAD_TGA=1 -DLOAD_XCF=1 -DLOAD_XPM=1 -DLOAD_XV=1 -DLOAD_TIF_DYNAMIC="libtiff.so.3" -DLOAD_PNG_DYNAMIC="libpng.so.1.4" -I. -I/boot/common/include/libpng15 -g -O2 -I/boot/common/include/SDL -D_GNU_SOURCE=1 -c -o IMG_ImageIO.lo IMG_ImageIO.m
libtool: compile: gcc -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="SDL_image" -DVERSION="1.2.11" -DLOAD_JPG=1 -DLOAD_PNG=1 -DLOAD_TIF=1 -DLOAD_BMP=1 -DLOAD_GIF=1 -DLOAD_LBM=1 -DLOAD_PCX=1 -DLOAD_PNM=1 -DLOAD_TGA=1 -DLOAD_XCF=1 -DLOAD_XPM=1 -DLOAD_XV=1 -DLOAD_TIF_DYNAMIC="libtiff.so.3" -DLOAD_PNG_DYNAMIC="libpng.so.1.4" -I. -I/boot/common/include/libpng15 -g -O2 -I/boot/common/include/SDL -D_GNU_SOURCE=1 -c IMG_ImageIO.m -Wp,-MD,.deps/IMG_ImageIO.TPlo -DPIC -o .libs/IMG_ImageIO.o
gcc: IMG_ImageIO.m: Objective-C compiler not installed on this system
make: *** [IMG_ImageIO.lo] Error 1

On 2012-01-03 19:15:01 +0000, Sam Lantinga wrote:

Fixed, thanks!
http://hg.libsdl.org/SDL_image/rev/66fc2d8ddfbc

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL_image.h.patch (SDL_image.h.patch, text/plain, 2009-02-03 11:31:50 +0000, 453 bytes)

Reported in version: unspecified
Reported for operating system, platform: Mac OS X (All), PowerPC

Comments on the original bug report:

On 2009-02-03 11:31:50 +0000, Nicolas Simonds wrote:

Created attachment 293
SDL_image.h.patch

Apple's gcc gives you this bit of syntactic sugar for free; if you include headers in the form:

#include <Some_Framework/some_header_file.h>

...the compiler will look in any relevant frameworks as well as the defined INCLUDE_PATH. If the SDL_image.framework headers are modified to use this style, it requires much less tinkering on the part of developers to get the think to compile/link.

The attached patch throws in some good vibes for us Apple folk, while hopefully staying out of everyone else's way.

On 2009-09-26 01:37:57 +0000, Sam Lantinga wrote:

This is a larger discussion about expected usage of SDL headers.
This will be evaluated with the SDL 1.3 release.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch that fixes the memory leaks against current hg (imagememerrors.patch, text/plain, 2011-08-07 00:19:51 +0000, 1239 bytes)
• Patch that fixes the memory leaks against current hg, and compiles (imagememerrors.patch, text/plain, 2011-08-09 16:28:01 +0000, 1563 bytes)

Reported in version: 1.2.10
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2011-08-07 00:19:51 +0000, Joshua Beck wrote:

Created attachment 669
Patch that fixes the memory leaks against current hg

cppcheck found these errors in SDL_image:

[IMG_xpm.c:262]: (error) Common realloc mistake: 'linebuf' nulled but not freed upon failure
[IMG_xpm.c:280]: (error) Common realloc mistake: 'linebuf' nulled but not freed upon failure
[IMG_xpm.c:127]: (error) Memory leak: hash.table

The included patch fixes all of them.

On 2011-08-09 16:28:01 +0000, Joshua Beck wrote:

Created attachment 672
Patch that fixes the memory leaks against current hg, and compiles

On 2011-08-24 23:25:14 +0000, Ryan C. Gordon wrote:

This patch is now hg changeset bb611e7cb1e5, thanks!

--ryan.