The Generic Image Decoder (GID) is an Ada package for decoding a broad
variety of image formats, from any data stream, to any kind of medium,
be it an in-memory bitmap, a GUI object, some other stream, arrays of
floating-point initial data for scientific calculations, a browser
element, a device,...
Animations are supported.
Currently supported formats are: BMP, GIF, JPEG, PNG, TGA.
No bindings, eh? I'm impressed. Is it mostly translations? For
instance, did you translate the libpng for the PNG encoding?
I'll try it out soon.
> Quite excellent.
Thanks - but try it first ;-)
> No bindings, eh? I'm impressed. Is it mostly translations? For
> instance, did you translate the libpng for the PNG encoding?
JPEG is mostly translated from NanoJPEG; the rest has been written
from scratch, with a good part of re-use from other Ada sources.
For instance the PNG decompression is taken from the Zip-Ada sources;
the GIF decompression is a contribution.
> I'll try it out soon.
I'd be glad to have some feedbacks.
A quick note.
I just tried compiling this package with a GNAT compiler built from
the gcc 4.4.2 sources and the GNU binutils package and got the classic
`cannot find libaddr2line.a' error. I understand that this library
comes with the binutils supplied by AdaCore with their binaries and
sources, but I prefer to build my compilers from the actual GNU
sources if at all possible.
Searching comp.lang.ada, I've come to understand that in more recent
GNAT versions (later than GNAT 2009?), and hopefully more recent GCCs
(i.e. gcc 4.5.0), GNAT no longer needs libaddr2line. I'm compiling
a new gcc right now. Hopefully this will fix the problem. I'll let
> Searching comp.lang.ada, I've come to understand that in more recent
> GNAT versions (later than GNAT 2009?), and hopefully more recent GCCs
> (i.e. gcc 4.5.0), GNAT no longer needs libaddr2line. I'm compiling
> a new gcc right now. Hopefully this will fix the problem. I'll let
> you know.
On Mac OS X, GCC 4.5.0's GNAT.Traceback.Symbolic says
-- Version used on unimplemented targets
-- Run-time symbolic traceback is currently supported on the
-- following targets:
-- GNU/Linux x86
-- Solaris sparc
-- Windows NT/XP/Vista
-- This version is used on all other targets, it generates a warning
-- at compile time if it is with'ed, and the bodies generate
-- messages saying that the functions are not implemented.
The working version (g-trasym.adb) in the 4.5.0 sources includes
package body GNAT.Traceback.Symbolic is
pragma Linker_Options ("-laddr2line");
pragma Linker_Options ("-lbfd");
pragma Linker_Options ("-liberty");
and hasn't changed on trunk.
Maybe GNAT GPL 2010 will have the promised change ...
Anyway, you should be able to find where GNAT.Traceback.Symbolic is
referenced, usually in the main program, and revert to plain (hex)
> A quick note.
> I just tried compiling this package with a GNAT compiler built from
> the gcc 4.4.2 sources and the GNU binutils package and got the classic
> `cannot find libaddr2line.a' error.
I guess you tried to build tb.ads in the "Debug" mode (that's the
default), which uses GNAT's symbolic traceback. You can build
to_bmp.adb or mini.adb - without the trace-back wrapper - and also try
other build modes as well. Or even use a complete version of GNAT or
even another compiler ;-).
Gautier's Ada programming -- http://gautiersblog.blogspot.com/
Yup. I ran `gnatmake -Pgid' with no other switches, which I _knew_
compiled in Debug mode, but I didn't really consider the implications.
So now, here I am compiling GCC 4.5.0, trying to navigate the strange
and frightening labyrinth of installing and updated CLooG/PPL, GMP,
MPFR and MPC while not torching half my Debian toolchain, and I
could've just added -XBuild_Mode=Fast... Oh, well. A reinstall of GCC
was bound to happen soon anyway.
Since you're on Debian, gnat-4.4 has working symbolic tracebacks. They
are unfortunately broken in gnat-4.3.
Actually, I'm really impressed with the job you've been doing
packaging GNAT for Debian. I have it installed, too, but I've never
felt comfortable polluting my system's environment with libraries,
etc, that I'm just playing around with. I _do_ use the Debian-
supplied compilers to test code that I've written, to make sure that
it doesn't break in a ``clean'' environment.
I think I originally compiled my current installation of GNAT-from-GCC
because I wanted to try out the AVR libraries, and found that I just
felt more comfortable building other Ada libs from source in my local
toolchain. Of course, there is the whole maintenance issue, but
that's the price I pay for control. Personally, I _really_ prefer
building from scratch, ala Linux From Scratch, but haven't had the
time to devote to that recently. If only the Hurd were stable enough
to build and maintain a production environment from sources; then I'd
be really happy.