gtkmm fails to compile with clang++

[Quuxplusone]

Bugzilla Link	PR26784
Status	NEW
Importance	P normal
Reported by	john.frankish@outlook.com
Reported on	2016-03-01 03:43:07 -0800
Last modified on	2016-03-05 23:27:23 -0800
Version	3.7
Hardware	PC Linux
CC	compnerd@compnerd.org, dgregor@apple.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments	clang_gcc_comp.tar.xz (330468 bytes, text/plain)
Blocks
Blocked by
See also

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)

[Quuxplusone]

(In reply to comment #0)
> 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.

[Quuxplusone]

> 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?

[Quuxplusone]

(In reply to comment #2)
> > 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?

[Quuxplusone]

> 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

[Quuxplusone]

> 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

[Quuxplusone]

(In reply to comment #4)
> > 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.

[Quuxplusone]

(In reply to comment #5)

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

[Quuxplusone]

Attached clang_gcc_comp.tar.xz (330468 bytes, text/plain): clang gcc comparison

[Quuxplusone]

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

[Quuxplusone]

> 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]

[Quuxplusone]

(In reply to comment #9)
> > 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?

[Quuxplusone]

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