X265 from haiku depot

Hello, I see latest build for x86_64 reports “[noasm]” which means no SIMD instruction support builtin → slow encoding times.
Why doesn’t this build enable asm instructions?
I mean, is it on purpose or the build scripts are still not haiku-friendly enough?

It seems there is no other reason than nobody enabled it yet.

Maybe modify the recipe and send a PR.

3 Likes

Well, I just tried to build myself, with poor results.

The build/ subdirectory has a bunch of scripts suitable for different OSs/compilers, I went into linux/ one and run make-Makefiles.bash (which in turn calls cmake). ‘nasm’ detected, accepted the default and run ‘make’:

[…]
[ 97%] Building CXX object CMakeFiles/cli.dir/x265cli.cpp.o
[ 98%] Building CXX object CMakeFiles/cli.dir/abrEncApp.cpp.o
[100%] Linking CXX executable x265
/boot/system/develop/tools/bin/…/lib/gcc/x86_64-unknown-haiku/8.3.0/…/…/…/…/x86_64-unknown-haiku/bin/ld: libx265.a(cpu-a.asm.o): relocation R_X86_64_PC32 against symbol `x265_intel_cpu_indicator_init’ can not be used when making a shared object; recompile with -fPIC
/boot/system/develop/tools/bin/…/lib/gcc/x86_64-unknown-haiku/8.3.0/…/…/…/…/x86_64-unknown-haiku/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
CMakeFiles/cli.dir/build.make:257: recipe for target ‘x265’ failed
make[2]: *** [x265] Error 1
CMakeFiles/Makefile2:200: recipe for target ‘CMakeFiles/cli.dir/all’ failed
make[1]: *** [CMakeFiles/cli.dir/all] Error 2
Makefile:135: recipe for target ‘all’ failed
make: *** [all] Error 2

Do I need some fixes? How can I tell cmake to add ‘-fPIC’ into makefiles?

EDIT: the cmake user interface already reports ENABLE_PIC = ON

I would recommend you to analyze the linked recipe, install all the listed dependencies manually, try to apply the existing patches manually and then try again.
Or just get comfortable with haikuporter.

1 Like

Oh, and use the build-system invocation like it is done in the recipe.
A naive attempt to build things (like you did) wont be painless rxperience, most *nicy software is platform-dependant, not in source, but because the build systems assumes too many non-posix stuff. And Haiku is not a *nix.

1 Like

Done!
You were right, the build completed with no issues following the cmake invocation as in the recipe (and applying the patches)!
And the x265 binary has now assembly optimizations as on my debian box :slight_smile:

The one and only thing I’m not sure about the recipe is that “cmd:yasm” among the BUILD_PREREQUIRES. The shipped cmake scripts actually don’t care about yasm, they fail when nasm is not found, as nasm is all they seek for.
Maybe when the recipe sets everything up for a build (with yasm as required assembler) the result is a non optimized binary ?

Why dont’t you test the recipe with your extra modification and with and without yasm and with and without nasm?
You have basically every means at your hand to test your theory, they why to ask?

2 Likes

Well, how can I “run” a recipe?

1 Like

Have a look at the blog post Building packages with haikuporter .

2 Likes

Done.

2 Likes

What if I want to add a patch to the patchset?
How can I achieve the right format for the headers?

When you build the recipe using haikuports, it will create a git repository in a directory named work-$version. You can go there and make any changes you need to the code, and commit them using git.

When you are done, use haikuporter --extract-patchet, it will automatically create or recreate the patchset file with all the changes.

Done.

5 Likes