[cfe-users] Right way to fully configure clang default search path and default compile/linker flags

[Romain GEISSLER via cfe-users]

Hi,

I have been trying to add clang to an existing GNU toolchain, which goal is to be as isolated from the base system as possible (ie install a working compiler/assembler/linker/libc in a very specific folder in /opt/MyToolchain which doesn't use any files from the base system). Also I need to customize some of the cpp/c/cxx/ldflags used by default in this toolchain.

With gcc, this is quite straight forward since gcc's configure file comes with handy flags like:
 - --with-local-prefix= which allows to override the default system header include /usr/local/include
 - --with-native-system-header-dir= to override the default system header include /include
 --enable-linker-build-id to enable build ids by default (in clang the equivalent is -DENABLE_LINKER_BUILD_ID)
 --with-linker-hash-style=gnu to force the gnu hash style when emitting the symbol table.

Gcc regularly adds new configure flags as the binutils add new features, so that you can explicitly enable/disable them from the frontend.

Also gcc comes with its "spec" file which allows to update flag used during the whole compilation flow, without recompiling gcc itself.

On the other side, when I try to configure clang, it seems much harder to have a toolchain that:
 - is isolated from the base system (my toolchain is not a cross toolchain, it doesn't use --sysroot, so using a sysroot is not an option)
 - allows me to easily customize what are the default ldflags passed to the linker.

I found out by looking at tools/clang/lib/Driver/ToolChains.cpp that the only way to achieve that is to, as a packager, maintain patches over the clang source code. Is this really the way we are meant to properly configure clang when we don't want to stick to the hardcoded defaults ? Except -DENABLE_LINKER_BUILD_ID and -DGCC_INSTALL_PREFIX there is not much that seems to be configurable. What do you advice to packagers with special needs ?

Also why are some flags tied to the distro ? When I see code like this:

  if (!IsMips && !IsAndroid) {
    if (IsRedhat(Distro) || IsOpenSUSE(Distro) ||
        (IsUbuntu(Distro) && Distro >= UbuntuMaverick))
      ExtraOpts.push_back("--hash-style=gnu");
    
    if (IsDebian(Distro) || IsOpenSUSE(Distro) || Distro == UbuntuLucid ||
        Distro == UbuntuJaunty || Distro == UbuntuKarmic)
      ExtraOpts.push_back("--hash-style=both");
  }

I wonder why do you check for distro/distro version, while what really matters are the linker capabilties. gcc achieves that either through explicit configure options, or if nothing is given, through autotools feature check tests. Why does clang chooses to hardcode ldflags based on distro/distro versions ? How are people having their own (coporate, so private) distro meant to configure clang in that case ?

Cheers,
Romain