2020-08-24 14:48:27 +00:00
|
|
|
#!/bin/sh
|
2020-03-11 16:04:10 +00:00
|
|
|
|
|
|
|
|
if [ "$#" -eq 0 ]; then
|
|
|
|
|
programname=`basename "$0"`
|
|
|
|
|
echo "ERROR: No program supplied"
|
|
|
|
|
echo
|
|
|
|
|
echo "Usage: $programname <program>"
|
|
|
|
|
exit 1
|
|
|
|
|
fi
|
|
|
|
|
|
meson: unwrap ld_libdir_mangohud handling, remove ld_libdir_abs
Currently we have ld_libdir_abs which defaults to false. In that case,
both the mangohud shell wrapper, as well as the json files, reference
the DSOs directly without any path component.
This means that at run-time the dynamic linker, vulkan loader as well as
pressure-vessel will need to jump through hoops and figure out the
bitness of the DSO, whether one wants the 32 or 64bit one and even then
there will be confusing messages like:
fatal: /usr/lib/libMangoHud.so: wrong ELF class: ELFCLASS32
When set to true, as seen in the in-tree build.sh we'll append empty
path to LD_LIBRARY_PATH (bad), the full path with the $LIB token will be
used with LD_PRELOAD (good) and json files (bad).
Since we are generating separate json files, we can use the actual path
(while $LIB currently works, it's not really strict json nor documented
as supported). We can also drop the dubious LD_LIBRARY_PATH manipulation
This basically reinstates the prepend_libdir_vk=true option that was
dropped earlier.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2023-03-04 23:47:53 +00:00
|
|
|
MANGOHUD_LIB_NAME="@ld_libdir_mangohud@libMangoHud.so"
|
2020-03-11 16:04:10 +00:00
|
|
|
|
2023-03-12 14:11:38 +00:00
|
|
|
if [ "$1" = "--dlsym" ]; then
|
|
|
|
|
MANGOHUD_DLSYM=1
|
meson: unwrap ld_libdir_mangohud handling, remove ld_libdir_abs
Currently we have ld_libdir_abs which defaults to false. In that case,
both the mangohud shell wrapper, as well as the json files, reference
the DSOs directly without any path component.
This means that at run-time the dynamic linker, vulkan loader as well as
pressure-vessel will need to jump through hoops and figure out the
bitness of the DSO, whether one wants the 32 or 64bit one and even then
there will be confusing messages like:
fatal: /usr/lib/libMangoHud.so: wrong ELF class: ELFCLASS32
When set to true, as seen in the in-tree build.sh we'll append empty
path to LD_LIBRARY_PATH (bad), the full path with the $LIB token will be
used with LD_PRELOAD (good) and json files (bad).
Since we are generating separate json files, we can use the actual path
(while $LIB currently works, it's not really strict json nor documented
as supported). We can also drop the dubious LD_LIBRARY_PATH manipulation
This basically reinstates the prepend_libdir_vk=true option that was
dropped earlier.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2023-03-04 23:47:53 +00:00
|
|
|
MANGOHUD_LIB_NAME="@ld_libdir_mangohud@libMangoHud_dlsym.so:${MANGOHUD_LIB_NAME}"
|
2023-03-12 14:11:38 +00:00
|
|
|
shift
|
2020-06-03 20:00:48 +00:00
|
|
|
fi
|
2020-07-06 16:59:17 +00:00
|
|
|
|
2021-02-03 01:33:03 +00:00
|
|
|
# Preload using the plain filenames of the libs, the dynamic linker will
|
meson: unwrap ld_libdir_mangohud handling, remove ld_libdir_abs
Currently we have ld_libdir_abs which defaults to false. In that case,
both the mangohud shell wrapper, as well as the json files, reference
the DSOs directly without any path component.
This means that at run-time the dynamic linker, vulkan loader as well as
pressure-vessel will need to jump through hoops and figure out the
bitness of the DSO, whether one wants the 32 or 64bit one and even then
there will be confusing messages like:
fatal: /usr/lib/libMangoHud.so: wrong ELF class: ELFCLASS32
When set to true, as seen in the in-tree build.sh we'll append empty
path to LD_LIBRARY_PATH (bad), the full path with the $LIB token will be
used with LD_PRELOAD (good) and json files (bad).
Since we are generating separate json files, we can use the actual path
(while $LIB currently works, it's not really strict json nor documented
as supported). We can also drop the dubious LD_LIBRARY_PATH manipulation
This basically reinstates the prepend_libdir_vk=true option that was
dropped earlier.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2023-03-04 23:47:53 +00:00
|
|
|
# figure out whether the 32 or 64 bit version should be used
|
2023-03-12 14:11:38 +00:00
|
|
|
LD_PRELOAD="${LD_PRELOAD:+$LD_PRELOAD:}${MANGOHUD_LIB_NAME}"
|
2020-07-06 16:59:17 +00:00
|
|
|
|
meson: unwrap ld_libdir_mangohud handling, remove ld_libdir_abs
Currently we have ld_libdir_abs which defaults to false. In that case,
both the mangohud shell wrapper, as well as the json files, reference
the DSOs directly without any path component.
This means that at run-time the dynamic linker, vulkan loader as well as
pressure-vessel will need to jump through hoops and figure out the
bitness of the DSO, whether one wants the 32 or 64bit one and even then
there will be confusing messages like:
fatal: /usr/lib/libMangoHud.so: wrong ELF class: ELFCLASS32
When set to true, as seen in the in-tree build.sh we'll append empty
path to LD_LIBRARY_PATH (bad), the full path with the $LIB token will be
used with LD_PRELOAD (good) and json files (bad).
Since we are generating separate json files, we can use the actual path
(while $LIB currently works, it's not really strict json nor documented
as supported). We can also drop the dubious LD_LIBRARY_PATH manipulation
This basically reinstates the prepend_libdir_vk=true option that was
dropped earlier.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
2023-03-04 23:47:53 +00:00
|
|
|
exec env MANGOHUD=1 LD_PRELOAD="${LD_PRELOAD}" "$@"
|
