respectively other gcc version on a Haiku compiled with gcc 2 or gcc 4.
The libraries for such an executable are first searched in "gcc4"
respectively "gcc2" subdirectories of the standard search path
directories. If not found there, we try again with the standard paths.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25532 a95241bf-73f2-0310-859d-f6bbb57e9c96
executable permissions of the file by hand. We use _kern_access()
instead, which also handles the root case correctly.
* The user and group arguments of test_executable() aren't needed any
longer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24483 a95241bf-73f2-0310-859d-f6bbb57e9c96
The runtime loader did not correctly resolve %A correctly with the
actual normalized program path. IOW it would not work correctly with
symlinks to applications that had their own lib directory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23986 a95241bf-73f2-0310-859d-f6bbb57e9c96
for _kern_load_image().
* Added KMessage to the runtime_loader (a bit hacky, though) - it will use
it to deliver the above mentioned functionality.
* load_dependencies() did return the wrong status code in case a library
was missing; now it returns B_MISSING_LIBRARY.
* load_dependencies() will now try to load all dependencies when a report
message is requested; therefore, all missing libraries are listed.
* Renamed uspace_program_args to user_space_program_args.
* The kernel filled in various members of the user_space_program_args structure
unsafely, ie. was not using user_memcpy().
* Renamed some local variables in team.c to better fit our style guide (ie.
uargs to userArgs).
* Changed Tracker to use the new _kern_load_image() variant on Haiku to retrieve
and report all missing libraries. This fixes bug #1324.
* Adapted kernel_cpp.cpp to the runtime loader as well; the latter will now
compile with _LOADER_MODE defined.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21715 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The previous symbol resolution code was incorrect. It would search all
loaded images in the order they had been loaded. Thus an add-on would
possibly see a symbol of an earlier loaded add-on. Now we search
recursively starting with the respective root image (executable or
add-on).
* Added BeOS style symbol resolution and made it the default. A symbol
undefined in an image is only searched in its direct dependencies.
Fixes bug #889 (BeOS apps crashing under Haiku when opening a file
panel).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21290 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This sane heap revealed a bunch of bugs (like sLoadedImageCount not being
maintained that was used for various allocations).
* If the allocation of the image fails, opening the app will now just fail
instead of crashing of overwriting random data (IOW VLC will now load
okay, but cannot load some of its add-ons anymore).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19045 a95241bf-73f2-0310-859d-f6bbb57e9c96
to determine linkage of libnet.so vs. libsocket.so/libbind.so in the libnetwork.so.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19008 a95241bf-73f2-0310-859d-f6bbb57e9c96
issues:
* Our glue code was broken after all - it allowed Haiku apps to start under
BeOS (and vice versa), but the initialization/termination functions were
called with an invalid image ID - on *both* sides! As it turns out, the
Be glue code did *something* with %ebx, but certainly didn't put the image
ID in there, but just passed it on the stack, as we did before (just in
the wrong order...). Therefore, the arch_call_init_term stuff is not
necessary.
* When unloading add-ons, their termination functions were never called, as
the image (for get_image_symbol()) was already made inaccessible, and
therefore the symbol couldn't be found.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17928 a95241bf-73f2-0310-859d-f6bbb57e9c96
This makes the runtime_loader able to adopt path changes properly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17380 a95241bf-73f2-0310-859d-f6bbb57e9c96
