Compiling SDL within Adobe Crossbridge's Cygwin - c++

Question

Crossbridge allows you to compile C/C++ programs to target the flash runtime. It comes with its own modified gcc within cygwin. Since SDL only provides developmental zips for VC or mingw, I'm trying to compile SDL within this cygwin environment. However Crossbridge's gcc is version 4.2.1 and according to google searches SDL cannot be compiled with gcc versions higher than 3 inside cygwin. When I run ./configure, it fails with:
*** Your compiler (/cygdrive/c/Users/Tom/Desktop/Crossbridge_1.0.1/sdk/usr/bin/g
cc.exe -jvmopt=-Xmx1G) does not produce Win32 executables!
When I just type gcc alone, I get:
bash: /usr/bin/gcc: cannot execute binary file
Does it make a difference if I compile SDL using one compiler (i.e., a lower version of gcc) and attempt to use it with the Crossbridge compiler?
Is there a workaround for this?

Answer 1

I checked the Crossbridge_1.0.1.zip, cc and gcc maybe are broken link (only 56 bytes?) but the gcc-4 seem to be good.
edit
type gcc-4 as you typed gcc from the bash and you'll see the usual expected no input files gcc's error message, try gcc-4 -v
the message Your compiler does not produce Win32 executables is given by the fact that whatever you've executed (or has been executed automatically) is using /cygdrive/c/Users/Tom/Desktop/Crossbridge_1.0.1/sdk/usr/bin/gcc.exe as your compiler, but as you already checked it doesn't work, and if you check it with ls -l /usr/bin/gcc.exe you'll see that this is only 56 bytes size, this can't be the real compiler, I guess it probably was a symbolic link to the real compiler, which for some reason isn't working as expected (on linux executing a symlink is as executing the real binary).
I'm not an expert of cygwin, but I guess at some level symlink are supported, reading this FAQ make me wonder if some attribute hasn't lost packaging/unpackaging the zip, so that the symlink aren't recognized.
Try to recreate it (it worked for me):
cd /usr/bin # change directory
rm gcc.exe # remove the broken link
ln -s gcc-4.exe gcc.exe # re-create the symlink
run gcc again, should return the no input files error as expected.
But this isn't the solution, because probably in the unzipped files there are many broken symlink.
I can't believe Adobe is distributing a broken SDK, so perhaps there's some instruction somewhere about how to properly unzip the SDK preserving the symlinks (maybe unzip have a preserve attribute option? I don't know much about zip sorry.
edit
execute the run.bat (the bash) and cd to the main directory where you unzipped the SDK (mine is /cygdrive/c/crossbrige)
cd /cygdrive/c/crossbrige
for f in $(find ./ -type f -print0 | xargs -0 grep '!<symlink>' -l); do attrib +S $f; done
this should hopefully fix all the broken symlink, the only side-effect is that any file containing !<symlink> will get set the attribute DOS SYSTEM, but cygwin check both this magic string at offset 0 and the S attribute to consider a file as a symlink, so hopefully will not break anything.

Answer 2

I used Alex find/ attribute loop to fix all broken links in my cygwin install. I have no idea why they appeared.
The first attempt failed with messages like:
Invalid switch - /usr/lib/terminfo
for each file attrib worked on.
Turned out that for my cygwin/Windows combo I had to cd into the directory and execute attrib from there. So the loop content was:
do cd $(dirname $f); attrib +S $(basename $f); done