#32 cygwin64 failure: as68 trapfunc.s -o trapfunc.bin returns 127 and no trapfunc.bin

[KotCzarny]

as stated above, in cygwin64 above command fails to work

uname: CYGWIN_NT-6.1 t500 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64 Cygwin
gcc version 5.3.0 (GCC)

[Ben G. Han]

I'm missing a bit of context here. Does it happen during compile time ? Did you compile as68 separatly before building the main tree as specified by the point -4- of README-SVN ? If as68 is present in the PATH can you copy the relevant output ?

Just in case there is a problem with as68 (which is possible) I have attached the current binary version of trapfunc.

[KotCzarny]

i compile as68 first and its in the path later. that part is working.
i have even tried running it like this: as68 trapfunc.s -o trapfunc.bin
and it doesnt return any output, but also doesnt create .bin file. and return value in shell is: 127

[Ben G. Han]

Can you compile as68 separatly in debug mode ?

../../as68/configure --enable-sc68-debug --program-suffix=-debug

Try with as68-debug, It should produce a bit more output.

[KotCzarny]

hmm, it looks like its cygwin related. when i run as68.exe inside the build dir, it works. but moved to any other place it fails silently.

[Ben G. Han]

That's weird. I'm heavily using cygwin without problem. All my builds (cyg32/cyg64/mingw32//mingw64) are made from cygwin (currently 64 because I had problems with Windows 10 spawing process in 32bit ). In my experience this kind of problem happen when running an cyg32 executable in cyg64 context or this kind of stuff.

[KotCzarny]

but then it wouldnt work at all, its somehow related to paths i think?

[Ben G. Han]

No you can exec. But somtimes it has weird effects. For exemple I remember running cyg64 sc68 from a cyg32 enviroment would not display anything (just like your case) and exit without a single message. Behind the scene it's a dll loading issue but for some reason sometime you don't get any error message.

If that's your problem then it is probably related to your PATH. Try which as68 You can use file or objdump -f to check the file executable format.

[KotCzarny]

which as68
which: no as68 in (/usr/local/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static)

file as68.exe
as68.exe: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows

objdump -f as68.exe

as68.exe: file format pei-x86-64
architecture: i386:x86-64, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x0000000100401000

---

my env is pure 64 bit i think because host is 64bit and cygsetup also was 64bit. and as i said, it works when it wasnt moved from build place, but if i copy it (even to parent dir) it fails silently.

[Ben G. Han]

Ok. I think I get your problem here. It's libtool related. You CAN NOT copy libtool objects just like that. You have to install them properly. That's what make install does. If you want to install it manually you have to use libtool to do it, Here is the libtool related doc.

[KotCzarny]

that's it! forgot that sometimes bins are located in .libs/ and only wrappers in build dir (i've got mislead by the thing that same script works on normal linux). you can close this issue as INVALID and thank you for your help!

[Ben G. Han]

No problem. it's easy to forget specially since it works with some platforms. IIRC It actually work with cygwin32.

I'm glad it's not a bug with as68. It's an old program awful to maintain. I intend to remove it someday in favor of an external 68k assembler.