@corto
I'll give a full
but brief story.
I'm using my own Cygwin x86 build (on a 64bit machine) of gcc 6.1.0 and binutils 2.23.2 from
https://github.com/sba1/adtoolsYears ago, ffmpeg's configure script started crashing abc-shell. This is before I had a cross-compiling set up. I would use a Linux VM and run the configure script there to generate the Makefile and config.h/.mak, then modify them, transfer those to the Sam440 and build it there.
Then later I set up a cross-compiling environment, using zerohero's adtools (gcc 4.2.4 and binutils 2.18) in a Linux VM. Worked fine.
Then I started to build adtools myself from the sourceforge repo, and since then, I've never been able to get anything that uses altivec instructions to work properly. I myself don't have a machine that I run these binaries on, but some friends test them for me.
I tried different branches of gcc & binutils on sourceforge, and all had the same problem. I thought it might be something I was doing, or my compiling environment.
On a whim I decided to transfer the whole directory structure of ffmpeg to my Sam440ep-Flex, keeping all the already compiled .o/.a files, and just re-link the binaries there, and the people that tested those said it worked! So that's what I did for a while, and then I set up a Cygwin environment and started linking it there, using zerohero's gcc 4.2.4 / binutils 2.18 build.
This time with ffmpeg 3.4, it had been a long time since the last port I did, and I have a different PC now and built adtools from scratch again, and I thought I'd try not re-linking this time. I sent the binary for testing, but obviously that wasn't thorough enough :) When K-L posted this thread, I knew exactly what to do to fix it (I just wanted to rule out a couple of things first).
So now I wanted to track down the root cause. So, knowing that re-linking fixed it, I knew it had to be either linker libs (libgcc/gcc_eh etc.), or the way the binary itself is put together. Turns out to be the latter.
The common denominator amongst ALL of my own adtools builds, including ones using binutils 2.18, is that they're all built after February 2010. At the moment I'm guessing it's revision 335 on sourceforge that did it. The official OS4 SDK and zerohero's port were done prior to that revision.
Using ldscripts/amigaos.x from the official SDK and loading it manually using -Wl,-T /path/to/amigaos.x (otherwise it will use an internal one), I can use binutils 2.23.2 / gcc 6.1.0 again and the altivec instructions work properly again!
I could be wrong about the exact cause. All I know is using the external amigaos.x from the OS4 SDK solves it.