LLVM

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

Bug #792146 reported by Anders Kaseorg
44
This bug affects 8 people
Affects Status Importance Assigned to Milestone
LLVM
Confirmed
Wishlist
clang (Debian)
Fix Released
Unknown
clang (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: clang

clang in oneiric doesn’t look for crtbegin.o, libgcc.so, or libgcc_s.so in the right place, so it can’t link any programs.

$ echo 'int main() {return 0;}' > foo.c

$ clang foo.c
/usr/bin/ld.bfd.real: cannot find crtbegin.o: No such file or directory
/usr/bin/ld.bfd.real: cannot find -lgcc
/usr/bin/ld.bfd.real: cannot find -lgcc_s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

$ clang -v foo.c
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name foo.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.51.20110421 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-d3WZZO.o -x c foo.c
clang -cc1 version 2.9 based upon llvm 2.9 hosted on x86_64-pc-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/bin/../lib/clang/2.9/include
 /usr/include
End of search list.
 "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o crtbegin.o -L -L/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/../../.. /tmp/cc-d3WZZO.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o /usr/lib/../lib64/crtn.o
/usr/bin/ld.bfd.real: cannot find crtbegin.o: No such file or directory
/usr/bin/ld.bfd.real: cannot find -lgcc
/usr/bin/ld.bfd.real: cannot find -lgcc_s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

$ find /usr -name crtbegin.o -o -name libgcc.so -o -name libgcc_s.so
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/crtbegin.o
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/libgcc_s.so
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/32/crtbegin.o
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/32/libgcc_s.so
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/crtbegin.o
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5/libgcc_s.so

$ strace clang foo.c |& grep 'crtbegin\.o'
stat("/usr/lib/gcc//4.5.2/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.5.2/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.5.1/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.5.1/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.5/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.5/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.4.5/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.4.5/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.4.4/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.4.4/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.4.3/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.4.3/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.4/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.4/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.3.4/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.3.4/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.3.3/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.3.3/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.3.2/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.3.2/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.3/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.3/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.2.4/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.2.4/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.2.3/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.2.3/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.2.2/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.2.2/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.2.1/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.2.1/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib/gcc//4.2/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/gcc//4.2/crtbegin.o", 0x7fff1cfc8600) = -1 ENOENT (No such file or directory)
stat("/crtbegin.o", 0x7fff1cfc8780) = -1 ENOENT (No such file or directory)
stat("/../../../../lib64/crtbegin.o", 0x7fff1cfc8780) = -1 ENOENT (No such file or directory)
stat("/lib/../lib64/crtbegin.o", 0x7fff1cfc8780) = -1 ENOENT (No such file or directory)
stat("/usr/lib/../lib64/crtbegin.o", 0x7fff1cfc8780) = -1 ENOENT (No such file or directory)
stat("/../../../crtbegin.o", 0x7fff1cfc8780) = -1 ENOENT (No such file or directory)
wait4(28765, /usr/bin/ld.bfd.real: cannot find crtbegin.o: No such file or directory

Perhaps clang needs to be taught harder about multiarch paths?

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: clang 2.9-1
ProcVersionSignature: Ubuntu 2.6.39-3.10-generic 2.6.39
Uname: Linux 2.6.39-3-generic x86_64
NonfreeKernelModules: openafs
Architecture: amd64
Date: Thu Jun 2 20:56:07 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20101202)
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: clang
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Anders Kaseorg (andersk) wrote :
Anders Kaseorg (andersk)
tags: added: regression-release
Revision history for this message
Anders Kaseorg (andersk) wrote :

clang 2.8-0ubuntu2 from natty works fine on an otherwise current oneiric system.

Revision history for this message
Anders Kaseorg (andersk) wrote :

Fixed in clang 2.9-6.

Changed in clang (Ubuntu):
status: New → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in clang (Debian):
status: Unknown → Fix Released
Revision history for this message
David Coles (dcoles) wrote :

I'm currently seeing this issue in the Clang 2.9-8 package on x86_64 on a clean install of Ubuntu 11.10 Beta 1. Can I get confirmation if this is affecting others.

Revision history for this message
Ilmari Vacklin (wolverian) wrote :

I'm getting something similar on Oneiric 64-bit. Does it look like this bug? Output of clang -v attached below.

    ➜ tmp git:(ubuntu) ✗ cat trivial.c
    #include <stdio.h>

    int main() {
        printf("Hello World");
        return 0;
    }
    ➜ tmp git:(ubuntu) ✗ clang trivial.c -v
    clang version 2.9 (tags/RELEASE_29/final)
    Target: x86_64-pc-linux-gnu
    Thread model: posix
     "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name trivial.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.53.20110810 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 127 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-cj0i6G.o -x c trivial.c
    clang -cc1 version 2.9 based upon llvm 2.9 hosted on x86_64-pc-linux-gnu
    ignoring duplicate directory "/usr/include/x86_64-linux-gnu"
    #include "..." search starts here:
    #include <...> search starts here:
     /usr/local/include
     /usr/include/x86_64-linux-gnu
     /usr/bin/../lib/clang/2.9/include
     /usr/include
    End of search list.
     "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out crt1.o crti.o crtbegin.o -L -L/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/../../.. /tmp/cc-cj0i6G.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o crtn.o
    /usr/bin/ld: cannot find crt1.o: No such file or directory
    /usr/bin/ld: cannot find crti.o: No such file or directory
    /usr/bin/ld: cannot find crtbegin.o: No such file or directory
    /usr/bin/ld: cannot find -lgcc
    /usr/bin/ld: cannot find -lgcc_s
    clang: error: linker command failed with exit code 1 (use -v to see invocation)

Revision history for this message
Anders Kaseorg (andersk) wrote :

Yeah, this is broken again. On oneiric amd64 I get

 "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out crt1.o crti.o crtbegin.o -L -L/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/../../.. /tmp/cc-cdfXQY.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o crtn.o
/usr/bin/ld: error: cannot open crt1.o: No such file or directory
/usr/bin/ld: error: cannot open crti.o: No such file or directory
/usr/bin/ld: error: cannot open crtbegin.o: No such file or directory
/usr/bin/ld: error: cannot open crtend.o: No such file or directory
/usr/bin/ld: error: cannot open crtn.o: No such file or directory
/usr/bin/ld: error: cannot find -lgcc
/usr/bin/ld: error: cannot find -lgcc_s
/usr/bin/ld: error: cannot find -lc
/usr/bin/ld: error: cannot find -lgcc
/usr/bin/ld: error: cannot find -lgcc_s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The situation is a little better after rebuilding clang 2.9-11 from Debian, but still not fixed:

 "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out crt1.o crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../.. /tmp/cc-r7kJDE.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtend.o crtn.o
/usr/bin/ld: error: cannot open crt1.o: No such file or directory
/usr/bin/ld: error: cannot open crti.o: No such file or directory
/usr/bin/ld: error: cannot open crtn.o: No such file or directory
/usr/bin/ld: error: cannot find -lc
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Changed in clang (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Matthias Klose (doko) wrote :

fixed in 2.9-11

Changed in clang (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Anders Kaseorg (andersk) wrote :

Sorry, still fails for me on oneiric amd64 with clang 2.9-11.

$ echo 'int main() {return 0;}' > foo.c
$ clang -v foo.c
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name foo.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.53.20110810 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-cN3pW4.o -x c foo.c
clang -cc1 version 2.9 based upon llvm 2.9 hosted on x86_64-pc-linux-gnu
ignoring nonexistent directory "/usr/local/include"
ignoring duplicate directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/x86_64-linux-gnu
 /usr/bin/../lib/clang/2.9/include
 /usr/include
End of search list.
 "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out crt1.o crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../.. /tmp/cc-cN3pW4.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtend.o crtn.o
/usr/bin/ld: error: cannot open crt1.o: No such file or directory
/usr/bin/ld: error: cannot open crti.o: No such file or directory
/usr/bin/ld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Changed in clang (Ubuntu):
status: Fix Released → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in clang (Ubuntu):
status: New → Confirmed
Revision history for this message
Björn Schließmann (b-schliessmann) wrote :

Affecting me with 2.9-11 (32 bit), too:

clang version 2.9 (tags/RELEASE_29/final)
Target: i386-pc-linux-gnu
Thread model: posix
 "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test crt1.o crti.o /usr/lib/gcc/i686-linux-gnu/4.6.1/crtbegin.o -L/usr/lib/i386-linux-gnu -L/usr/lib/gcc/i686-linux-gnu/4.6.1 -L/usr/lib/gcc/i686-linux-gnu/4.6.1/../../.. -L/usr/lib/i386-linux-gnu/ test.o -Bsymbolic-functions -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -lasound -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-linux-gnu/4.6.1/crtend.o crtn.o
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [test] Error 1

Revision history for this message
Björn Schließmann (b-schliessmann) wrote :

I circumvented the error placing symlinks of crt1.o and crti.o in the working directory; then it complained about crtn.o. When I symlinked this one too, it worked.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package clang - 2.9-11ubuntu1

---------------
clang (2.9-11ubuntu1) oneiric; urgency=low

  * Add support for Ubuntu natty and oneiric (LP: #792146, #852870).
 -- Colin Watson <email address hidden> Sun, 18 Sep 2011 22:43:25 +0100

Changed in clang (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Anders Kaseorg (andersk) wrote :

Still fails with clang 2.9-11ubuntu1.

$ clang -v foo.c
…

 "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out crt1.o crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../.. /tmp/cc-Ro8pXj.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtend.o crtn.o
/usr/bin/ld: error: cannot open crt1.o: No such file or directory
/usr/bin/ld: error: cannot open crti.o: No such file or directory
/usr/bin/ld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Changed in clang (Ubuntu):
status: Fix Released → New
summary: - clang can’t link any programs: cannot find crtbegin.o, -lgcc, -lgcc_s
+ clang can’t link any programs: cannot find crt1.o, crti.o, crtn.o
Evan Broder (broder)
Changed in clang (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in clang (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Leo Iannacone (l3on) wrote :

Dear developers,

I would like to discuss with you some solution to take away hardcoded codenames in ToolChains.cpp.

For example, Debian and (in particular) Ubuntu need to patch and add by-their-hands Distro names in the code every release.

Ubuntu needs upgrade patch every six months.

My question is: does exist another way in which ToolChains.cpp should be "written" or "conceived" in order to simplify this process?

In this discussion Anders Kaseorg explains the problem very well:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-June/015545.html

Best regards,

Leo.

Revision history for this message
In , Chandler Carruth (chandlerc) wrote :

The ToolChains.cpp system has been completely rewritten since the thread you cite was written. The specific complaints mentioned there have been fixed (if not in the exact way proposed).

What is actually causing problems? Do you actually need to patch Clang today?

For reference, I have tested the current 3.0 release candidate on both Debian and Ubuntu without *any* patches applied and I believe it found the correct GCC installation and headers.

Leo Iannacone (l3on)
tags: added: precise
Bug Watch Updater (bug-watch-updater)
Changed in llvm:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Revision history for this message
In , Anders Kaseorg (andersk) wrote :

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. This code automatically breaks every six months when Ubuntu and Fedora both release another version. (For example, Ubuntu has a new Precise Pangolin development release, and Fedora released Fedora 16 as stable. Even Debian squeeze released, so its /etc/debian_version looks like ‘6.0.3’ instead of ‘squeeze/sid’ now and DetectLinuxDistro() misdetects it.)

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.

Revision history for this message
In , Chandler Carruth (chandlerc) wrote :

(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.

Revision history for this message
In , Sylvestre Ledru (sylvestre) wrote :

As the Debian maintainer of clang, even with the version 3.0, I had to patch it to make sure clang finds all headers...
However, my patches are Debian/Ubuntu oriented/hardcoded and cannot be ported easily into the main distribution.

Changed in clang (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Anders Kaseorg (andersk) wrote :

Still doesn’t work in precise.

$ echo 'int main() {return 0;}' > foo.c
$ clang foo.c
/usr/bin/ld: error: cannot open crt1.o: No such file or directory
/usr/bin/ld: error: cannot open crti.o: No such file or directory
/usr/bin/ld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

But it works if I replace /etc/lsb-release to make my precise system look like oneiric. If nothing else, the patch needs to be rewritten to treat unknown/future Ubuntu releases the same way as oneiric so that this doesn’t automatically break again every six months.

Changed in clang (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Leo Iannacone (l3on) wrote :

I fixed problem updating patch in https://bugs.launchpad.net/ubuntu/+source/clang/+bug/896695

Revision history for this message
Anders Kaseorg (andersk) wrote :

Does your updated patch treat unknown/future Ubuntu releases the same way, so that this doesn’t automatically break again every six months?

Revision history for this message
Leo Iannacone (l3on) wrote :

I think this version fix this bug https://launchpad.net/ubuntu/+source/clang/3.0-3ubuntu1

Changed in clang (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.