Hi!

it's kind of odd. Using gcc for compilation leads to this error during 
compilation:
tools/lto/CMakeFiles/LTO.dir/build.make:278: recipe for target 
'lib/libLTO.so.8svn' failed
make[2]: *** [lib/libLTO.so.8svn] Error 1
make[2]: *** Deleting file 'lib/libLTO.so.8svn'
CMakeFiles/Makefile2:20689: recipe for target 
'tools/lto/CMakeFiles/LTO.dir/all' failed
make[1]: *** [tools/lto/CMakeFiles/LTO.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

This seems to be related to 
this: https://groups.google.com/forum/#!topic/llvm-dev/KH3DHQo0A38

Does setting those flags disable the -DCMAKE_BUILD_TYPE=Release 
-DLLVM_USE_LINKER=gold flags? It seems the built files are quite large... 
(hinting at additional debug info)

On Monday, December 17, 2018 at 4:20:07 PM UTC+1, Than McIntosh wrote:
>
>
> Thanks for reporting this problem.
>
> As Ian said, one of the go library sources includes  <cpuid.h>, and then 
> expects to see an inline definition of that routine.
>
> I poked around a little and it looks as though versions of clang prior to 
> 5.0 do provide a definition of <cpuid.h>, but they don't 
> define __get_cpuid_count -- that seems to have been added later in this 
> commit 
> <https://github.com/llvm-mirror/clang/commit/723acf9205420108ade64c216de7ca30181c7877>
> .
>
> Do you have a later version of clang that you could use as your build 
> compiler (5.0 later)? Or could you use GCC instead? Either of these should 
> take care of this problem. In you cmake invocation you'll want to use
>
> cmake ...
>   -DCMAKE_ASM_COMPILER=/usr/bin/gcc \
>   -DCMAKE_CXX_COMPILER=/usr/bin/g++ \
>   -DCMAKE_C_COMPILER=/usr/bin/gcc \
>
> Or equivalent.
>
> I will add a note to the FAQ on this, since others may also run into it.
>
> Thanks, Than
>
>
>
>
>
>
>
> On Sun, Dec 16, 2018 at 7:17 PM Ian Lance Taylor <ia...@golang.org 
> <javascript:>> wrote:
>
>> [ + thanm ]
>>
>> On Sat, Dec 15, 2018 at 6:56 AM <ben...@gmail.com <javascript:>> wrote:
>> >
>> > I'm trying to use the current gollvm build, but it seems there is a 
>> symbol error. Probably that symbol is absent in the libgo release?
>> > Anyone had a similar problem or an idea how I can fix that?
>>
>> The libgo sources expect __get_cpuid_count to be defined by the
>> compiler intrinsics header <cpuid.h>.  This is true for GCC.  The
>> reference to the symbol is in libgo/go/internal/cpu/cpu_gccgo.c.
>>
>> Than: does the LLVM version of <cpuid.h> define __get_cpuid_count?  If
>> not, I guess we need to tweak cpu_gccgo.c.
>>
>> Ian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to