ffmpeg AltiVec on PA6-T

So, according to testing by K-L, a binary I linked with binutils 2.18 and gcc 6.1.0 works fine. gcc 6.1.0 gives some arguments to "collect2" that an older binutils doesn't understand, but I can run it manually with those arguments removed and it works fine.

There were a lot of updates to binutils since 2.18 that might have caused this problem. Does anyone with more knowledge about these sorts of things have any idea which change it might have been?

Maybe this one? https://sourceforge.net/p/adtools/code/335/

That's still 2.18 but that change came after the binutils 2.18 build in the official SDK, and zerohero's port.

Edit: I've sent a build that uses the amigaos.x ldscript from binutils 2.18, but uses binutils 2.23.2 to do the linking using -Wl,-T /path/to/amigaos.x to load the file. Awaiting result!

Edit2: Report is in! That build appears fine.

@MickJT

Is this version the one on os4depot?

@ddni

It is : http://www.amigans.net/modules/xforum ... id=108739#forumpost108739

@MickJT

That's not clear for me which build environment (cross-compiler?) you use.

You mentioned adtools on sourceforge but it moved to:
https://github.com/adtools

If you're not using the official SDK, I recommend to look at:
https://github.com/sba1/adtools

You can get gcc (and binutils) to install on OS4 or Linux (Debian).

@K-L

if there is nothing wrong with AltiVec code, maybe it alignment issue, anyway it sound strange.

@LiveForIt

Read the entire thread

@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/adtools

Years 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.

@MickJT

Have you posted this issue as a bug report on the adtools github tracker?

Does it also occur with the prebuilt native builds available from the site?

BTW the crashing issue with the ffmpeg configure script is almost certainly fixed with the latest abc-shell from os4depot. A crashing bug, due to freeing cropped path names, was fixed in that release and I had no crashes when configuring ffmpeg for my blender update.

@broadblues

Quote:

I'm still churning out binaries and having them tested by a couple of people. Then I will.

Quote:

The ones on bintray? That's something I need to test.

Quote:

I'll keep that in mind next time I need to build something natively. Thanks.

@MickJT

So it is caused by different amigaos.x files? These are text files. Any diff available?

@Deniil

Check your private messages.

@MickJT Thank you for the detailed answer. My following question would have been about filling an issue on the adtools github, but you already answered