Cygwin is a complicated platform, any reason you're not using "normal" Windows or some "normal"  Unix/linux?

That aside: There shouldn't be any dll's or so's being built. Can you please check the created .out / .diff files from the tests to see whether the report any specific error? If they run at all PHP can't be totally broken as the test runner is using PHP, too. I guess it is some php.ini related error.

For most development I'm using "normal" Windows builds,
but for some experiments I prefer the Unix toolchain,
so Cygwin comes in handy (I could use a virtual machine,
but it seems a bit heavyweight).

I should have noted in the first place that the compiled
PHP seems to run fine; at least I haven't noticed any issues
yet (neither CLI nor CGI).

basic/001.out:
  /home/cmb/php-5.5.2/sapi/cli/php.exe: error while loading
  shared libraries: ?: cannot open shared object file: No 
  such file or directory

The other .out files have the same message (I've checked 
only a handful, however).

This looks like some environment problem. PHP does not load its own shared libs, 
so whatever is going wrong is going wrong either in the compiler or in the 
environment. If you're getting this message with tests but not when you run 
either -v or -i, the difference may be either php.ini or some environment vars.

You might have linked with incompatible library.

ldd php or ldd libphp5.so too see what are linked.

It may happen during build also.
I recently helped a user who had build problem due to libtool installed under 
/usr/local. Explicitly using proper libtool solved the problem.

Look for suspicious errors in build log, too.

Indeed it is an issue related to the php.ini.  When I remove it or 
disable it for single tests with -n, most tests succeed (I'll
send a report about the failing tests to the qa-reports list).

According to README.TESTING [Which php.ini is used] it shouldn't
matter which php.ini is used.  But both php.ini-production as well
as php.ini-development cause all tests to fail ("error while loading
shared libraries").

However, no errors are reported when running PHP with either of both php.ini
files.

So you most likely have another php.ini which is loaded which tries to load a shared extension which fails.
the test system is supposed to verify PHP wors with "all" *valid* configurations.

check the ini files the test runner mentions at the top of the output under "INI actual" and "More .INIs"

The test runner reports:

  INI actual  : /usr/local/lib/php.ini
  More .INIs  :

When this file is a copy of the shipped php.ini-developement
resp. php.ini-production (I tried both), all tests are failing.

Through some expermentation I found that the variables_order
setting (which is "GPCS" in both php.ini files) is causing the 
tests to fail.  It seems to be necessary that "E" is included
on my system.

Through further expermentation I found that the environment 
variable PATH is necessary to successfully run the tests.
Adding the following line at the beginning of run-tests.php
was sufficient:

  $_ENV['PATH']=getenv('PATH');

My PATH contains nothing special:

/usr/local/bin:/usr/bin/:/cygdrive/c/WINDOWS/system32/:/cygdrive/c/WINDOWS/:/cyg
drive/c/WINDOWS/System32/Wbem/

FWIW: PHP 5.4.19 and PHP 5.5.3 show the same behavior.

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.