gccrs cannot print the expected filenames

[CohenArthur]

rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro

produces the following output

___
lib___.rlib
lib___.so
lib___.so
lib___.a
lib___.so

Right now, gccrs does not print the expected file names nor does it have the required options.

gccrs also does not understand the concept of rlib or proc-macro

[philberty]

I wonder is there something with binutils/gcc that gives us the expected suffix. What comes to mind is https://cmake.org/cmake/help/v3.0/variable/CMAKE_STATIC_LIBRARY_SUFFIX.html maybe a variable like this exists?

@tschwinge @dkm @rguenth @davidmalcolm any suggestions?

[davidmalcolm]

@philberty I confess that I merely hardcoded the extension names in libgccjit (see e.g. jit-tempdir.c's gcc::jit::tempdir::create, e.g. m_path_so_file), so if you find the answer to this, I should update libgccjit accordingly.

[rguenth]

Indeed I don't think it exists. There's HOST_EXECUTABLE_SUFFIX, so that's precedent, and collect2 uses SHLIB_SUFFIX
(see doc/tm.texi - that's a target macro and thus applies to the target). If you need more (like a HOST_SHLIB_SUFFIX)
feel free to add it (see doc/hostconfig.texi).

[bjorn3]

Cargo expects the host triple in the verbose version output (-vV) of rustc. In addition it expects to get the default file prefixes and suffixes for all crate types for the specified target. The host triple could be compiled into the cargo-gccrs executable. The default file prefixes and suffixes can't be compiled into the cargo-gccrs executable, but have to be queried at runtime as cargo will get it for both the host and the user specified target. (cross-compilation requires building build scripts and proc macros for the host) For cross-compilation cargo-gccrs will have to switch between different gcc executables I guess. HOST_EXECUTABLE_SUFFIX and SHLIB_SUFFIX are C/C++ macros, so cargo-gccrs can't read them. It needs a way to take an arbitrary gcc executable and query this information I think. I think this gcc flag would also be useful for other (C/C++) build systems.

[rguenth]

Adding some additional -print-xyz to the driver would be possible though all the info isn't in any way GCC specific but to the
host/target combo, so any such configuration would be static in GCC (in the respective target and host configs) and thus
the static configuration could be replicated in the appropriate rust binaries as well.

Usually -print-xyz print things that are dependent on configuration or the install location, not something that is fixed
for a target or host. The CPP macros are this config bits and they are then compiled into the GCC executable.

Rust must already have a list of valid host/target, how does it determine the suffixes you are looking for?

[bjorn3]

and thus the static configuration could be replicated in the appropriate rust binaries as well.

That means that the configuration has to be duplicated many times and requires changes to cargo-gccrs every time a new target is added.

Rust must already have a list of valid host/target, how does it determine the suffixes you are looking for?

Cargo asks rustc as it doesn't have any special knowledge about targets (except for a couple of special cases for things that only exist on macOS, Windows or Emscripten [0]). The target specifications baked into rustc contain this information alongside stuff like data layouts, linker configuration and supported target features. Adding a new target requires changes to rustc anyway, so the prefixes and suffixes are easily added. Adding a new target does not require any changes to Cargo. In addition rustc supports target json specifications, which contain the same info as the builtin target specifications, but stored in an external file. This format is unstable and as such external tools like Cargo can't use them for getting the target info they need.