Default linker can be set with DEFAULT_LINKER in options.
Packages can influence linker selection both by positive and/or
negative PKG_BUILD_FLAGS, eg +bfd or -gold.
Positive build flags take priority over the default linker so eg
DEFAULT_LINKER="gold" and PKG_BUILD_FLAGS="+bfd" will select bfd.
Negative flags mean a specific linker should not be used, eg -gold
prevents using gold.
If the default linker is disabled via a build flag then any other
available linker will be used.
Optional linkers like gold have to be enabled with eg GOLD_SUPPORT="yes"
in options. If an optional linker is not enabled it won't be a candidate
for linker selection. So eg "+mold" will have no effect if MOLD_SUPPORT
isn't set to "yes".
Signed-off-by: Matthias Reichl <hias@horus.com>
Timing detail reporting can be enabled by setting
TRACE_BUILD_TIMING=1
This enables timestamping collecting at various build stages so we
can easily analyze how long eg configure, make/build, install etc
steps take.
Signed-off-by: Matthias Reichl <hias@horus.com>
march and mcpu were added in ~2011. I don't know why. I have seen CFLAGS added
en masse to LDFLAGS when using LTO, but that does not explain these inclusions.
Remove to cleanup LDFLAGS.
Signed-off-by: Ian Leonard <antonlacon@gmail.com>
was:
- OpenGL (GLX) support (provider): no (no)
- OpenGL ES support (provider): yes (mesa)
- Vulkan API support (provider): no (no)
is:
- OpenGL (GLX) support (provider): no
- OpenGL ES support (provider): yes (mesa)
- Vulkan API support (provider): no
uname options -p and -i are non portable and return "unknown" on
Linux with GNU coreutils as there's no OS support for it.
Note: some distributions like Fedora or Ubunto patch coreutils so
that uname -p (more or less) returns the machine name (uname -m output).
But that should not be used and fails on distributions like Debian
that don't add that patch.
Signed-off-by: Matthias Reichl <hias@horus.com>
If we build with `-Os` some vars are missing in backtraces and will be listed as `<optimized out>`
- https://github.com/PCSX2/pcsx2/issues/5226#issuecomment-1036987320
```
Optimize debugging experience. -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0.
Like -O0, -Og completely disables a number of optimization passes so that individual options controlling them have no effect. Otherwise -Og enables all -O1 optimization flags except for those that may interfere with debugging:
```
- https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
