do you tried al_iio_init();??

EDIT
sorry, I didn't see that iio_load_png was working
could you tell us what is the error?

I had to run cmake 3 times for it to work.
first to generate "CMakeCache.txt", you'll find 2 lines:

//Path to a file.
ZLIB_INCLUDE_DIR:PATH=C:\VSC\include

//Path to a library.
ZLIB_LIBRARY:FILEPATH=C:\VSC\lib\zlib.lib

if cmake couldn't find zlib, something like NOTFOUND (can't remeber, sorry) will be written.
after change the file and save it, run cmake again, and when you re-open the file, 2 PNG PATH lines will appear.

This is an interesting issue. I tested myself under Linux with the latest SVN, and al_iio_load loads a png file just fine. If I ever end up in Windows I can try to install the 4.9.4 release and see what happens.

I did nothing special with cmake, but in Linux things tend to work automatically. At least in my experience.

Here is the contents of that file:

/* #undef ALLEGRO_CFG_IIO_HAVE_PNG */

Did that two or three times already.

Just tried it and indeed it did find everything I had but the runtime issue still remains. Even though libpng and libz are linked into liba5_iio, somehow al_iio_load() is not aware of this. I can still use iio_load_png() directly but that is not exposed by the API therefore I shouldn't really be doing that.

I may tinker with it myself this afternoon and see if I can find out what is going on.

Yes. I am loading other images as well (PCX, TGA) and all those work fine.

Edit: I have confirmed that the PNG handler is not being added during al_iio_init().

Edit 2: ALLEGRO_CFG_IIO_HAVE_PNG is not defined when "iio.c" is being compiled even though cmake shows that it has found PNG support. I'm not sure how cmake works but according to the "CMakeLists.txt" file ALLEGRO_CFG_IIO_HAVE_PNG is defined when PNG_FOUND is true. If that's the case then somehow that information must not be getting passed along to the compiler.

Edit 3: I redid everything from scratch in a new folder and it worked. I guess I screwed something up in all my tinkering with the settings.

Hmm, it is not working. For some reason when I was rebuilding my project, a new executable wasn't being created. I remedied that problem and now the original problem still stands.

The patch fixed it!

Todd, can you tell me which version of CMake and which C compiler you're using? The patch Trent posted is only a hack (which will be reverted), and I'd like to figure out why it wasn't working before.

I tried it in a virtual machine with Windows XP, and a completely fresh installation of mingw. CMake 2.6-patch 1, gcc 3.4.2. Works for me.

I unpacked allegro-4.9.4 in c:\allegro, and built in a subdirectory called "Build". c:\allegro\Build\include\allegro5\internal\aintern_iio_cfg.h contains:

#define ALLEGRO_CFG_IIO_HAVE_PNG

ex_bitmap loaded a PNG file okay.

So, I don't know what to make of it. To help you debug it, this is how it's supposed to work:

- CMake finds zlib and libpng
- CMake generates aintern_iio_cfg.h from aintern_iio_cfg.h.cmake
- iio.c includes iio.h, which includes aintern_iio_cfg.h
- iio.c checks if ALLEGRO_CFG_IIO_HAVE_PNG is defined and registers the handler

I can only imagine that you have another file called aintern_iio_cfg.h somewhere, which is being picked up instead. Try entering some gibberish into aintern_iio_cfg.h which would cause the C compiler to abort, just to make sure it's looking at the right file.