gtkmm fails to compile with clang++

[318fd643-f71d-4317-9e72-7567dcb33bee]

Bugzilla Link	26784
Version	3.7
OS	Linux
CC	@compnerd,@DougGregor

Extended Description

Using clang-3.70 and gcc-5.2.0

[clang appears hardcoded to look for the loader in /lib64 rather than lib] [ld.gold has to be renamed to ld]

This works (to show that clang works in some cicumstances):

$ clang++ -flto -mtune=generic -Os -pipe -std=c++11 -E gtkmm-3.16.0/gtk/gtkmm/treeviewcolumn.cc -I/usr/local/include/glibmm-2.4 ... > foo.ii

$ clang++ -v -flto -Os -fPIC -shared -nostdlib -std=c++11 foo.ii

but:

$ CC="clang" CXX="clang++ -flto -Os -std=c++11" ./configure --prefix=/usr/local --disable-static --localstatedir=/var

$ make
..
libtool: link: clang++ -flto -Os -std=c++11 -Wall -o extra_defs_gen/generate_defs_gdk extra_defs_gen/generate_defs_gdk.o  -L/usr/local/lib /usr/local/lib/libatkmm-1.6.so /usr/local/lib/libgiomm-2.4.so /usr/local/lib/libpangomm-1.4.so /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libcairomm-1.0.so /usr/local/lib/libsigc-2.0.so /usr/local/lib/libgtk-3.so /usr/local/lib/libgdk-3.so /usr/local/lib/libpangocairo-1.0.so /usr/local/lib/libpango-1.0.so /usr/local/lib/libatk-1.0.so /usr/local/lib/libcairo-gobject.so /usr/local/lib/libcairo.so /usr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/libgio-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so /usr/local/lib/libglibmm_generate_extra_defs-2.4.so -pthread
extra_defs_gen/generate_defs_gdk.o:extra_defs_gen/generate_defs_gdk.cc:function main: error: undefined reference to 'get_defs(unsigned long, bool (*)(unsigned long))'
extra_defs_gen/generate_defs_gdk.o:extra_defs_gen/generate_defs_gdk.cc:function main: error: undefined reference to 'get_defs(unsigned long, bool (*)(unsigned long))'
extra_defs_gen/generate_defs_gdk.o:extra_defs_gen/generate_defs_gdk.cc:function main: error: undefined reference to 'get_defs(unsigned long, bool (*)(unsigned long))'
extra_defs_gen/generate_defs_gdk.o:extra_defs_gen/generate_defs_gdk.cc:function main: error: undefined reference to 'get_defs(unsigned long, bool (*)(unsigned long))'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:454: recipe for target 'extra_defs_gen/generate_defs_gdk' failed
make[2]: *** [extra_defs_gen/generate_defs_gdk] Error 1
make[2]: Leaving directory '/usr/src/gtkmm-3.16.0/tools'
Makefile:753: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/src/gtkmm-3.16.0'
Makefile:538: recipe for target 'all' failed

$ clang++ -v -flto -Os -std=c++11 -Wall -o extra_defs_gen/generate_defs_gdk extra_defs_gen/generate_defs_gdk.o  -L/usr/local/lib /usr/local/lib/libatkmm-1.6.so /usr/local/lib/libgiomm-2.4.so /usr/local/lib/libpangomm-1.4.so /usr/l
ocal/lib/libglibmm-2.4.so /usr/local/lib/libcairomm-1.0.so /usr/local/lib/libsigc-2.0.so /usr/local/lib/libgtk-3.so /usr/local/lib/lib
gdk-3.so /usr/local/lib/libpangocairo-1.0.so /usr/local/lib/libpango-1.0.so /usr/local/lib/libatk-1.0.so /usr/local/lib/libcairo-gobject.so /usr/local/lib/libcairo.so /usr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/libgio-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so /usr/local/lib/libglibmm_generate_extra_defs-2.4.so -pthread
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0
Selected GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
 "/usr/local/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o extra_defs_gen/generate_defs_gdk /usr/lib/crt1.o /usr/lib/crti.o /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/crtbegin.o -L/usr/local/lib -L/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0 -L/lib/../lib64 -L/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../.. -L/usr/local/bin/../lib -L/lib -L/usr/lib -plugin /usr/local/bin/../lib/LLVMgold.so -plugin-opt=mcpu=x86-64 extra_defs_gen/generate_defs_gdk.o /usr/local/lib/libatkmm-1.6.so /usr/local/lib/libgiomm-2.4.so /usr/local/lib/libpangomm-1.4.so /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libcairomm-1.0.so /usr/local/lib/libsigc-2.0.so /usr/local/lib/libgtk-3.so /usr/local/lib/libgdk-3.so /usr/local/lib/libpangocairo-1.0.so /usr/local/lib/libpango-1.0.so /usr/local/lib/libatk-1.0.so /usr/local/lib/libcairo-gobject.so /usr/local/lib/libcairo.so /usr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/libgio-2.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so /usr/local/lib/libglibmm_generate_extra_defs-2.4.so -lstdc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/crtend.o /usr/lib/crtn.o
extra_defs_gen/generate_defs_gdk.o:extra_defs_gen/generate_defs_gdk.cc:function main: error: undefined reference to 'get_defs(unsigned long, bool (*)(unsigned long))'
extra_defs_gen/generate_defs_gdk.o:extra_defs_gen/generate_defs_gdk.cc:function main: error: undefined reference to 'get_defs(unsigned long, bool (*)(unsigned long))'
extra_defs_gen/generate_defs_gdk.o:extra_defs_gen/generate_defs_gdk.cc:function main: error: undefined reference to 'get_defs(unsigned long, bool (*)(unsigned long))'
extra_defs_gen/generate_defs_gdk.o:extra_defs_gen/generate_defs_gdk.cc:function main: error: undefined reference to 'get_defs(unsigned long, bool (*)(unsigned long))'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[318fd643-f71d-4317-9e72-7567dcb33bee]

Yes, gcc is using /usr/local/bin/ld

[compnerd]

Ah, I think I missed this the first time around! The linker that it is using is "/usr/local/bin/ld". This is most likely a build of GNU ld, however, it seems that it does not support the object file, which means that it is possible that it doesn't support ELF x86_64, whilst the gold that gets used does support ELF x64. This is not a clang issue at all, but rather an issue with your linker.

Maybe I misunderstand, but I deleted ld.gold and gcc compiles 64-bit without problems...

Which linker is gcc actually using? Is it using /usr/local/bin/ld?

[318fd643-f71d-4317-9e72-7567dcb33bee]

This sounds like a distribution integration issue. The loader paths are defaulted, as they are the traditional paths. I know that debian has custom patches for the default loader paths.

[rant] To have a pure 64-bit system using /lib rather than /lib64 does not seem too unusual - and I hear some major distros will soon stop providing 32-bit.

It would seem logical that clang checks where the loader is rather than relying on the user to patch the source.

..and why doesn't LLVMgold.so compile and install by default? [/rant]

[318fd643-f71d-4317-9e72-7567dcb33bee]

Ah, I think I missed this the first time around! The linker that it is using is "/usr/local/bin/ld". This is most likely a build of GNU ld, however, it seems that it does not support the object file, which means that it is possible that it doesn't support ELF x86_64, whilst the gold that gets used does support ELF x64. This is not a clang issue at all, but rather an issue with your linker.

Maybe I misunderstand, but I deleted ld.gold and gcc compiles 64-bit without problems...

[318fd643-f71d-4317-9e72-7567dcb33bee]

clang gcc comparison

That means that we have something to go on then. Can you provide generate_defs_gdk.o built by clang and by gcc. Also, please provide the preprocessed output of the corresponding source file. > Furthermore, can you provide the same set (.o files from clang and gcc and the preprocessed source code) for the file that contains get_defs(unsigned long, bool (*)(unsigned long)).

See attached, note that I do not find any file containing get_defs(unsigned long, bool (*)(unsigned long)) in the gtkmm-3.16.0 source.

[compnerd]

The errors that you have demonstrated deal with unresolved symbol dependencies. > It also seems like the symbol referenced are internal. It is possible that there is some exploitation of gcc specific behavior that is permitting things to work atm? It might be useful to actually build the file that provides the internal symbol with gcc and the remainder with clang to see if that is the case.

I substituted g++ for clang++ in tool/Makefile and gtkmm-3.16.0 compiles :)

That means that we have something to go on then. Can you provide generate_defs_gdk.o built by clang and by gcc. Also, please provide the preprocessed output of the corresponding source file. Furthermore, can you provide the same set (.o files from clang and gcc and the preprocessed source code) for the file that contains get_defs(unsigned long, bool (*)(unsigned long)).

I see "clang: warning: argument unused during compilation: '-pthread'" at the final linking stage for libgtkmm-3.0, is this expected?

Sounds like it was part of the compilation. Currently, -pthread does not change compilation behavior in clang. So, that warning is expected with clang.

..and also, unlike with gcc-5.2/lto, clang/lto seems to have built libgtkmm-3.0 properly - see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953

[compnerd]

It shouldn't require gold. It should be able to use either binutils or gold. Why do you think it requires gold?

As per config.log, the ./configure test fails like this:

"/usr/local/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/crtbegin.o -L/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0 -L/lib/../lib64 -L/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../.. -L/tmp/tcloop/clang/usr/local/bin/../lib -L/lib -L/usr/lib -plugin /tmp/tcloop/clang/usr/local/bin/../lib/LLVMgold.so -plugin-opt=mcpu=x86-64 /tmp/conftest-fe34b6.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/crtend.o /usr/lib/crtn.o /tmp/conftest-fe34b6.o: file not recognized: File format not recognized clang: error: linker command failed with exit code 1

If I rename ld.gold or use "-fuse-ld=gold" then it passes

Ah, I think I missed this the first time around! The linker that it is using is /usr/local/bin/ld. This is most likely a build of GNU ld, however, it seems that it does not support the object file, which means that it is possible that it doesn't support ELF x86_64, whilst the gold that gets used does support ELF x64. This is not a clang issue at all, but rather an issue with your linker.

[318fd643-f71d-4317-9e72-7567dcb33bee]

The errors that you have demonstrated deal with unresolved symbol dependencies. > It also seems like the symbol referenced are internal. It is possible that there is some exploitation of gcc specific behavior that is permitting things to work atm? It might be useful to actually build the file that provides the internal symbol with gcc and the remainder with clang to see if that is the case.

I substituted g++ for clang++ in tool/Makefile and gtkmm-3.16.0 compiles :)

I see clang: warning: argument unused during compilation: '-pthread' at the final linking stage for libgtkmm-3.0, is this expected?

..and also, unlike with gcc-5.2/lto, clang/lto seems to have built libgtkmm-3.0 properly - see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953

[318fd643-f71d-4317-9e72-7567dcb33bee]

It shouldn't require gold. It should be able to use either binutils or gold. Why do you think it requires gold?

As per config.log, the ./configure test fails like this:

 "/usr/local/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/crtbegin.o -L/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0 -L/lib/../lib64 -L/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../.. -L/tmp/tcloop/clang/usr/local/bin/../lib -L/lib -L/usr/lib -plugin /tmp/tcloop/clang/usr/local/bin/../lib/LLVMgold.so -plugin-opt=mcpu=x86-64 /tmp/conftest-fe34b6.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/crtend.o /usr/lib/crtn.o
/tmp/conftest-fe34b6.o: file not recognized: File format not recognized
clang: error: linker command failed with exit code 1

If I rename ld.gold or use -fuse-ld=gold then it passes

[compnerd]

Im not sure I understand this. Do you mean the loader path? You should be able to override that with an explicit path passed to the linker.

clang was compiled on a pure 64-bit system, but when trying to run a simple program compiled with clang, a.out fails looking for /lib64/ld-linux-x86-64.so.2 when there is no /lib64, /usr/lib64, /usr/local/lib64.

This sounds like a distribution integration issue. The loader paths are defaulted, as they are the traditional paths. I know that debian has custom patches for the default loader paths.

This is not true. You should specify "-fuse-ld=gold" as part of your LDFLAGS (you might be able to get away with it in CFLAGS/CXXFLAGS).

OK, but if clang requires ld.gold, can't it just use ld.gold?

It shouldn't require gold. It should be able to use either binutils or gold. Why do you think it requires gold?

[318fd643-f71d-4317-9e72-7567dcb33bee]

Im not sure I understand this. Do you mean the loader path? You should be able to override that with an explicit path passed to the linker.

clang was compiled on a pure 64-bit system, but when trying to run a simple program compiled with clang, a.out fails looking for /lib64/ld-linux-x86-64.so.2 when there is no /lib64, /usr/lib64, /usr/local/lib64.

This is not true. You should specify "-fuse-ld=gold" as part of your LDFLAGS (you might be able to get away with it in CFLAGS/CXXFLAGS).

OK, but if clang requires ld.gold, can't it just use ld.gold?

[compnerd]

Using clang-3.70 and gcc-5.2.0

[clang appears hardcoded to look for the loader in /lib64 rather than lib]

Im not sure I understand this. Do you mean the loader path? You should be able to override that with an explicit path passed to the linker.

[ld.gold has to be renamed to ld]

This is not true. You should specify -fuse-ld=gold as part of your LDFLAGS (you might be able to get away with it in CFLAGS/CXXFLAGS).

The errors that you have demonstrated deal with unresolved symbol dependencies. It also seems like the symbol referenced are internal. It is possible that there is some exploitation of gcc specific behavior that is permitting things to work atm? It might be useful to actually build the file that provides the internal symbol with gcc and the remainder with clang to see if that is the case.