search

VirtualGL / virtualgl

Main VirtualGL repository
https://VirtualGL.org
Other
701 stars 106 forks source link

LD_LIBRARY_PATH manipulation not needed #198

Closed JHagemeister closed 2 years ago

JHagemeister commented 2 years ago

Is there a reason for vglrun to manipulate both LD_LIBRARY_PATH as well as LD_PRELOAD?

It seems not to be necessary to modify LD_LIBRARY_PATH when the full path is used in LD_PRELOAD. That would make things more concise, I believe. :)

karlkleinpaste commented 2 years ago

On a 64-bit installation, full pathnames like /usr/lib64/libdlfaker.so in LD_PRELOAD will cause whining about "wrong ELF class" when you run 32-bit programs.

dcommander commented 2 years ago

vglrun does not manipulate LD_LIBRARY_PATH by default. It only does so under two circumstances:

  1. If -ld is passed to the script, then the specified directory is prepended to LD_LIBRARY_PATH. This is an undocumented convenience feature that is useful for testing.
  2. If the fakers are installed in a non-system library directory, then VirtualGL installs an optional script (.vglrun.vars64 or .vglrun.vars32) into the same directory as vglrun. That script, if it exists, is invoked by vglrun, and it prepends the faker directory to LD_LIBRARY_PATH.

The full path is not used in LD_PRELOAD for precisely the reason that @karlkleinpaste cites. VirtualGL is designed so that both 64-bit and 32-bit applications can be launched using the same script (vglrun.) Using the full path in LD_PRELOAD would necessitate having a separate vglrun script for 64-bit and 32-bit applications. That being said, eventually 32-bit applications will go away, and that would make it possible to do what you propose.

JHagemeister commented 2 years ago

Ah, I see. Thank you very much for your replies!