BeIDE fails to load

[haiqu]

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).

[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.

[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.

[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.

[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?

[modeenf]

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

[pulkomandy]

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

[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.

[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?

[pulkomandy]

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

[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.

[waddlesplash]

Fixed in hrev50445.