Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#6427 closed bug (fixed)

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

Reported by: pulkomandy Owned by: phoudoin
Priority: normal Milestone: R1
Component: System/runtime_loader Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description (last modified by 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.

Attachments (2)

strace_log (200.0 KB) - added by pulkomandy 9 years ago.
strace log when running from main app directory
add-ons-relative-path.patch (1.2 KB) - added by phoudoin 8 years ago.
Search relative-path add-on image in search paths too.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 9 years ago by pulkomandy

Component: - GeneralSystem/runtime_loader
Description: modified (diff)
Summary: A-player :window does not openRuntime loader doesn't look for add ons in $(PROGDIR)/add-ons/

comment:2 Changed 9 years ago by 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

comment:3 Changed 9 years ago by bonefish

strace, please.

Changed 9 years ago by pulkomandy

Attachment: strace_log added

strace log when running from main app directory

comment:4 Changed 9 years ago by 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 :)

comment:5 in reply to:  4 Changed 9 years ago by 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...

comment:6 Changed 8 years ago by phoudoin

Has a Patch: set

comment:7 Changed 8 years ago by bonefish

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

comment:8 in reply to:  7 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by 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."

Changed 8 years ago by phoudoin

Attachment: add-ons-relative-path.patch added

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

comment:10 Changed 8 years ago by phoudoin

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

comment:11 Changed 8 years ago by 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?

comment:12 Changed 8 years ago by phoudoin

Owner: changed from pulkomandy to phoudoin
Status: newassigned

comment:13 Changed 8 years ago by phoudoin

Resolution: fixed
Status: assignedclosed

Fixed in hrev39661.

comment:14 in reply to:  11 Changed 8 years ago by 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. :-)

Note: See TracTickets for help on using tickets.