| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
We consider it acceptable, but let's still document it in case people
notice it and are not sure why it's there.
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.
Cc: Timothy Arceri <[email protected]>
Signed-off-by: Nicholas Kazlauskas <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For some reason wine will sometimes give us a windows style path
for an application. For example when running the 64bit version
of Rage wine gives a Unix style path, but when running the 32bit
version is gives a windows style path.
If we detect no '/' in the path at all it should be safe to
assume we have a wine application and instead look for a '\'.
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
On windows process.h is a system provided header, and it's required in
include/c11/threads_win32.h. This header interferes with searching for
that header, and results in windows build warnings with scons, but
errors in meson which doesn't allow implicit function declarations. Just
rename process to u_process, which follows the style of utils anyway.
Fixes: 2e1e6511f76370870b5cde10caa9ca3b6d0dc65f
("util: extract get_process_name from xmlconfig.c")
Signed-off-by: Dylan Baker <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
