Add /usr dir to isolate self-built binaries and libs? #166
Comments
|
I agree. But how do we get GCC to search in these places? I'm sure it's possible. I just don't know how. |
|
A convention like /opt or /usr/local is necessary when the file system
root (e.g. /) is shared between system and operator. However, w64dk isn't
the file system root and does not need to share its subtree. Unlike MSYS2
or Cygwin, nor does it host a virtual file system rooted within itself. So
the solution is simply to not "install" files within w64dk unless you're
ready to repeat that process after updates.
Instead, create one or more "system roots" outside of w64dk, then set a
few environment variables to virtually merge it into the w64dk sysroot.
For example, if you use your home directory, then in your .profile:
PATH="$HOME/bin;$PATH"
export CPATH="$HOME/include"
export LIBRARY_PATH="$HOME/lib"
export PKG_CONFIG_PATH="$HOME/lib/pkgconfig;$HOME/share/pkgconfig"
For multiple sysroots, each variable supports ";" as a path separator. Now
you can update w64dk without disturbing self-built dependencies and tools.
When you ./configure or whatever, it's --prefix=$HOME to match the above.
The Windows environment block size is historically significantly limited,
and the documentation on those limits is wrong [1]. So I'm wary of loading
it more than necessary by default. Paths must be absolute, and the w64dk
installation path can easily be quite long (e.g. deep inside someone's
profile directory). Adding itself to PATH once is necessary, but each new
search path is another full copy of a potentially long installation path
for significantly less benefit for most users.
There's probably a way to teach Binutils and GCC about more search paths
so that they don't need to go in the environment, but I'd prefer to not
encourage installing libraries inside w64dk as a general solution.
Side note: There's been a sticky issue that "$ARCH/bin" isn't added to
PATH, yet that's where DLLs and EXEs are installed. That means dynamically
linked libraries and tools installed within w64dk don't work out of the
box. Since w64dk isn't "multiarch" I should probably eliminate the $ARCH
component in the sysroot and lift everything up a level. I haven't figured
out how to do this yet, but I also haven't put much effort into it.
[1]: https://nullprogram.com/blog/2023/08/23/
|
|
This is a snippet from my .profile file for SDL2, SFML and RayLib ` unset C_INCLUDE_PATH export CPATH="$CPATH;$SDK/SDL2/$ARCH/include" export SFML_VERSION="2.6.1" export RAYLIB_VERSION="5.0" PATH="$PATH;$LD_LIBRARY_PATH" |
|
Thanks for the example, @rapte! The "gcc -dumpmachine" trick is great and
I use it myself.
LD_LIBRARY_PATH should have no effect in w64devkit. The Windows dynamic
linker certainly doesn't use it, Bintuils only uses it for ELF targets,
and it generally doesn't fit into the Win32 linking model. Ultimately you
tack it onto the end of PATH, so it seems perhaps you're just using the
name as a convention. (Even then, it still doesn't need to be exported.)
|
|
Thank you @skeeto for this super portable toolchain. It is true that I use the LD_LIBRARY_PATH just as a naming convention. But the reason |
Currrently if you self-build a lot of packages - it can be tough to look inside the bin/lib/share etc folder and realize which file is yours and/or remove them to restore w64devkit to stock - especially since it's not easy to undo a
make install. It might be a good idea to follow FHS and put all usermade packages in /usr or /usr/local?The text was updated successfully, but these errors were encountered: