Opened 9 years ago

Closed 9 years ago

#6669 closed bug (invalid)

binary clock application creates a zombie replicant on desktop

Reported by: the ringmaster Owned by: anevilyak
Priority: normal Milestone: R1
Component: Applications Version: R1/alpha2
Keywords: zombie, replicant, desktop_server Cc: bonefish
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

As seen in the screenshot. When I try to make a replicant of the binary clock application, it only creates a grey square where the replicant should be.

Attachments (1)

zombie_replicant.png (162.6 KB) - added by the ringmaster 9 years ago.

Download all attachments as: .zip

Change History (7)

Changed 9 years ago by the ringmaster

Attachment: zombie_replicant.png added

comment:1 Changed 9 years ago by anevilyak

Owner: changed from nobody to anevilyak
Status: newassigned

Where did that binary clock app come from? Also, what kind of build are you on? Replicants have a limitation that they have to match the compiler of the app you're embedding them in, ergo you cannot take a replicant from a gcc2 app and embed them into the desktop of a gcc4 tracker and vice versa.

comment:2 Changed 9 years ago by anevilyak

Cc: bonefish added

Assuming it's this app: http://haikuware.com/directory/view-details/geek-toys/other/binaryclock , that one is indeed gcc2-built.

Assuming you're on a gcc4-based hybrid, this is unfortunately not a problem that can be worked around easily that I know of, unless Ingo has some insight that I'm missing.

comment:3 Changed 9 years ago by the ringmaster

Yeah that's the one. I am using a hybrid gcc4 build. Too bad that I still can't use the gcc version even though I do have gcc2 support on this build.

comment:4 Changed 9 years ago by anevilyak

Unfortunately that's difficult to avoid in this instance, because the replicant gets loaded directly into the hosting team's address space. As such it has to be able to interface with the libbe, etc. that have already been loaded for said app, as a consequence of which hybrid support can't really help. There may possibly be some runtime loader trick that can work around this problem but I unfortunately would not know how to implement that.

comment:5 in reply to:  4 ; Changed 9 years ago by bonefish

Replying to anevilyak:

There may possibly be some runtime loader trick that can work around this problem but I unfortunately would not know how to implement that.

I can't think of any solution other than a complete ABI mapper either. And I'm pretty sure that this is not going to happen. Too much work for too little gain, I'm afraid.

Unless there is some aspect of this ticket that shall be addressed (like to prevent loading of incompatible add-ons) I'd suggest to close it as invalid ("won't fix", really).

comment:6 in reply to:  5 Changed 9 years ago by anevilyak

Resolution: invalid
Status: assignedclosed

Replying to bonefish:

Unless there is some aspect of this ticket that shall be addressed (like to prevent loading of incompatible add-ons) I'd suggest to close it as invalid ("won't fix", really).

The only way to do that would be to eliminate the zombie replicant mechanism entirely, since it can't detect the distinction between being unable to find a symbol due to ABI mismatch vs due to a required lib for the replicant not being in an accessible location for the host (i.e. SoundPlay replicant without liblayout.so in ~/config/lib). Since I'd rather not go that far without some consensus, closing as invalid. Thanks for the input!

Note: See TracTickets for help on using tickets.