problem on clang+gold

Hi there,

I compiled clang+gold using a gcc under path /s/gcc-4.3.1/bin/. Later on I do configure and make for flex-2.5.35, and the following command is invoked:
"/path/to/my/gold/ld" --hash-style=gnu --no-add-needed --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o flex /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crt1.o /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crti.o /usr/lib/gcc/i386-redhat-linux/4.1.2/crtbegin.o -L/usr/lib/gcc/i386-redhat-linux/4.1.2 -L/usr/lib/gcc/i386-redhat-linux/4.1.2/../../.. -L/lib -L/usr/lib -plugin /path/to/my/llvm/../lib/LLVMgold.so -plugin-opt=also-emit-llvm ccl.o dfa.o ecs.o scanflags.o gen.o main.o misc.o nfa.o parse.o scan.o skel.o sym.o tblcmp.o yylex.o options.o scanopt.o buf.o tables.o tables_shared.o filter.o regex.o -lm -L /s/gcc-4.3.1/lib -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i386-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crtn.o

and got errors like:
/path/to/my/gold/ld: error: dfa.o: multiple definition of 'vprintf'
/path/to/my/gold/ld: ccl.o: previous definition here
/path/to/my/gold/ld: error: dfa.o: multiple definition of 'getchar'
/path/to/my/gold/ld: ccl.o: previous definition here
...

The problem to me is that clang should really pick the library under /s/gcc-4.3.1/lib rather the one under /usr/lib/gcc.

Is this a bug that clang does not pick the correct library path? Any ways to fix this?

Thanks,
Guoliang

The problem to me is that clang should really pick the library under
/s/gcc-4.3.1/lib rather the one under /usr/lib/gcc.

Is this a bug that clang does not pick the correct library path? Any
ways to fix this?

  From the top of my head, perhaps you can look into
clang/lib/Frontend/InitHeaderSearch.cpp and try to use the GCC path you want.

HTH,
chenwj

Hi Guoliang,

Sebastian's approach is able to let clang to pick gcc-4.4.6. Thanks.

I have not tried Wei-Ren's suggestion yet.

Now the problem seems to be the bug mentioned here:http://llvm.org/bugs/show_bug.cgi?id=5960

Seem std=C89 is a workaround for this.