Actually, configure in gtk+ fails to find atk on cygwin.
The reason for that is because atk is compiled (by libtool,
on cygwin) as a static library but *without* the object
file that contains 'atk_object_get_type' (atkobject.lo).
The reson for that is discusably a bug in libtool: it
should actually have aborted with an error; but instead
only complains about the fact that it is not allowed to
created shared libraries on cygwin with undefined symbols
and then proceeds to create an archive (.a) that is unusable
because it leaves out a few .lo files. The reason that libtool
leaves out these .lo files is because they were compiled
for a .dll and are marked as 'PIC object' without that a
non-PIC object was compiled. libtool then thinks that there
is no need to include these .lo files in the .a archive.

The solution to this is simple: You need to add '-no-undefined'
to the LDFLAGS.  This flag is recognized by libtool --mode=link
and is stripped before starting the linking process.  It tells
libtool that this library does not contain any undefined symbols
(except for system libraries like libc, which are resolved by
libtool itself somehow) and that therefore it is safe to generate
a .dll.  Only then atkobject.lo will be included and it will be
possible again to configure and compile gtk+ on cygwin (and mingw).

Please note that this means that any shared libraries (dll's) that
libatk depends on must be passed to the linking process of atk as
well: if libatk depends on libglib - then it must be linked with
libglib.la.

How to add -no-undefined to the LDFLAGS can be seen in the glib
project, which is doing this correctly.  Have a look at glib/Makefile.am
for an example of how it was done there.

I hope that this can be fixed soon and will lead to a quick release
of atk-1.6.1; I need gtk+-2.4.3 on cygwin.