Bug 89599

Summary: symbol 'x86_64_entry_start' is already defined when building with LLVM/clang
Product: Mesa Reporter: Tomasz Paweł Gajc <tpgxyz>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact: mesa-dev
Severity: critical    
Priority: high CC: austinenglish, vlee
Version: 10.5   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Potential fix

Description Tomasz Paweł Gajc 2015-03-16 22:23:43 UTC
Mesa 10.5.1 does not build with LLVM/clang-3.6

Makefile:1426: recipe for target 'shared_glapi_libglapi_la-entry.lo' failed
make[4]: Leaving directory '/builddir/build/BUILD/mesa-10.5.1/src/mapi'
In file included from entry.c:49:
./entry_x86-64_tls.h:66:1: warning: tentative array definition assumed to have one element
x86_64_entry_start[];
^
fatal error: error in backend: symbol 'x86_64_entry_start' is already defined
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 3.6.0 (tags/RELEASE_360/final)

Detailed rpm-build.log can be found here
https://abf.io/build_lists/2473123
Comment 1 Tomasz Paweł Gajc 2015-04-03 10:49:25 UTC
Ping anyone ?
Comment 2 Tomasz Paweł Gajc 2015-04-07 07:44:28 UTC
This patch fixes this issues:

https://abf.io/openmandriva/mesa/blob/master/mesa-10.5.2-hide-few-symbols-to-workaround-clang.patch
Comment 3 yunlian 2015-04-24 19:25:17 UTC
Can we land this?
Comment 4 Tomasz Paweł Gajc 2015-04-25 08:53:16 UTC
Created attachment 115318 [details] [review]
Potential fix
Comment 5 Marek Olšák 2015-10-03 19:33:53 UTC
The patch should be sent to the mailing list.
Comment 6 Matt Turner 2016-01-25 16:39:22 UTC
What do I have to do to reproduce this? Mesa builds with clang (3.7.0)
fine for me. I've built with clang occasionally for a few years and
have never encountered this problem.
Comment 7 Armin K 2016-01-25 17:14:11 UTC
(In reply to Matt Turner from comment #6)
> What do I have to do to reproduce this? Mesa builds with clang (3.7.0)
> fine for me. I've built with clang occasionally for a few years and
> have never encountered this problem.

I use: CC=clang CXX="clang++ -std=libc++" CFLAGS="-march=sandybridge -g -Ofast -pipe -fstack-protector-strong", same CXXFLAGS.

This is clang 3.8.0 svn snapshot from 2 days ago. -Ofast doesn't matter here. Might be the march setting turning on something that causes the problem.
Comment 8 Tomasz Paweł Gajc 2016-01-25 22:45:20 UTC
I've build mesa-11.1.1 without a patch from comment #2.

make[4]: Entering directory '/builddir/build/BUILD/mesa-11.1.1/src/mapi'
/bin/sh ../../libtool  --tag=CC   --mode=link /usr/bin/clang -pthread -Werror=pointer-arith -Werror=vla -Oz -gdwarf-4 -Wstrict-aliasing=2 -pipe  -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4  -fPIC -flto -fno-optimize-sibling-calls -Ofast -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-math-errno -fno-trapping-math -fno-builtin-memcmp -Qunused-arguments  -no-undefined -Wl,--gc-sections -Wl,--no-undefined -Oz -gdwarf-4 -Wstrict-aliasing=2 -pipe  -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4  -fPIC -flto -Wl,-O2  -flto  -o shared-glapi/libglapi.la -rpath /usr/lib64 shared_glapi_libglapi_la-entry.lo shared_glapi_libglapi_la-mapi_glapi.lo shared_glapi_libglapi_la-stub.lo shared_glapi_libglapi_la-table.lo shared_glapi_libglapi_la-u_current.lo shared_glapi_libglapi_la-u_execmem.lo -lpthread  
libtool: link: /usr/bin/clang -shared  -fPIC -DPIC  .libs/shared_glapi_libglapi_la-entry.o .libs/shared_glapi_libglapi_la-mapi_glapi.o .libs/shared_glapi_libglapi_la-stub.o .libs/shared_glapi_libglapi_la-table.o .libs/shared_glapi_libglapi_la-u_current.o .libs/shared_glapi_libglapi_la-u_execmem.o   -lpthread  -pthread -Oz -gdwarf-4 -fstack-protector -flto -Ofast -Wl,--gc-sections -Wl,--no-undefined -Oz -gdwarf-4 -fstack-protector -flto -Wl,-O2 -flto   -pthread -Wl,-soname -Wl,libglapi.so.0 -o shared-glapi/.libs/libglapi.so.0.0.0
Makefile:1226: recipe for target 'shared-glapi/libglapi.la' failed
make[4]: Leaving directory '/builddir/build/BUILD/mesa-11.1.1/src/mapi'
LLVM ERROR: symbol 'x86_64_entry_start' is already defined
clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [shared-glapi/libglapi.la] Error 1
make[4]: *** Waiting for unfinished jobs....

Full build log:
https://abf.io/build_lists/2620585
Comment 9 Vinson Lee 2016-01-26 18:10:13 UTC
(In reply to Matt Turner from comment #6)
> What do I have to do to reproduce this? Mesa builds with clang (3.7.0)
> fine for me. I've built with clang occasionally for a few years and
> have never encountered this problem.

I can also reproduce this build error with clang.

./autogen.sh --enable-glx-tls --with-dri-drivers= --with-gallium-drivers=swrast
Comment 10 Vinson Lee 2016-07-08 23:43:03 UTC
*** Bug 92630 has been marked as a duplicate of this bug. ***
Comment 11 Matt Turner 2016-07-18 20:54:11 UTC
I sent a modified version of Tomasz's patch last week to mesa-dev.

Would anyone like to test it?

[PATCH] mapi: Massage code to allow clang to compile.
Comment 12 austinenglish@gmail.com 2016-07-19 19:40:37 UTC
(In reply to Matt Turner from comment #11)
> I sent a modified version of Tomasz's patch last week to mesa-dev.
> 
> Would anyone like to test it?
> 
> [PATCH] mapi: Massage code to allow clang to compile.

https://lists.freedesktop.org/archives/mesa-dev/2016-July/122804.html works for me, with mesa 11.0.6 and clang 3.7.1.
Comment 13 Matt Turner 2016-07-21 17:44:49 UTC
Thanks all. I've pushed the patch:

commit 5ec140c17b54c25920091501b665b9aa809cc5e8
Author: Matt Turner <mattst88@gmail.com>
Date:   Mon Jul 11 10:44:25 2016 -0700

    mapi: Massage code to allow clang to compile.
Comment 14 Tomasz Paweł Gajc 2016-07-21 20:19:36 UTC
(In reply to Matt Turner from comment #11)
> I sent a modified version of Tomasz's patch last week to mesa-dev.
> 
> Would anyone like to test it?
> 
> [PATCH] mapi: Massage code to allow clang to compile.

Thanks for this patch. It work fine with LLVM/clang-3.8.1 !

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.