Runtime loader doesn't look for relative add ons in $(PROGDIR)/add-ons/

[pulkomandy]

I downloaded and installed A-Player from ​http://www.polycode.dk/ Launching it results in a deskbar entry, but the window doesn't show up.

I had a look at the sourcecode, apparently A-Player is trying to load add-ons and Haiku's runtime loader doesn't look in the right folder.

A-Player does something like load_add_on("somefile") while the file is actually located in "$(PROGDIR)/add-ons/somefile". Running A-Player by doing "cd add-ons ; ../APlayer" works fine. I think the runtime loader is not looking in this particular folder.

[phoudoin]

Could you check what's your ADDON_PATH env value? If it's defined, it should have A%/add-ons in the search list, otherwise it's logic the add-on is not found there.

If it's not defined, the default value should search for A%/add-ons: ​http://dev.haiku-os.org/browser/haiku/trunk/src/system/runtime_loader/runtime_loader.cpp#L27

[bonefish]

strace, please.

[pulkomandy]

strace log when running from main app directory

[pulkomandy]

I attached an strace log. What might be happening is there are subfolders in the add-ons folder and APlayer does something like load_add_on("Clients/MainWindowSystem"). I'm not sure the runtime_loader expect part of the add-on path to be embedded in the name. But I may not have read the code properly :)

[bonefish]

Replying to pulkomandy:

I attached an strace log. What might be happening is there are subfolders in the add-ons folder and APlayer does something like load_add_on("Clients/MainWindowSystem"). I'm not sure the runtime_loader expect part of the add-on path to be embedded in the name. But I may not have read the code properly :)

The current implementation uses the same search algorithm for add-ons as the one specified for loading libraries via dlopen() (just with other search paths). When the given name contains a '/' it is directly interpreted as the path to be opened; the search paths are ignored. It seems BeOS's load_add_on() does (also?) try to append the path to the search paths. We should investigate the exact semantics...

[bonefish]

Philippe, have you analyzed the BeOS semantics or just guessed?

[phoudoin]

Replying to bonefish:

Philippe, have you analyzed the BeOS semantics or just guessed?

Just guessed, as I don't have anymore a BeOS machine. And I even fail to test my patch applied, as whatever I do, even rebuilding runtime_loader for the exact revision of my Haiku install, it fail to start any new process and don't boot (rocket icon) anymore.

[phoudoin]

For what it worth, the BeBook says this about load_add_on() pathname argument:

"pathname can be absolute or relative; if it's relative, it's reckoned off the base path specified by the ADDON_PATH environment variable."

[phoudoin]

Search relative-path add-on image in search paths too.

[phoudoin]

I've rebuild a whole hrev39660 image with just this patch applied to runtime_loader, and use this image since one day long without detecting any regression. Oh, and it does fix this issue too ;-)

Considering that both BeBook and at least one application - which loads with any issue his add-ons under BeOS - makes me think that the semantic for relative add-on pathname is indeed broken currently under Haiku, I've commit that change in hrev39661.

One thing to check is if BeOS try to open CWD's relative addon pathname too (as we do even without this patch) or does it only search in ADDON_PATH. Currently, if both %A/subdir/some-addon and %A/add-ons/subdir/some-addon exists, and the current working directory is %A, load_add_on("subdir/some-addon") will load from the first one. According to BeBook, it should not, but I suspect it does it anyway. If it does not, we need to fix that too.

Could someone with BeOS could check, after moving (not copying) for instance APlayer/add-ons/Clients/MainWindowSystem in a (temporary) APlayer/Clients folder?

[phoudoin]

Fixed in hrev39661.

[bonefish]

Replying to phoudoin:

Could someone with BeOS could check, after moving (not copying) for instance APlayer/add-ons/Clients/MainWindowSystem in a (temporary) APlayer/Clients folder?

If you extend the runtime loader test suite (src/tests/system/runtime_loader/test_suite), I'd be willing to run it on BeOS. :-)