40 replies to this topic

[samsamsam]

@athoik this discussion have no sense @Erik Slagter know better what is bug and what is not bug.

He know better than kernel developers. He know better than author of these extension of ABI.

 

But I am afraid that he still not understand the issue.

 

Regards,

SSS

[athoik]

@SSS, both have valid arguments.

Personally I think since we have a regression in the kernel, since we have ready patch, let's apply it and see if that will solve the problem.


I'll send create the PR for et4x00 BSP soon, and let's hope that will fix problem, since I cannot test my self (no et4x00 hw available here).

[Erik Slagter]

@athoik, what do we need compatibility with old binaries for?

Edited by Erik Slagter, 21 October 2017 - 20:06.

[athoik]

Why not, kernel developer add something that is causing a regression and it was fixed, later.

(although nobody confirmed that patch I mention is really solving the issue)

Personally I have no problem adding a missing patch in kernel, that exists already in newer kernels.

[Erik Slagter]

Although it's definitely something we do not need, I agree solving a regression in a simple way is always preferrable. I am quite allergic to all sorts of binary blobs, many of them related to illegal business (otherwise they could just as well supply the source code...)

[athoik]

@Erik, Like I said, both @SSS and you, have valid arguments.

I guess completely dropping all closed source binaries (mostly cams) from feeds is something to consider for next major release.

Only the cams with sources should be build and delivered to feeds.

Edited by athoik, 22 October 2017 - 09:26.

[littlesat]

Why do you need all these binary blob cams while Oscam can do all?

[Erik Slagter]

The softcams are a gray area. I guess the deserve some purpose. I'd rather have them out, but I guess Oscam will not suffice for every card available. We may or may not try to get them all out. It would be preferrable if it was possible, but maybe we can't.

 

In my previous statement I am rather referring to "other" binary blobs, by "3rd parties".

[MastaG]

maybe we should first look into which binaries are affected by this?

adding patches to older kernel's means that we need to start testing them and submitting PR's to their bsp-layers..

if it only concerns stuff like cccam, mgcamd etc.. then fuck 'm

[Erik Slagter]

Please go ahead and start the investigation. I already know the outcome.

 

- almost all binaries are generated by OE during the build process and are by definition compatible because they were built against the same libs

- some closed source softcams

- a few binaries that the developer doesn't care to make a recipe for

 

In the last category:

 

- the developer lacks the skills to do that, I guess we should step in there

- the developer has something to hide, I don't want to see or support these binaries, especially also because they violate the GPL license they're bound to

[XRayhTec]

Hi,

 

I applied Set O32 default FPU flags patch to kernel 4.0.1 on et4000 (mips32el-nf)

 

This results in:

 /usr/local/hbb-browser/lib/hbbtv.app: Accessing a corrupted shared library

 

For this case the patch is not working.

 

When building without the -nf everything is working as intended.

 

Regards,

[XRayhTec]

Now the better news

 

I now applied:

Improve the overall ABI and FPU mode checks patch

Set O32 default FPU flags patch

 

No more "Accessing a corrupted shared library"

 

Regards,

[MastaG]

Thanks xrayhtec for verifying.
Now somebody needs to start forking all meta- bsp layers and submit a shitload of pull requests.

Respect for the members doing this, but I'm not going to be the one saving other people's precious cccam

[athoik]

Now the better news
 
I now applied:
Improve the overall ABI and FPU mode checks patch
Set O32 default FPU flags patch
 
No more "Accessing a corrupted shared library"
 
Regards,

Can you create a PR here? https://github.com/X...eam/meta-xtrend

Or just provide the hash of patch "Improve the overall ABI and FPU mode checks patch" in order to add it to existing PR.

@MastaG, I think only et4x00 is affected.

Edited by athoik, 25 October 2017 - 22:06.

[samsamsam]

@athoik

 

What about XP1000?

 

Regards,

SSS

[athoik]

I thought that older kernel was used on xp1000, but they use 4.0.1 too.

So patches for meta-xp required too!

[XRayhTec]

 

Now the better news
 
I now applied:
Improve the overall ABI and FPU mode checks patch
Set O32 default FPU flags patch
 
No more "Accessing a corrupted shared library"
 
Regards,

Can you create a PR here? https://github.com/X...eam/meta-xtrend

Or just provide the hash of patch "Improve the overall ABI and FPU mode checks patch" in order to add it to existing PR.

@MastaG, I think only et4x00 is affected.

 

Unfortunately I have no idea how to do such. I am not familiar with github.

 

However the error message does not arise anymore but the application is also not  responding as intended. I have to figure out what happens there.

For functionality I still stick to Building without -nf.

 

Regards,

[XRayhTec]

Hello,

 

Some deeper investigation

 

Hello,

 

The soft-float ABIFLAGS + no ABIFLAGS combination combination binaries cause faile "Accessing a corrupted shared library".

This problem is confirmed issue and related to ABIFLAGS  extenstion please read:

https://www.linux-mi...1/msg00290.html

for more information.

 

This cause problem when you want to run mipsel binaries compiled without ABIFLAGS extensions and use shared libraries compiled with this extension and vice versa.

 

 

The application I used for investigation indicates following:

File Attributes
  Tag_GNU_MIPS_ABI_FP: Hard float (double precision)

 

So this is different than the initial problem (soft-float ABIFLAGS + no ABIFLAGS combination)

 

My combination hard-float ABI flags + soft-float ABI flags.

 

Despite the error message is gone in this case the application is not running and something says me that never will be. Correct me if I am wrong.

 

 

Regards,

 

 

 

[dobrogi]

I thought that older kernel was used on xp1000, but they use 4.0.1 too.

So patches for meta-xp required too!

 

Yes, my XP1000 box is also affected.
ffmpeg3.2.2: error: "Accessing a corrupted shared library"

Regards, Celeburdi

Edited by dobrogi, 29 October 2017 - 18:21.

[gorski]

The problem was reported here, for instance: https://forums.openp...dreambox/page-2

 

I tested in XP1000 with OpenPLi 6 and no joy. OpenPLi 4, in the same box, was OK > IPTV Player was fine.

 

As an IT lay person my gut feeling was correct, I see from SSS and Athoik posts now...

 

"Yeah, it seems to me - an IT lay person - that OPenPLi 6 has a number of things different and so some older things might be missing and then... we have to find a way around them..." Now I "understand" a bit better...

 

https://forums.openp...and-info/page-3

 

Thanx to SSS, Athoik and co. for investigating and trying...

Edited by gorski, 30 October 2017 - 11:57.