Opened 4 years ago

Closed 3 years ago

#12100 closed bug (fixed)

BeIDE fails to load

Reported by: haiqu Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Applications Version: R1/Development
Keywords: Trash Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by pulkomandy)

Could not open "BeIDE" (Missing symbol: FSGetTrashDir__FP10BDirectoryl).

I believe this has something to do with the changes to the Trash Bin made for the purpose of "making it multi-user ready" (although it beggars belief that this code would be included in a pre-Beta - or in fact any version below R2 - since BeOS itself was always single-user).

Change History (12)

comment:2 Changed 4 years ago by pulkomandy

Description: modified (diff)

comment:3 Changed 4 years ago by pulkomandy

This doesn't look related to any changes to the trash directory itself. It's just that we don't implement the function FSGetTrashDir. As you can see, that function name doesn't start with a B like anything else in the BeAPI. This means it is not part of the public API of BeOS and apps were not supposed to use it. But BeIDE did anyway, so we could try to implement it to improve support.

comment:4 Changed 4 years ago by modeenf

FSGetTrashDir exists in http://cgit.haiku-os.org/haiku/tree/src/kits/tracker/FSUtils.cpp

Have there bean changes to som libs and what files are included? BeIDE use to work.

comment:5 Changed 4 years ago by waddlesplash

Apparently so. A nm of libtracker.so from BeOS R5 shows that the signature of the FSGetTrashDir function was FSGetTrashDir__8BPrivateP10BDirectoryl, whereas in Haiku it has an additional parameter of type dev_t.

comment:6 Changed 4 years ago by modeenf

If I look at this ticket https://dev.haiku-os.org/ticket/1906

in hrev43550 BeIDE still worked. But I can't see any chnages in FSGetTrashDir. Perhaps it was another but hidde tracker thing?

comment:7 Changed 4 years ago by modeenf

Perhaps we need a !missing_symbols.cpp file like the one in the media kit. :)

comment:8 Changed 4 years ago by pulkomandy

Our implementation in Tracker is in the BPrivate namespace, so it doesn't match the symbol BeIDE is looking for.

comment:9 in reply to:  8 ; Changed 4 years ago by korli

Replying to waddlesplash:

Apparently so. A nm of libtracker.so from BeOS R5 shows that the signature of the FSGetTrashDir function was FSGetTrashDir__8BPrivateP10BDirectoryl, whereas in Haiku it has an additional parameter of type dev_t.

In the signature the "l" meant long, which is the actual type of dev_t. So I'd say they should match and the symbol isn't missing.

Replying to pulkomandy:

Our implementation in Tracker is in the BPrivate namespace, so it doesn't match the symbol BeIDE is looking for.

From waddlesplash's R5 dump, I'd say the R5 implementation is in the BPrivate namespace too.

comment:10 in reply to:  9 ; Changed 4 years ago by modeenf

Replying to korli:

Replying to pulkomandy:

Our implementation in Tracker is in the BPrivate namespace, so it doesn't match the symbol BeIDE is looking for.

From waddlesplash's R5 dump, I'd say the R5 implementation is in the BPrivate namespace too.

But are our implemented in BPrivate? Has it moved sins hrev43550?

Last edited 4 years ago by modeenf (previous) (diff)

comment:11 Changed 4 years ago by pulkomandy

I don't know, but the symbol in the original bug report doesn't include the BPrivate namespace.

comment:12 in reply to:  10 Changed 4 years ago by korli

Replying to modeenf:

From waddlesplash's R5 dump, I'd say the R5 implementation is in the BPrivate namespace too.

But are our implemented in BPrivate? Has it moved sins hrev43550?

Since 2005 our is in BPrivate, first commit in log.

comment:13 Changed 3 years ago by waddlesplash

Resolution: fixed
Status: newclosed

Fixed in hrev50445.

Note: See TracTickets for help on using tickets.