From 3986ce0335353ad69446fbc9f6dce131b409a356 Mon Sep 17 00:00:00 2001 From: Philippe Houdoin Date: Sat, 27 Nov 2010 09:57:16 +0000 Subject: [PATCH] Relative add-ons pathnames are now searched in ADDON_PATH too if they're not found from current working directory. Fix #6427. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39661 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- src/system/runtime_loader/runtime_loader.cpp | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/src/system/runtime_loader/runtime_loader.cpp b/src/system/runtime_loader/runtime_loader.cpp index 00d95964ea..8c57f298ea 100644 --- a/src/system/runtime_loader/runtime_loader.cpp +++ b/src/system/runtime_loader/runtime_loader.cpp @@ -224,14 +224,23 @@ open_executable(char *name, image_type type, const char *rpath, if (strchr(name, '/')) { // the name already contains a path, we don't have to search for it fd = _kern_open(-1, name, O_RDONLY, 0); - if (fd >= 0 || type != B_LIBRARY_IMAGE) + if (fd >= 0 || type == B_APP_IMAGE) + return fd; + + // can't search harder an absolute path add-on name! + if (type == B_ADD_ON_IMAGE && name[0] == '/') return fd; // Even though ELF specs don't say this, we give shared libraries - // another chance and look them up in the usual search paths - at + // and relative path based add-ons another chance and look + // them up in the usual search paths - at // least that seems to be what BeOS does, and since it doesn't hurt... - paths = strrchr(name, '/') + 1; - memmove(name, paths, strlen(paths) + 1); + if (type == B_LIBRARY_IMAGE) { + // For library (but not add-on), strip any path from name + // Relative path of add-on is kept + paths = strrchr(name, '/') + 1; + memmove(name, paths, strlen(paths) + 1); + } } // let's evaluate the system path variables to find the container