(In reply to comment #2)
> Looking at current trunk, it looks like something was done about the hardcoded
> list of gcc versions:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=143874
> 
> However, nothing has been done about the hardcoded list of distros and distro
> release files.  There is still
> 
> enum LinuxDistro {
>   ArchLinux,
>   DebianLenny,
>   DebianSqueeze,
>   DebianWheezy,
>   Exherbo,
>   RHEL4,
>   RHEL5,
>   RHEL6,
>   Fedora13,
>   Fedora14,
>   Fedora15,
>   FedoraRawhide,
>   OpenSuse11_3,
>   OpenSuse11_4,
>   OpenSuse12_1,
>   UbuntuHardy,
>   UbuntuIntrepid,
>   UbuntuJaunty,
>   UbuntuKarmic,
>   UbuntuLucid,
>   UbuntuMaverick,
>   UbuntuNatty,
>   UbuntuOneiric,
>   UnknownDistro
> };
> 
> along with code to parse /etc/lsb-release, /etc/redhat-release,
> /etc/debian_version, /etc/SuSE-release, /etc/exherbo-release, and
> /etc/arch-release to detect which of these distros is running.

Much of this code is dead. We don't use the Linux distro detection for
much now other than a few fairly random bits, and I had thought all of
those only cared about distinguishing between suse, ubuntu, debian, and
everything-else.

I'm going to continue cleaning this up as time permits, but what would
help me is if you listed specific actions with Clang which break because
of this. Unless we have something specific that breaks because of this,
I don't think keeping a PR open about the design cruft is all that
useful...

> Maybe a stopgap solution would be to treat unknown Ubuntu releases as
> UbuntuOneiric, unknown Fedora releases as FedoraRawhide, etc. instead of
> categorizing all distros from the future as UnknownDistro.  But I think the
> entire idea of looking at /etc/*-release files to guess the right linker flags
> is a violation of abstraction.

No one is really arguing that it is a good abstraction, but we need to
know the concrete things it breaks. It does actually fix things. My
personal goal is that for large, common Linux distributions no patch or
configuration step is necessary to build a Clang which can compile and
link binaries on that system. Doing this is not easy given the
peculiarities of several distributions' packaging practices (I'm looking
at you Debian/Ubuntu and your multiarch madness). That said, we should
key behavior on the actual detected toolchain of the system, not on the
/etc/...-release files.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/792146

Title:
  clang can’t link any programs: cannot find crt1.o, crti.o, crtn.o

To manage notifications about this bug go to:
https://bugs.launchpad.net/llvm/+bug/792146/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to