Yep, me too. Fails for every C/C++ program I try. lld 6 did work, but all lld 7 versions have failed.

Some additional info:

The clang/clang++/lld 7 combination works on x86_64 Debian Sid (Unstable) and openSUSE Tumbleweed.
They both happen to have glibc 2.27, whereas Rawhide currently has 2.28.9000-* (is that a 2.29 prerelease?).
I mention that because the crt1.o relocatable comes from glibc-devel.

It seems I wasn't using the LLVM compilers much this Fall. The "all lld 7 versions" comment was an overstatement.
What I have from notes and logs:

02 Aug 2018 glibc upgraded to 2.28.1
11 Aug 2018 My clang/clang++/lld 6 tests ran okay
18 Aug 2018 clang/clang++/lld upgraded to 7.0.0 rc1
            Gee I wish I'd run some tests then!
21 Oct 2018 My clang/clang++/lld 7 tests failed.
            clang/clang++ with GNU ld run fine (leaving off -fuse-ld=lld option)

I've retried lld 7 a few times since, and it continues to fail.

Correction: That was glibc 2.28-1 (not 2.28.1) on 02 Aug 2018.

Another addition:

29 Nov 2018 glibc upgraded to 2.28 on Debian Sid, but clang/clang++/lld 7 combinations continue to work. Hmmm. Dunno.

I fail to reproduce the error with clang 7.0.0 from f29, same command line. Just in case can you provide a failing C file?

(In reply to serge_sans_paille from comment #5)
> I fail to reproduce the error with clang 7.0.0 from f29, same command line.
> Just in case can you provide a failing C file?

It's not Fedora 29 but Fedora 30 - rawhide.

ok, I can reproduce, checking that.

Some extra bad news: even with master version of lld, the bug happens. For some reasons I still need to exactly determine, crt1.o contains group section formatted in an unsupported way.

follow-up here: https://reviews.llvm.org/D56437. Bascally gcc emits a construction not supported by lld.

Simple reproducer, involving annobin, gcc, clang and lld:

$ gcc -O2 -c a.c -fplugin=annobin
$ clang a.o -fuse-ld=lld

  <<a.c>>
  #include <stdio.h>
  
  int foo() __attribute__((cold));
  int foo() { return 0;}
  int main(int argc, char**argv) {
    if(argc == 1023) return foo();
    else return 0;
  }

The bug should be fixed with https://koji.fedoraproject.org/koji/buildinfo?buildID=1182117

While the simple test-case does indeed work, Firefox configure still fails for me at least.

@emilio do you have a link / backtrace to share?

Created attachment 1526694 [details]
Output of configure.

This is with lld-7.0.1-3.fc30.src.rpm installed, so should have the fix, and the minimal test-case there works clang can just be regular clang-7, doesn't need to be icecc.

Created attachment 1526695 [details]
config.log

Hope it helps, let me know if you need something else.

That's super strange. I've been able to compile Python from source using the following, does that work for you?

  curl -s https://www.python.org/ftp/python/3.7.2/Python-3.7.2.tgz | tar xz
  cd Python-3.7.2/
  mkdir _build
  cd _build
  ../configure CC=clang CFLAGS=-fuse-ld=lld LDFLAGS=-fuse-ld=lld
  make

Yup, that works without issue.

how strange++.

In the attached logfile, There's a 

configure:4598: /usr/libexec/icecc/bin/clang -std=gnu99 -o conftest  -Qunused-arguments   -fuse-ld=lld conftest.c  1>&5
ld.lld: error: /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/crt1.o: unsupported SHT_GROUP format
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
configure: failed program was:
#line 4591 "configure"
#include "confdefs.h"

int main() {

; return 0; }
configure: error: compiler is incompatible with sanitize options

Do you reproduce the error when manually compiling the samefile, with the same confdefs.h? If so, can you attach this header to the bug?

Ah, I see what's going wrong. It's picking the wrong ld.lld from the mozilla-distributed clang. Sorry for the noise.

In particular they're prepending instead of appending to $PATH for some configure checks here: https://searchfox.org/mozilla-central/rev/60c4067b1cbb0f94d7dc2d7cdfa27ed579817fee/build/moz.configure/toolchain.configure#834. That's unfortunate.