40 replies to this topic

[samsamsam]

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.

 

May I ask if OpenPLI team plan to apply patch to fix this problem?

 

Regards,

SSS

Edited by samsamsam, 17 October 2017 - 18:46.

[samsamsam]

This problem was reported for example here:

https://forums.openp...li-6-and-cccam/

 

I read @littlesat answer:

It might be cccam needs old ancient libraries that are not anymore there in openpli 6.0.. In between cccam is already an almost 5 years old binary blob... 

 

But this was wrong diagnos. I think when we know real reason you can consider to apply patch to allow to run binaries compiled without ABIFLAGS.

 

Unfortunately, I do not have hardware with MIPSEL CPU without FPU supported by OpenPLI, so I am not able to test patch.

[littlesat]

Is this alone for cccam or do you have more (closed source) plugins that suffer from this?

[samsamsam]

@littlesat

 

I am not talking about closed plugins, I am talking about backward compatibility. There is no reason why old binaries without ABIFLAGS cannot be run on rootfs build with ABIFLAGS.

 

Of course in case closed cccam you are not able to run it because you do not have source code to recompile it with this ABI extension, but you will not be able for example to run binaries compiled with official toolchain provided by Broadcom.

You will not be able to run binaries from OpenPLI 4 to confirm problem with new version of some utilities and so on.

 

Anyway even if you not want to apply patch at least now you will know the root cause of the problem.

 

Regards,

SSS

Edited by samsamsam, 17 October 2017 - 19:31.

[Erik Slagter]

I am not talking about closed plugins, I am talking about backward compatibility. There is no reason why old binaries without ABIFLAGS cannot be run on rootfs build with ABIFLAGS.

You are contradicting yourself here. If there is source available, we can always (and must do so) compile the source and the output will always match the current libraries.

 

This is exactly why I hate plugins (especially with binaries in them) that are not compiled by OE as part of the image building process.

There is no room in an open source image for binary blobs. I am not going to spend any time on this.

[littlesat]

+1....

[samsamsam]

Hello @Erik Slagter

 

 

You are contradicting yourself here.

 

No. I do not contradicting myself.

I think you really do not understand what I mean.

But I am sure that you understand that when you want to investigate issue and check if the problem is not related with new binaries it is important to make do this fast check on diffrent binaries.

 

Of course you can take old source and compile but there are two problem:

- time needed to do this

- problem can be related with toolchain or compilation options

 

There is no room in an open source image for binary blobs.

 

This is really funny   I hope you know that each image build by OpenPLI build system contains such blob.

Do you realize it?

 

I am not going to spend any time on this.

 

But I hope that now you know what is root couse and OpenPLI team members will not misleading others users. That was my goal.

 

Regards,

SSS

Edited by samsamsam, 18 October 2017 - 19:01.

[athoik]

Dear SSS,

I had a quick view on the discussion, and the problem is a specific commit that merged on kernel 3.x, right?

So reverting that commit fixes some issues with some old binaries, on mispel-nf.

I can try to create a patch for affected machines, in case you have the hash of commit that would be perfect.

Thanks for your help on affected OpenPLi users.

PS. Out of topic, you might interting adding free proxy on iptvplayer (many countries included) using that project https://github.com/spaze/oprah-proxy

[samsamsam]

Hello @athoik

 

Thank you for the information about Opera Proxy. I will check it at free time.

 

Once again thank you very much.

 

Regards,

SSS

Edited by samsamsam, 18 October 2017 - 19:37.

[WanWizard]

This is really funny   I hope you know that each image build by OpenPLI build system contains such blob.

Do you realize it?

 

That should be limited to the drivers and related files in the BSP. We wish we had the source, but unfortunately they are under heavy NDA. Since they are vital to the image itself, this can't be helped.

 

Other blobs we try and want to avoid, any others you know of?

[Taapat]

@samsamsam have you checked the build system before you write?

Are you sure that it's not fixed some time ago?

https://github.com/O...8cc7553bf305977

[samsamsam]

Hello @Taapat,

 

Mentioned by you problem it is different one than this which causes error:

 

Accessing a corrupted shared library

 

 

Regards,

SSS

Edited by samsamsam, 19 October 2017 - 20:15.

[athoik]

Hi,


I think this one is the commit we are talking about:

1. https://git.kernel.o...72beb2941e55ede

Some time later a fix was commited:

2. https://git.kernel.o...c47363b37e54450

and another one:

3. https://git.kernel.o...debe84ae47d454b


I am almost sure that simply applying patch 2 will fix the issue.

PS. The et4x00 misses the patch 2 (already check it)

Edited by athoik, 19 October 2017 - 21:14.

[Erik Slagter]

This is really funny   I hope you know that each image build by OpenPLI build system contains such blob.
Do you realize it?

It's called drivers, they live in the kernel and have no API-wise interaction with user processes. So your point is moot.

[athoik]

Anyone with affected hardware here, able to reproduce the problem, willing to test image with patch kernel?

[samsamsam]

Hello,

 

 

This is really funny   I hope you know that each image build by OpenPLI build system contains such blob.
Do you realize it?

It's called drivers, they live in the kernel and have no API-wise interaction with user processes. So your point is moot.

 

 

What?

 

 

[...] have no API-wise interaction with user processes. [...]

 

 

What? I think you must think once again about what you wrote. Because it does not make sense.

 

At first they have API to interact with user processes. The main process which interact with DVB drivers is the Enigma2.

Even not, then what? In the kernel space you have access to anything you want and you can do much more bad things.

 

You try to defend your opinion:

 

There is no room in an open source image for binary blobs.

 

But reality is different. Anyway this is not related to this thread.

You use argument that you not what to fix issue because you not like binary blob but this have nothing to do with the issue.

 

I have already given you the arguments. Discussion with you looks always like this one. It looks for me that you do not have knowledge but you try to prove something.

 

Regards,

SSS

Edited by samsamsam, 20 October 2017 - 21:06.

[Erik Slagter]

This looks like an "argument" with gutemine or spacerat. I think we all know how they tend to end.

 

So yes, lets get back on topic. Your "request" (more like: demand) is not relevant, because all included software in the image/feeds should be compiled by the build run of OE and hence is by definition compatible with the used glibc and other libraries. And yes, that is still the same statement.

[athoik]

Erik, what about that commit https://git.kernel.o...c47363b37e54450

That seems like a bug, that eventually will solve problems with old binaries.

This also fixes a regression introduced in commit 46490b572544 ...

Edited by athoik, 21 October 2017 - 10:25.

[samsamsam]

Hello @Erik Slagter

 

 

demand

 

What you call "demand"?

 

This question 

 

May I ask if OpenPLI team plan to apply patch to fix this problem?

 

is demand?

 

or maybe this sentence is "demand"

 

Anyway even if you not want to apply patch at least now you will know the root cause of the problem.

 

 

So, were you saw "demand" in my words?

 

[...]because all included software in the image/feeds should be compiled by the build run of OE[...]

 

 

 

This is your position and I respect it. But may I ask to not mislead users if you don't know root cause, when you do not have knowledge about topic?

Because in your case this is not first time when you did this.

 

Regards,

SSS

Edited by samsamsam, 21 October 2017 - 10:42.

[Erik Slagter]

That seems like a bug, that eventually will solve problems with old binaries.

The "old" binaries is the whole crux. Images shouldn't have these anyway.