[REQUEST] Update build of MIPS targets

[lars18th]

Hi @catalinii and @Jalle19 ,

I've created a new (manual) workflow to create MIPS builds. You can check it:
https://github.com/lars18th/minisatip/blob/master/.github/workflows/binaries-manual-mips.yml

Some comments with the objective of reusing some parts to update the current master binaries.yml workflow of the project:

• The extra flag -Wno-error=date-time is necessary to compile with recent compilers. The current use of the __DATE__ and __TIME__ macros breaks any reproducible compilation. And new compilers refuse to compile (by default) non-reproducible binaries. So, I suggest to target this issue in the future. But in the meantime it will be useful to set this flag. You agree?
• The second point is to update the ZIG CC compiler. At time the binary is installed directly in the container catalinii/minisatip-build-image. But a recent (5 days ago) master version of zig has updated support for MIPS targets. Therefore, using the master release you can compile for MIPS GNU and MUSL targets without troubles. But the best point is that you can use the external Action goto-bus-stop/setup-zig@v2 to setup the ZIG CC compiler. And it has cache support. So I suggest to change the container to move this ancient compiler to /opt/catalinii/zig and remove it from the PATH. Please, check my dirty workaround command mv /opt/zig /opt/zig.disabled in my workflow to overcome this compiler. My suggestion is to not remove the compiler, but not add it to the PATH. So you can still use it if you want it.
• And the last is to enable MUSL and GNU mips targets at the same time. And for the GNU version if you use -target mipsel-linux-gnueabihf.2.30 then you will support Linux 4.x kernels and OpenATV 6.x devices. Because these releases are static then it has sense to support ancient devices. For more optimized versions, a cross-compiler for the specific target using dynamic linking will be preferable. But for these releases I recommend in this way.

I hope you want to update the releases.
Regards.

[Jalle19]

IMO we should move away from minisatip-build-image, it only makes things more complicated right now. I need to figure out how to get Coverity Scan working first, then I'll have time to look at this.

[lars18th]

Hi @Jalle19 ,

If you accept to compile all targets using the ZIG CC compiler (based on clang), then we can work on it. At time releases for MIPS, ARM and X86-64 are not a problem. The problem is the AXE target. Any idea to support it using the zig cc tool?

[Jalle19]

@lars18th can you make a pull request with your new workflow, but remove container: catalinii/minisatip-build-image:latest? Then we'll fix whatever needs fixing for the build to succeed.

[lars18th]

Hi @Jalle19

@lars18th can you make a pull request with your new workflow, but remove container: catalinii/minisatip-build-image:latest? Then we'll fix whatever needs fixing for the build to succeed.

The resquested PR is #1177 . I hope you want to merge it (as a reference) and then update the binaries.yml. However, some ideas for it:

• Perhaps you want to add MUSL and GNU versions for all targets compiled with ZIG CC (x64, ARM and MIPS). In this case, perhaps the best is to maintain the current names (minisatip_???.zip) for the GNU version and use alternate name (minisatip-musl_???.zip) for the MUSL version. You agree with that?
• I don't know if the AXE build could be done without the container, because the --host=sh4-linux parameter. Inside the container is /opt/STM/STLinux-2.4/devkit/sh4/bin but I don't know if this is really used. You know it?
• The last question is about the libraries compiled inside the container. I feel they need them to be compiled standalone, or not?

Regards.

[Jalle19]

Perhaps you want to add MUSL and GNU versions for all targets compiled with ZIG CC (x64, ARM and MIPS). In this case, perhaps the best is to maintain the current names (minisatip_???.zip) for the GNU version and use alternate name (minisatip-musl_???.zip) for the MUSL version. You agree with that?

I don't really have an opinion either way

I don't know if the AXE build could be done without the container, because the --host=sh4-linux parameter. Inside the container is /opt/STM/STLinux-2.4/devkit/sh4/bin but I don't know if this is really used. You know it?

Yeah, I'll see what I can do about this one. We need to stop using the base image that minisatip-build-image uses because it's not possible to build it from scratch anymore, the only working version is the image that's currently published to Docker Hub.

[lars18th]

Hi @Jalle19 ,

The lines make EXTRA_CFLAGS="-I/sysroot/mipsel/include -L/sysroot/mipsel/lib" EMBEDDED=1 are not needed if we don't use the container (you can remove them). And I'm not sure, but I think that @catalinii is using it to link with the libdvbcsa and openssl versions from the container. So the question is: compiling with ZIG CC it's necessary to use any special library, or we can go with the stock versions? Perhaps for the libdvbcsa we need the patched version (from https://github.com/catalinii/libdvbcsa), but for others it's really needed?

[Jalle19]

@catalinii what is the purposw of your libdvbcsa patch?

[lars18th]

@catalinii what is the purposw of your libdvbcsa patch?

Easy! Support for ICAM and similar ECM manipulations.

[Jalle19]

Okay

[catalinii]

@lars18th can you make a pull request with your new workflow, but remove container: catalinii/minisatip-build-image:latest? Then we'll fix whatever needs fixing for the build to succeed.

Should I try to fix minisatip-build-image?

[Jalle19]

@catalinii I think it would be best to move away from it completely, it's clearer if everything needed for CI is available in this repository.

[catalinii]

I am not opposed to it, but we would have to build libdvbcsa, netceiver and openssl for all targets somehow: https://github.com/catalinii/minisatip-build-image/blob/master/build_libraries.sh

this will make the binaries build much slower

[catalinii]

Then axe building…

[Jalle19]

I'll have to think about it some more