Re: [blfs-dev] rustc-1.25
> Umm, installed in /root instead of /usr/bin ? No, I was logged in as root and was using tab completion to find out the various rust programs. > I think that so far everyone has had 1.22.1 installed when trying to > build 1.25.0. In theory, using the previous versions of rust and > cargo (so 1.24.x for rust) can avoid the stage0 downloads with the > right settings - but we don't do that. Ok. I don't mind the stage0 download (unlimited relatively slow internet here). Alain -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 05:18:10PM -0500, Bruce Dubbs wrote: > On 04/15/2018 05:15 PM, Ken Moffat wrote: > > On Sat, Apr 14, 2018 at 01:24:46PM -0400, Alain Toussaint wrote: > > > > > > root [ ~ ]# rust > > > rustc rustdocrust-gdb rust-lldb > > > > Umm, installed in /root instead of /usr/bin ? > > He did rust for tab completion. > > -- Bruce Too clever by half for me ;) ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 12:49:38PM -0400, Alain Toussaint wrote: > > > -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG > > -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed > > > I do get these failures but the configure & build steps went fine on the > stock build instruction: > > CC=gcc CXX=g++ \ > cmake -DCMAKE_INSTALL_PREFIX=/usr \ > -DLLVM_ENABLE_FFI=ON \ > -DCMAKE_BUILD_TYPE=Release\ > -DLLVM_BUILD_LLVM_DYLIB=ON\ > -DLLVM_TARGETS_TO_BUILD="host;AMDGPU" \ > -Wno-dev > > build log not included, I can send it separately out of the list (718k) but > I'm currently rebuilding > by hand using all targets (most of my video cards are nvidia here so building > all target because of > lazyness). > > Alain A comment on this and another of your posts which I can't immediately lay my hands on, but where I think you said you were using -j1: For this post: llvm is only needed for (expletivve-deleted) packages such as rust (and the bpf part of the kernel - aka "a Spectre vulnerability" although that vulnerability is probably now worked around), but some other packages will prefer to use it if present. The extra targets include BPF (qv) but otherwise they are mostly other architectures - so if you want to use llvm to build for those other architectures (or to use system llvm to build rust for them), not limiting will help. But if all you have is x86 and nvidia then the book's restriction will allow you to build mesa for radeon (but not run it, obviously), or you might prefer to just drop to X86. As to using -j1 : remember that rust will use all available cores. See the editor's guide (chapter 6) re taskset, but I need to update that: on intel, multithreaded CPUs are actually paired by the 'core id' in /proc/cpuinfo and in practice the first half of the cores are prime so on an 8-way SMT machine cores 4-7 are the siblings of cores 0-3 and only using one of each pair is still 'prime', using both cores of a pair gives the increased compilation times found with large packages on SMT. NB I don't have any SMT AMD's except my kaveri[1], and there the info in /proc/cpuinfo is unreliable (it suggests all the cores are real). More generally, if you are mostly building with -j1 you might want to consider something one of the contributors to blfs-support has done: use Makefiles, with each package a target depending on its dependencies. So in the end multiple packages can build at the same time. 1. My Ryzen is a 1300X which is the non-multithreaded version of the 1500X - 4 real cores. People with Ryzen 5/7 or FX* CPUs may be able to tell how the core IDs map out. If anyone has Threadripper, I assume they are actually using all the cores to build - there might be NUMA issues if restricting them! ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/15/2018 05:15 PM, Ken Moffat wrote: On Sat, Apr 14, 2018 at 01:24:46PM -0400, Alain Toussaint wrote: I have a nearly ready made system done with llvm 6 and rust 1.22.1: I came to answer this because I couldn't remember if your question at the end had been answered. But ... root [ ~ ]# llvm-config --version 6.0.0 root [ ~ ]# rust rustc rustdocrust-gdb rust-lldb Umm, installed in /root instead of /usr/bin ? He did rust for tab completion. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sat, Apr 14, 2018 at 01:24:46PM -0400, Alain Toussaint wrote: > > I have a nearly ready made system done with llvm 6 and rust 1.22.1: > I came to answer this because I couldn't remember if your question at the end had been answered. But ... > root [ ~ ]# llvm-config --version > 6.0.0 > root [ ~ ]# rust > rustc rustdocrust-gdb rust-lldb Umm, installed in /root instead of /usr/bin ? > root [ ~ ]# rustc --version > rustc 1.22.1 > root [ ~ ]# > > I can try to build rust 1.25 and report back but are there any pitfall of > doing so when rust 1.22.1 > is installed? > > Alain I think that so far everyone has had 1.22.1 installed when trying to build 1.25.0. In theory, using the previous versions of rust and cargo (so 1.24.x for rust) can avoid the stage0 downloads with the right settings - but we don't do that. ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 09:07:15PM +0100, Ken Moffat wrote: > > And yesterday I tried building llvm in /tmp for speed (tmpfs, should > be fast) - only to discover that for some reason the fstab I had > started from (system was a binary copy from an older machine, fstab > modified to point to the correct partitions) restricted the size of > /tmp to 2GB. Can't remember why I did that, now changed. Just to be clear - I copied a binary system and used that to build the LFS I am running. But I create machine-specific 'hostfile's for things like fstab (various things such as /boot, /home, swap at fixed locations, as well as my /scratch directory) as well as for "can it suspend or hibernate" and "which xorg driver". Just being pedantic because I wouldn't want to think I was doing things for the book on a binary-installed system ;) ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/15/2018 02:57 PM, Ken Moffat wrote: On my system,: llvm-config --libs all gives -lLLVM-6.0 llvm-config --libs gives -lLLVM-6.0 llvm-config --system-libs returns an empty line Yes, I get the same. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 15/04/2018 21:57, Ken Moffat wrote:
> On Sun, Apr 15, 2018 at 01:01:54PM -0500, Bruce Dubbs wrote:
>> On 04/15/2018 11:14 AM, baldu...@units.it wrote:
>>>
>>> I saw the "undefined symbol: ffi_type_float" error quite a long ago with
>>> 1.17.0 and it was fixed by:
>>>
>>> export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi"
>>
>> Well that fixed it for me. Adding that to the book would be harmless if it
>> is not needed. The issue now is why some need it and others do not.
>>
>
> Confirmed it is harmless.
>
>> I wonder if others are returning something different for
>> llvm-config. I'm not sure what parameters are but a grep of the rustc
>> source gives:
>>
>> llvm-config --cxxflags --ldflags --system-libs --libs core orc native
>> llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native
>> llvm-config --libs all
>>
>> and others
>>
>> My system for 'llvm-config --libs all' gives -lLLVM-6.0
>>
>
> On my system,:
>
> llvm-config --libs all gives -lLLVM-6.0
>
> llvm-config --libs gives -lLLVM-6.0
>
> llvm-config --system-libs returns an empty line
>
Same here.
About the DESTDIR install. There are 2 problems with /sources/RUST:
- Some users may have another build directory (/usr/src comes to mind), or
/sources may be readonly, or...
- /sources/RUST is not removed when the build directory is removed.
So I like the approach of using ${PWD}/DESTDIR (or ${PWD}/whatever).
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 01:43:52PM -0500, Bruce Dubbs wrote:
> On 04/15/2018 01:16 PM, Ken Moffat wrote:
> > On Sun, Apr 15, 2018 at 11:27:22AM +0200, Pierre Labastie wrote:
> > >
> > > Done, and it built. Ken, don't you think the instructions should wipe out
> > > /sources/RUST after installing?
> > >
> > > Pierre
> > >
> > We don't explicitly remove the build directories, AFAICS.
> >
> > This is a first (hopefully the only) DESTDIR in the book and I'm
> > reluctant to blow it away before we know if there are possible
> > problems with it (unexpectedly, the problems seem to be in the
> > builds).
>
> Actually, I like the idea of having an example DESTDIR install in the book.
>
I think I am thoroughly pissed off by everything related to rust :)
> >
> > I suppose we could do something like ${PWD}/DESTDIR to install it
> > within the build tree, and then the real install would be something
> > like:
> >
> > chown -R root:root DESTDIR
> > cp -a DESTDIR/* *
> >
> > and it would all get blown away when the source was removed. But
> > maybe I'm missing something.
>
> Perhaps a note to say to replace 'sources' with the user's choice of
> directory would be appropriate.
>
On reflection, I think that putting the DESTDIR in the current
directory (and therefore removing it with that) will be cleaner.
> I tend to build in /tmp (which I have mounted as a separate partition).
> Personally I do:
>
> DIR=`pwd`
>
> BUILDDIR=/tmp/
> DEST=$BUILDDIR/install
>
> sudo rm -rf $BUILDDIR
> mkdir $BUILDDIR
> cd $BUILDDIR
>
> tar -xf $DIR/$PROGRAM.tar.?z*
> cd $PROGRAM
> ...
> DESTDIR="$DEST"
>
> But there are many ways to select a DESTDIR. The example used now is fine,
> but there should be something to tell the users that there is flexibility in
> that choice.
>
I like calling it 'install'.
> Note. The reason I build in /tmp is because I store my sources and scripts
> in an nfs mounted directory. I've found actually building over nfs is
> fairly slow, especially the tarball extraction. Extracting from the nfs
> partition to a local partition is reasonably fast.
I too have /sources on nfs. Yeah, from time to time I am building on
multiple machines, sometimes two are updating firefox (or rust or
qt/qtwebengine) at the same time so a single /sources on nfs doesn't
work - quite apart from the slowness of building over nfs.
But for untarring I mostly don't notice the times.
And yesterday I tried building llvm in /tmp for speed (tmpfs, should
be fast) - only to discover that for some reason the fstab I had
started from (system was a binary copy from an older machine, fstab
modified to point to the correct partitions) restricted the size of
/tmp to 2GB. Can't remember why I did that, now changed.
Will start a new thread listing how I propose to change llvm and
rustc.
ĸen
--
In my seventh decade astride this planet, and as my own cells degrade,
there are some things I cannot do now: skydiving, marathon running,
calculus. I couldn't do them in my 20s either, so no big loss.
-- Derek Smalls, formerly of Spinal Tap
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 01:01:54PM -0500, Bruce Dubbs wrote: > On 04/15/2018 11:14 AM, baldu...@units.it wrote: > > > > I saw the "undefined symbol: ffi_type_float" error quite a long ago with > > 1.17.0 and it was fixed by: > > > > export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" > > Well that fixed it for me. Adding that to the book would be harmless if it > is not needed. The issue now is why some need it and others do not. > Confirmed it is harmless. > I wonder if others are returning something different for > llvm-config. I'm not sure what parameters are but a grep of the rustc > source gives: > > llvm-config --cxxflags --ldflags --system-libs --libs core orc native > llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native > llvm-config --libs all > > and others > > My system for 'llvm-config --libs all' gives -lLLVM-6.0 > On my system,: llvm-config --libs all gives -lLLVM-6.0 llvm-config --libs gives -lLLVM-6.0 llvm-config --system-libs returns an empty line ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/15/2018 01:16 PM, Ken Moffat wrote:
On Sun, Apr 15, 2018 at 11:27:22AM +0200, Pierre Labastie wrote:
Done, and it built. Ken, don't you think the instructions should wipe out
/sources/RUST after installing?
Pierre
We don't explicitly remove the build directories, AFAICS.
This is a first (hopefully the only) DESTDIR in the book and I'm
reluctant to blow it away before we know if there are possible
problems with it (unexpectedly, the problems seem to be in the
builds).
Actually, I like the idea of having an example DESTDIR install in the book.
I was originally going to use a bit of bash to place the directory
at ../ (because I know it's not just me who doesn't build in
sources), until I realised that not _knowing_ the absolute directory
may give problems depending on how people become root.
I suppose we could do something like ${PWD}/DESTDIR to install it
within the build tree, and then the real install would be something
like:
chown -R root:root DESTDIR
cp -a DESTDIR/* *
and it would all get blown away when the source was removed. But
maybe I'm missing something.
Perhaps a note to say to replace 'sources' with the user's choice of
directory would be appropriate.
I tend to build in /tmp (which I have mounted as a separate partition).
Personally I do:
DIR=`pwd`
BUILDDIR=/tmp/
DEST=$BUILDDIR/install
sudo rm -rf $BUILDDIR
mkdir $BUILDDIR
cd $BUILDDIR
tar -xf $DIR/$PROGRAM.tar.?z*
cd $PROGRAM
...
DESTDIR="$DEST"
But there are many ways to select a DESTDIR. The example used now is
fine, but there should be something to tell the users that there is
flexibility in that choice.
-- Bruce
Note. The reason I build in /tmp is because I store my sources and
scripts in an nfs mounted directory. I've found actually building over
nfs is fairly slow, especially the tarball extraction. Extracting from
the nfs partition to a local partition is reasonably fast.
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 11:27:22AM +0200, Pierre Labastie wrote:
>
> Done, and it built. Ken, don't you think the instructions should wipe out
> /sources/RUST after installing?
>
> Pierre
>
We don't explicitly remove the build directories, AFAICS.
This is a first (hopefully the only) DESTDIR in the book and I'm
reluctant to blow it away before we know if there are possible
problems with it (unexpectedly, the problems seem to be in the
builds).
I was originally going to use a bit of bash to place the directory
at ../ (because I know it's not just me who doesn't build in
sources), until I realised that not _knowing_ the absolute directory
may give problems depending on how people become root.
I suppose we could do something like ${PWD}/DESTDIR to install it
within the build tree, and then the real install would be something
like:
chown -R root:root DESTDIR
cp -a DESTDIR/* *
and it would all get blown away when the source was removed. But
maybe I'm missing something.
ĸen
--
In my seventh decade astride this planet, and as my own cells degrade,
there are some things I cannot do now: skydiving, marathon running,
calculus. I couldn't do them in my 20s either, so no big loss.
-- Derek Smalls, formerly of Spinal Tap
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/15/2018 11:14 AM, baldu...@units.it wrote: hi, There remains to understand why Bruce has an error with libffi. There is no mention of libffi in my rust build log. I routinely build rustc vs system llvm I had no problems building rustc-1.25.0 vs llvm-6.0 I saw the "undefined symbol: ffi_type_float" error quite a long ago with 1.17.0 and it was fixed by: export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" Well that fixed it for me. Adding that to the book would be harmless if it is not needed. The issue now is why some need it and others do not. I wonder if others are returning something different for llvm-config. I'm not sure what parameters are but a grep of the rustc source gives: llvm-config --cxxflags --ldflags --system-libs --libs core orc native llvm-config --cxxflags --ldflags --system-libs --libs core mcjit native llvm-config --libs all and others My system for 'llvm-config --libs all' gives -lLLVM-6.0 I have: $ ldd /usr/lib/libLLVM-6.0.so linux-vdso.so.1 (0x7ffe50da7000) libffi.so.6 => /usr/lib/../lib/libffi.so.6 (0x7f06085c) ... so I would think that the system would pick up libffi from that. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 07:01:10PM +0200, baldu...@units.it wrote: > > Tools will only be linked to the libLLVM shared library if > LLVM_LINK_LLVM_DYLIB > is also ON. Thanks for that explanation. ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 11:42:56AM -0500, Bruce Dubbs wrote: > > Well this is interesting. I tried to build llvm with: > > CC=gcc \ > CXX=g++ \ > cmake -DCMAKE_INSTALL_PREFIX=/usr \ > -DLLVM_ENABLE_FFI=ON \ > -DCMAKE_BUILD_TYPE=Release\ > -DLLVM_BUILD_LLVM_DYLIB=ON\ > -DLLVM_LINK_LLVM_DYLIB=ON \ > -DBUILD_SHARED_LIBS=ON\ > -DLLVM_TARGETS_TO_BUILD="host;AMDGPU" \ > -Wno-dev .. > > > -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG > -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed > CMake Error at tools/llvm-shlib/CMakeLists.txt:39 (list): > list sub-command REMOVE_DUPLICATES requires list to be present. > > > -- Configuring incomplete, errors occurred! > I noticed that failed test last night when I was doing the manual builds, but I did not have an error. ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/15/2018 12:01 PM, baldu...@units.it wrote: Well this is interesting. I tried to build llvm with: [snip] Here are my notes about the above problem, which I wrote for 4.0.0 (2017-04-29), but I guess still apply. The essence is: do NOT switch *BOTH* LLVM_BUILD_LLVM_DYLIB and BUILD_SHARED_LIBS ON (BTW, this caused a nasty problem with mesa build, as mentioned below) [snip] Thanks for that. It clears up one problem. What we have for llvm seems to be ok. The issue is rustc and I was experimenting. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
> Well this is interesting. I tried to build llvm with: > > CC=gcc \ > CXX=g++ \ > cmake -DCMAKE_INSTALL_PREFIX=/usr \ >-DLLVM_ENABLE_FFI=ON \ >-DCMAKE_BUILD_TYPE=Release\ >-DLLVM_BUILD_LLVM_DYLIB=ON\ >-DLLVM_LINK_LLVM_DYLIB=ON \ >-DBUILD_SHARED_LIBS=ON\ >-DLLVM_TARGETS_TO_BUILD="host;AMDGPU" \ >-Wno-dev .. > > > -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG > -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed > CMake Error at tools/llvm-shlib/CMakeLists.txt:39 (list): >list sub-command REMOVE_DUPLICATES requires list to be present. > > Here are my notes about the above problem, which I wrote for 4.0.0 (2017-04-29), but I guess still apply. The essence is: do NOT switch *BOTH* LLVM_BUILD_LLVM_DYLIB and BUILD_SHARED_LIBS ON (BTW, this caused a nasty problem with mesa build, as mentioned below) 8< * We now build with -DBUILD_SHARED_LIBS=ON * At first, got: CMake Error at tools/llvm-shlib/CMakeLists.txt:39 (list): list sub-command REMOVE_DUPLICATES requires list to be present. The fix seems to be commenting the offending line in tools/llvm-shlib/CMakeLists.txt * Then I found that building mesa vs the just built llvm wasn't working: the reason was that I was building with BOTH LLVM_BUILD_LLVM_DYLIB and BUILD_SHARED_LIBS enabled. This has a nasty consequence: How to build mesa with llvm shared libs === llvm's libraries can be built in two ways: 1. -DLLVM_BUILD_LLVM_DYLIB=ON -DBUILD_SHARED_LIBS=OFF (the default, so might be omitted) 2. -DLLVM_BUILD_LLVM_DYLIB=OFF (or omitted) -DBUILD_SHARED_LIBS=ON When building with 1., all individual libs are built as static libs (.a) and a jumbo libLLVM-x.y.z.so shared lib containing all the functions defined in the static libs is also built. When building with 2., all individual libs are built as shared libs (.so) and no jumbo libLLVM-x.y.z.so shared lib is built. Do not (not noT nOT NOT!!!) enable BOTH LLVM_BUILD_LLVM_DYLIB and BUILD_SHARED_LIBS!!! This is explicitly stated in docs/Cmake.rst: **LLVM_BUILD_LLVM_DYLIB**:BOOL If enabled, the target for building the libLLVM shared library is added. This library contains all of LLVM's components in a single shared library. Defaults to OFF. This cannot be used in conjunction with BUILD_SHARED_LIBS. ^ Tools will only be linked to the libLLVM shared library if LLVM_LINK_LLVM_DYLIB is also ON. The components in the library can be customised by setting LLVM_DYLIB_COMPONENTS to a list of the desired components. If both LLVM_BUILD_LLVM_DYLIB and BUILD_SHARED_LIBS are ON, this is the NASTY thing that happens: all individual libs are built as shared libs (.so); HOWEVER, a dummy libLLVM-x.y.z.so shared lib is also built: in this case, the libLLVM-x.y.z.so contains (almost) nothing. Now: if you then build mesa vs this botched llvm, you will get a build _crash for the following reason; the configure code of mesa that deals with the llvm shared libs is the following: [...] if test "x$enable_llvm_shared_libs" = xyes; then LLVM_SO_NAME=LLVM-`$LLVM_CONFIG --version` if test -f "$LLVM_LIBDIR/lib$LLVM_SO_NAME.$IMP_LIB_EXT"; then : llvm_have_one_so=yes fi [...] ie, IF it finds libLLVM-x.y.z.so, it will use that. BUT, when llvm was built with both LLVM_BUILD_LLVM_DYLIB and BUILD_SHARED_LIBS enabled, libLLVM-x.y.z.so contains garbage and this will make the build of mesa miserably fail with a bunch of undefined llvm function calls (also: difficult to debug) So be supersure that only one of LLVM_BUILD_LLVM_DYLIB and BUILD_SHARED_LIBS is enabled!!! >8 -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
> -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG > -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed I do get these failures but the configure & build steps went fine on the stock build instruction: CC=gcc CXX=g++ \ cmake -DCMAKE_INSTALL_PREFIX=/usr \ -DLLVM_ENABLE_FFI=ON \ -DCMAKE_BUILD_TYPE=Release\ -DLLVM_BUILD_LLVM_DYLIB=ON\ -DLLVM_TARGETS_TO_BUILD="host;AMDGPU" \ -Wno-dev build log not included, I can send it separately out of the list (718k) but I'm currently rebuilding by hand using all targets (most of my video cards are nvidia here so building all target because of lazyness). Alain -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/15/2018 02:25 AM, Pierre Labastie wrote: On 14/04/2018 23:50, Ken Moffat wrote: On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote: I think there is a switch for building shared libraries in llvm. The book was using it at a time, but there were problems with mesa IIRC. The switch is -DBUILD_SHARED_LIBS=ON, and the documentation still says: ``BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option.'' The book uses the LLVM_BUILD_LLVM_DYLIB option. Indeed it does, but I see that I also use -DLLVM_LINK_LLVM_DYLIB=ON. I assume that might have been in the book at some time, but it's what I've been using without obvious problems. I'll try -DLLVM_LINK_LLVM_DYLIB=ON soon, but I wanted to let you know that rustc built with book's instructions on LLVM built with -DBUILD_SHARED_LIBS=ON. Well this is interesting. I tried to build llvm with: CC=gcc \ CXX=g++ \ cmake -DCMAKE_INSTALL_PREFIX=/usr \ -DLLVM_ENABLE_FFI=ON \ -DCMAKE_BUILD_TYPE=Release\ -DLLVM_BUILD_LLVM_DYLIB=ON\ -DLLVM_LINK_LLVM_DYLIB=ON \ -DBUILD_SHARED_LIBS=ON\ -DLLVM_TARGETS_TO_BUILD="host;AMDGPU" \ -Wno-dev .. -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed CMake Error at tools/llvm-shlib/CMakeLists.txt:39 (list): list sub-command REMOVE_DUPLICATES requires list to be present. -- Configuring incomplete, errors occurred! -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
hi, > There remains to understand why Bruce has an error with libffi. There is no > mention of libffi in my rust build log. I routinely build rustc vs system llvm I had no problems building rustc-1.25.0 vs llvm-6.0 I saw the "undefined symbol: ffi_type_float" error quite a long ago with 1.17.0 and it was fixed by: export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" (which, BTW, I got from BLFS) Since then, I left it in my install script, so may be it is still needed: didn't try to run without it for 1.25.0, though. Also, I see this in my install script, when using config.toml: # ESSENTIAL for linking against llvm shared libs # this is the equivalent of --enable-llvm-link-shared when using configure export LLVM_LINK_SHARED=1 Don't remember where I got that, perhaps here: https://github.com/rust-lang/rust/issues/46995 ciao -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
Le samedi 14 avril 2018 à 22:26 +0200, Pierre Labastie a écrit : > On 14/04/2018 19:18, Pierre Labastie wrote: > > On 14/04/2018 18:18, Bruce Dubbs wrote: > > > On 04/13/2018 11:38 PM, Bruce Dubbs wrote: > > > > Using the new instructions in the book O could not get rustc to build. > > > > I was > > > > getting: > > > > > > > > --- stderr > > > > error: couldn't load codegen backend > > > > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64- > > > > unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": > > > > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64- > > > > unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: > > > > undefined symbol: ffi_type_float" > > > > > > > > === > > > > > > > > Note: ffi_type_float is defined as a symbol in libffi.so. > > > > > > > > > > > > > > Do we need to adjust the book's instructions? > > > > > > > I'd say not before understanding what is going on... Let me try building > > rust > > with the new instructions, after installing llvm 6, and removing completely > > llvm 5 (using porg). > > > > And then... Another error on my side: > - > [...] > cargo:rustc-link-search=native=/sources/rust/rustc-1.25.0-src/build/x86_64-unkno > wn-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-7878 > f9d37a1306fb/out > > --- stderr > llvm-config: error: missing: /usr/lib/libLLVMDemangle.so > llvm-config: error: missing: /usr/lib/libLLVMSupport.so > llvm-config: error: missing: /usr/lib/libLLVMBinaryFormat.so > llvm-config: error: missing: /usr/lib/libLLVMCore.so > llvm-config: error: missing: /usr/lib/libLLVMAsmParser.so > llvm-config: error: missing: /usr/lib/libLLVMBitReader.so > llvm-config: error: missing: /usr/lib/libLLVMMC.so > llvm-config: error: missing: /usr/lib/libLLVMMCParser.so > llvm-config: error: missing: /usr/lib/libLLVMObject.so > [... fifty so lines like that ...] > llvm-config: error: missing: /usr/lib/libLLVMX86AsmParser.so > llvm-config: error: missing: /usr/lib/libLLVMX86Disassembler.so > thread 'main' panicked at 'command did not execute successfully: > "/usr/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "asmparser" > "bitreader" "bitwriter" "instrumentation" "interpreter" "ipo" "linker" "lto" > "mcjit" "x86" > --- > And indeed, running the command: > --- > $ llvm-config --link-shared --libs > --- > returns the same list of errors as above, while > --- > $ llvm-config --libs > --- > returns a bunch of static libraries without errors. > > I think there is a switch for building shared libraries in llvm. The book was > using it at a time, but there were problems with mesa IIRC. > > The switch is -DBUILD_SHARED_LIBS=ON, and the documentation still says: > ``BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you > want to build LLVM as a shared library, you should use the > LLVM_BUILD_LLVM_DYLIB option.'' > > The book uses the LLVM_BUILD_LLVM_DYLIB option. > > So: three persons; three different outcomes... > > Let me rebuild llvm with -DBUILD_SHARED_LIBS=ON. I'll give the results > tomorrow (my time), since llvm+rustc build time ~ 3 hours, and I'll be > sleeping when it ends. > > Pierre > In that regard, I'm also getting these on the new build of llvm: lfs:~/blfs_root/work$ llvm-config --link-shared --libs llvm-config: error: missing: /usr/lib/libLLVMDemangle.so llvm-config: error: missing: /usr/lib/libLLVMSupport.so llvm-config: error: missing: /usr/lib/libLLVMBinaryFormat.so llvm-config: error: missing: /usr/lib/libLLVMCore.so llvm-config: error: missing: /usr/lib/libLLVMBitReader.so llvm-config: error: missing: /usr/lib/libLLVMMC.so llvm-config: error: missing: /usr/lib/libLLVMMCParser.so llvm-config: error: missing: /usr/lib/libLLVMObject.so llvm-config: error: missing: /usr/lib/libLLVMProfileData.so llvm-config: error: missing: /usr/lib/libLLVMAnalysis.so llvm-config: error: missing: /usr/lib/libLLVMBitWriter.so llvm-config: error: missing: /usr/lib/libLLVMTransformUtils.so llvm-config: error: missing: /usr/lib/libLLVMInstCombine.so llvm-config: error: missing: /usr/lib/libLLVMAsmParser.so llvm-config: error: missing: /usr/lib/libLLVMIRReader.so llvm-config: error: missing: /usr/lib/libLLVMLinker.so llvm-config: error: missing: /usr/lib/libLLVMScalarOpts.so llvm-config: error: missing: /usr/lib/libLLVMVectorize.so llvm-config: error: missing: /usr/lib/libLLVMInstrumentation.so llvm-config: error: missing: /usr/lib/libLLVMipo.so llvm-config: error: missing: /usr/lib/libLLVMCoroutines.so llvm-config: error: missing: /usr/lib/libLLVMTarget.so llvm-config: error: missing: /usr/lib/libLLVMCodeGen.so llvm-config: error: missing: /usr/lib/libLLVMRuntimeDyld.so llvm-config: error: missing: /usr/lib/libLLVMExecutionEngine.so llvm-config: error: missing: /usr/lib/libLLVMInterpreter.so llvm-config: error: missing: /usr/lib/libLLVMLineE
Re: [blfs-dev] rustc-1.25
On 15/04/2018 09:25, Pierre Labastie wrote: > On 14/04/2018 23:50, Ken Moffat wrote: >> On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote: >>> > > Do we need to adjust the book's instructions? > I'd say not before understanding what is going on... Let me try building rust with the new instructions, after installing llvm 6, and removing completely llvm 5 (using porg). >>> >>> And then... Another error on my side: >>> - >>> [...] >>> cargo:rustc-link-search=native=/sources/rust/rustc-1.25.0-src/build/x86_64-unkno >>> wn-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-7878 >>> f9d37a1306fb/out >>> >>> --- stderr >>> llvm-config: error: missing: /usr/lib/libLLVMDemangle.so >>> llvm-config: error: missing: /usr/lib/libLLVMSupport.so >> [...] >>> [... fifty so lines like that ...] >>> llvm-config: error: missing: /usr/lib/libLLVMX86AsmParser.so >>> llvm-config: error: missing: /usr/lib/libLLVMX86Disassembler.so >>> thread 'main' panicked at 'command did not execute successfully: >>> "/usr/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "asmparser" >>> "bitreader" "bitwriter" "instrumentation" "interpreter" "ipo" "linker" "lto" >>> "mcjit" "x86" >>> --- >>> And indeed, running the command: >>> --- >>> $ llvm-config --link-shared --libs >>> --- >>> returns the same list of errors as above, while >>> --- >>> $ llvm-config --libs >>> --- >>> returns a bunch of static libraries without errors. >>> >>> I think there is a switch for building shared libraries in llvm. The book >>> was >>> using it at a time, but there were problems with mesa IIRC. >>> >>> The switch is -DBUILD_SHARED_LIBS=ON, and the documentation still says: >>> ``BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you >>> want to build LLVM as a shared library, you should use the >>> LLVM_BUILD_LLVM_DYLIB option.'' >>> >>> The book uses the LLVM_BUILD_LLVM_DYLIB option. >>> >> Indeed it does, but I see that I also use -DLLVM_LINK_LLVM_DYLIB=ON. >> I assume that might have been in the book at some time, but it's >> what I've been using without obvious problems. > > I'll try -DLLVM_LINK_LLVM_DYLIB=ON soon Done, and it built. Ken, don't you think the instructions should wipe out /sources/RUST after installing? Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 14/04/2018 23:50, Ken Moffat wrote: > On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote: >> Do we need to adjust the book's instructions? >>> >>> I'd say not before understanding what is going on... Let me try building >>> rust >>> with the new instructions, after installing llvm 6, and removing completely >>> llvm 5 (using porg). >>> >> >> And then... Another error on my side: >> - >> [...] >> cargo:rustc-link-search=native=/sources/rust/rustc-1.25.0-src/build/x86_64-unkno >> wn-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-7878 >> f9d37a1306fb/out >> >> --- stderr >> llvm-config: error: missing: /usr/lib/libLLVMDemangle.so >> llvm-config: error: missing: /usr/lib/libLLVMSupport.so > [...] >> [... fifty so lines like that ...] >> llvm-config: error: missing: /usr/lib/libLLVMX86AsmParser.so >> llvm-config: error: missing: /usr/lib/libLLVMX86Disassembler.so >> thread 'main' panicked at 'command did not execute successfully: >> "/usr/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "asmparser" >> "bitreader" "bitwriter" "instrumentation" "interpreter" "ipo" "linker" "lto" >> "mcjit" "x86" >> --- >> And indeed, running the command: >> --- >> $ llvm-config --link-shared --libs >> --- >> returns the same list of errors as above, while >> --- >> $ llvm-config --libs >> --- >> returns a bunch of static libraries without errors. >> >> I think there is a switch for building shared libraries in llvm. The book was >> using it at a time, but there were problems with mesa IIRC. >> >> The switch is -DBUILD_SHARED_LIBS=ON, and the documentation still says: >> ``BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you >> want to build LLVM as a shared library, you should use the >> LLVM_BUILD_LLVM_DYLIB option.'' >> >> The book uses the LLVM_BUILD_LLVM_DYLIB option. >> > Indeed it does, but I see that I also use -DLLVM_LINK_LLVM_DYLIB=ON. > I assume that might have been in the book at some time, but it's > what I've been using without obvious problems. I'll try -DLLVM_LINK_LLVM_DYLIB=ON soon, but I wanted to let you know that rustc built with book's instructions on LLVM built with -DBUILD_SHARED_LIBS=ON. There remains to understand why Bruce has an error with libffi. There is no mention of libffi in my rust build log. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/14/2018 11:05 PM, Bruce Dubbs wrote: On 04/14/2018 08:22 PM, Ken Moffat wrote: On Sat, Apr 14, 2018 at 10:50:11PM +0100, Ken Moffat wrote: On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote: Given that one of the old issues I found suggested that the problem only happened with static libs, and that libffi is being pulled in by libclang.so when built my way, I suspect this is the cause of Bruce's failure as well as Pierre's. So, I suggest rebuilding llvm with -DLLVM_LINK_LLVM_DYLIB=ON and confirming that rustc will then build with the config.toml that is in the book. If that works, as well as changing llvm the rust build needs to mention "clang from llvm-6.0 (built with -DLLVM_LINK_LLVM_DYLIB=ON)". Will do that, and have results in the morning. Didn't take that long. I rebuilt llvm, but still get a failure: Compiling rustc_llvm v0.0.0 (file:///tmp/rustc-test/rustc-1.25.0-src/src/librustc_llvm) Finished release [optimized] target(s) in 88.40 secs Assembling stage1 compiler (x86_64-unknown-linux-gnu) Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) error: process didn't exit successfully: `/tmp/rustc-test/rustc-1.25.0-src/build/bootstrap/debug/rustc -vV` (exit code: 101) --- stdout rustc 1.25.0 binary: rustc commit-hash: unknown commit-date: unknown host: x86_64-unknown-linux-gnu release: 1.25.0 --- stderr error: couldn't load codegen backend "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: undefined symbol: ffi_type_float" thread 'main' panicked at 'command did not execute successfully: "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "12" "--release" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/tmp/rustc-test/rustc-1.25.0-src/src/libstd/Cargo.toml" "--message-format" "json" expected success, got: exit code: 101', bootstrap/compile.rs:1060:9 note: Run with `RUST_BACKTRACE=1` for a backtrace. failed to run: /tmp/rustc-test/rustc-1.25.0-src/build/bootstrap/debug/bootstrap build Build completed unsuccessfully in 0:14:36 876.1 Elapsed Time - rustc-1.25.0-src -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/14/2018 08:22 PM, Ken Moffat wrote: On Sat, Apr 14, 2018 at 10:50:11PM +0100, Ken Moffat wrote: On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote: Given that one of the old issues I found suggested that the problem only happened with static libs, and that libffi is being pulled in by libclang.so when built my way, I suspect this is the cause of Bruce's failure as well as Pierre's. So, I suggest rebuilding llvm with -DLLVM_LINK_LLVM_DYLIB=ON and confirming that rustc will then build with the config.toml that is in the book. If that works, as well as changing llvm the rust build needs to mention "clang from llvm-6.0 (built with -DLLVM_LINK_LLVM_DYLIB=ON)". Will do that, and have results in the morning. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 02:22:13AM +0100, Ken Moffat wrote: > > for the binaries, a lot of differences, mostly in size. > Attached as bindiff > I knew I'd forget. Attached now. -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap --- ONLYBIN 2018-04-15 01:55:09.045724116 +0100 +++ LINKBIN 2018-04-15 01:55:36.411731966 +0100 @@ -1,70 +1,70 @@ -38449680 bugpoint -23974352 c-index-test +450528 bugpoint +19913640 c-index-test 9 clang -> clang-6.0 5 clang++ -> clang -78155776 clang-6.0 -52740152 clang-check +38385304 clang-6.0 +26335792 clang-check 5 clang-cl -> clang 5 clang-cpp -> clang -2350072 clang-format -20694800 clang-func-mapping -26105496 clang-import-test -3249920 clang-offload-bundler -22747784 clang-refactor -21584336 clang-rename +1954608 clang-format +19521848 clang-func-mapping +22662728 clang-import-test +69568 clang-offload-bundler +21579248 clang-refactor +20409440 clang-rename 21791 git-clang-format -36919360 llc -27256848 lli -9990016 llvm-ar -2885792 llvm-as -316320 llvm-bcanalyzer -2589976 llvm-cat -11973920 llvm-cfi-verify -196600 llvm-config -3544736 llvm-cov -25986584 llvm-c-test -2998840 llvm-cvtres -2992104 llvm-cxxdump -326112 llvm-cxxfilt -2427584 llvm-diff -2046000 llvm-dis +195064 llc +490008 lli +85496 llvm-ar +25968 llvm-as +80368 llvm-bcanalyzer +32856 llvm-cat +125256 llvm-cfi-verify +71432 llvm-config +340360 llvm-cov +131592 llvm-c-test +45016 llvm-cvtres +88960 llvm-cxxdump +33304 llvm-cxxfilt +97792 llvm-diff +38384 llvm-dis 7 llvm-dlltool -> llvm-ar -26241528 llvm-dsymutil -8724632 llvm-dwarfdump -25607632 llvm-dwp -3753488 llvm-extract +345968 llvm-dsymutil +120680 llvm-dwarfdump +110136 llvm-dwp +53320 llvm-extract 7 llvm-lib -> llvm-ar -3553312 llvm-link -33127080 llvm-lto -35172528 llvm-lto2 -9569064 llvm-mc -245176 llvm-mcmarkup -2730584 llvm-modextract -279936 llvm-mt -10065240 llvm-nm -3202168 llvm-objcopy -10956784 llvm-objdump -432120 llvm-opt-report -5414616 llvm-pdbutil -1384128 llvm-profdata +72024 llvm-link +217792 llvm-lto +177176 llvm-lto2 +105808 llvm-mc +26064 llvm-mcmarkup +26584 llvm-modextract +30664 llvm-mt +137440 llvm-nm +298376 llvm-objcopy +538112 llvm-objdump +68912 llvm-opt-report +1106168 llvm-pdbutil +138408 llvm-profdata 7 llvm-ranlib -> llvm-ar -409160 llvm-rc +189872 llvm-rc 12 llvm-readelf -> llvm-readobj -4304624 llvm-readobj -8577904 llvm-rtdyld -2986632 llvm-size -3313400 llvm-split -3604088 llvm-stress -243808 llvm-strings -3427776 llvm-symbolizer +964056 llvm-readobj +95768 llvm-rtdyld +95872 llvm-size +21376 llvm-split +84648 llvm-stress +38416 llvm-strings +58488 llvm-symbolizer 2694128 llvm-tblgen -3889168 llvm-xray -4743224 obj2yaml -39672280 opt -10468400 sancov -3358304 sanstats +463880 llvm-xray +318096 obj2yaml +407424 opt +132504 sancov +29184 sanstats 53444 scan-build 4504 scan-view -3207656 verify-uselistorder -1611968 yaml2obj +69960 verify-uselistorder +168088 yaml2obj -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sat, Apr 14, 2018 at 10:50:11PM +0100, Ken Moffat wrote:
> On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote:
> >
> > thread 'main' panicked at 'command did not execute successfully:
> > "/usr/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "asmparser"
> > "bitreader" "bitwriter" "instrumentation" "interpreter" "ipo" "linker" "lto"
> > "mcjit" "x86"
[...]
> >
> > The book uses the LLVM_BUILD_LLVM_DYLIB option.
> >
> Indeed it does, but I see that I also use -DLLVM_LINK_LLVM_DYLIB=ON.
> I assume that might have been in the book at some time, but it's
> what I've been using without obvious problems.
> Sorry to offer that different suggestion after you have gone to bed.
>
> I'll try a couple of manual DESTDIR llvm builds to confirm what gets
> installed, including clang and compiler-rt (does anybody know of
> anything that actually needs compiler-rt, I don't bother building it
> on all machines and so far nothing seems to need it ?).
>
Now completed, the book's version DESTDIR'd to BUILDONLY, the one
with added -DLLVM_LINK_LLVM_DYLIB=ON to BUILDLINK.
ken@origin /scratch/ken $du -sh BUILD*
588MBUILDLINK
1.2GBUILDONLY
TRying to get only the important things into listings (size, name,
and symlink details) so that I can diff them:
ls -l BUILDONLY/usr/bin | awk '{ print $5 " " $9 " " $10 " " $11 }' >ONLYBIN
ditto for BUILDLINK to LINKBIN
similarly for /usr/lib to ONLYLIB and LINKLIB
for the binaries, a lot of differences, mostly in size.
Attached as bindiff
Comparing ldd output for the first file, bugpoint, the BUILDONLY
version (i.e. what is in the book) lacks
libLLVM-6.0.so => /scratch/ken/BUILDLINK/usr/bin/../lib/libLLVM-6.0.so
(0x7f20c8697000)
libffi.so.6 => /usr/lib/libffi.so.6 (0x7f20c7586000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x7f20c6987000)
libicui18n.so.60 => /usr/lib/libicui18n.so.60 (0x7f20c64d9000)
libicuuc.so.60 => /usr/lib/libicuuc.so.60 (0x7f20c611b000)
libicudata.so.60 => /usr/lib/libicudata.so.60 (0x7f20c4573000)
liblzma.so.5 => /lib/liblzma.so.5 (0x7f20c434d000)
Diffing the contents of /usr/lib (but not its subdirectories) only
shows differences in size for libclang.so.6.0 and libLTO.so.6.0.0
Comparing the ldd output for libclang.so.6.0 shows a similar
difference, i.e. it pulls in libLLVM, libffi, libxml2, libicu*,
liblzma.
Given that one of the old issues I found suggested that the problem
only happened with static libs, and that libffi is being pulled in
by libclang.so when built my way, I suspect this is the cause of
Bruce's failure as well as Pierre's.
So, I suggest rebuilding llvm with -DLLVM_LINK_LLVM_DYLIB=ON and
confirming that rustc will then build with the config.toml that is
in the book.
If that works, as well as changing llvm the rust build needs to
mention "clang from llvm-6.0 (built with
-DLLVM_LINK_LLVM_DYLIB=ON)".
NB I haven't built the docs or run the tests, so I don't have a view
on the space used by llvm built like this, except that it will be
smaller. I blew away the initial source from building like the
book, but building my way the source is 1.7GB (1740 MB) and the
DESTDIR is 588 MB (2.3 GB). Interestingly, for the book's build I'm
at 1740+1142 (2.8 GB).
ĸen
--
In my seventh decade astride this planet, and as my own cells degrade,
there are some things I cannot do now: skydiving, marathon running,
calculus. I couldn't do them in my 20s either, so no big loss.
-- Derek Smalls, formerly of Spinal Tap
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sat, Apr 14, 2018 at 11:35:56AM -0500, Bruce Dubbs wrote: > On 04/14/2018 11:20 AM, Ken Moffat wrote: > > On Fri, Apr 13, 2018 at 11:38:26PM -0500, Bruce Dubbs wrote: > > > > There was a suggestion from several years ago that this used to > > happen if _static_ llvm libs were used. Latest issue was > > https://github.com/rust-lang/rust/issues/39880 but that should have > > been fixed. > > I have not removed the static clang libraries. > > > I don't know why I didn't get the libffi problem (building > > on 8.2 and newer). > > I don't know if it makes a difference, but I have: > > $ ls -l /usr/lib/clang/* -d > drwxr-xr-x 4 root root 4096 Feb 18 13:34 /usr/lib/clang/5.0.1 > drwxr-xr-x 4 root root 4096 Mar 26 17:21 /usr/lib/clang/6.0.0 > I have similar. And on investigation I have not hidden the static libs (maybe I should, just to see what other pain I can get from rust) - they are a bit further down than I care about (usually only static libs in /usr/lib or in /opt/*/lib for qt and kde). Will reply to my previous post after doing the two DESTDIR installs, but I suspect that might be a separate issue. ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote: > > >> > >> Do we need to adjust the book's instructions? > >> > > > > I'd say not before understanding what is going on... Let me try building > > rust > > with the new instructions, after installing llvm 6, and removing completely > > llvm 5 (using porg). > > > > And then... Another error on my side: > - > [...] > cargo:rustc-link-search=native=/sources/rust/rustc-1.25.0-src/build/x86_64-unkno > wn-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-7878 > f9d37a1306fb/out > > --- stderr > llvm-config: error: missing: /usr/lib/libLLVMDemangle.so > llvm-config: error: missing: /usr/lib/libLLVMSupport.so [...] > [... fifty so lines like that ...] > llvm-config: error: missing: /usr/lib/libLLVMX86AsmParser.so > llvm-config: error: missing: /usr/lib/libLLVMX86Disassembler.so > thread 'main' panicked at 'command did not execute successfully: > "/usr/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "asmparser" > "bitreader" "bitwriter" "instrumentation" "interpreter" "ipo" "linker" "lto" > "mcjit" "x86" > --- > And indeed, running the command: > --- > $ llvm-config --link-shared --libs > --- > returns the same list of errors as above, while > --- > $ llvm-config --libs > --- > returns a bunch of static libraries without errors. > > I think there is a switch for building shared libraries in llvm. The book was > using it at a time, but there were problems with mesa IIRC. > > The switch is -DBUILD_SHARED_LIBS=ON, and the documentation still says: > ``BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you > want to build LLVM as a shared library, you should use the > LLVM_BUILD_LLVM_DYLIB option.'' > > The book uses the LLVM_BUILD_LLVM_DYLIB option. > Indeed it does, but I see that I also use -DLLVM_LINK_LLVM_DYLIB=ON. I assume that might have been in the book at some time, but it's what I've been using without obvious problems. This is my only machine which currently has 6.0 (5.0.1 seems to be good enough) and for the above commands I get: ken@origin /sources/scripts/lfs-dev/git $llvm-config --version 6.0.0 ken@origin /sources/scripts/lfs-dev/git $llvm-config --libs -lLLVM-6.0 ken@origin /sources/scripts/lfs-dev/git $llvm-config --link-shared --libs -lLLVM-6.0 I very rarely remove the static libs, I just rename them so that I have to take special measures to make them available (needed for e.g. some of kde). I have ls -l /usr/lib/libLLVM* lrwxrwxrwx 1 root root 14 Mar 28 04:26 /usr/lib/libLLVM-5.0.1.so -> libLLVM-5.0.so -rwxr-xr-x 1 root root 45474200 Mar 28 04:21 /usr/lib/libLLVM-5.0.so lrwxrwxrwx 1 root root 14 Apr 10 00:56 /usr/lib/libLLVM-6.0.0.so -> libLLVM-6.0.so -rwxr-xr-x 1 root root 49620320 Apr 10 00:53 /usr/lib/libLLVM-6.0.so -rw-r--r-- 1 root root 812692 Apr 10 00:29 /usr/lib/libLLVMAMDGPUAsmParser.a.hidden -rw-r--r-- 1 root root 320266 Apr 10 00:29 /usr/lib/libLLVMAMDGPUAsmPrinter.a.hidden [...] -rw-r--r-- 1 root root 182332 Apr 10 00:12 /usr/lib/libLLVMDemangle.a.hidden [...] lrwxrwxrwx 1 root root 14 Apr 10 00:56 /usr/lib/libLLVM.so -> libLLVM-6.0.so -rw-r--r-- 1 root root 2904212 Apr 10 00:13 /usr/lib/libLLVMSupport.a.hidden [...] -rw-r--r-- 1 root root 1053706 Apr 10 00:51 /usr/lib/libLLVMX86AsmParser.a.hidden [...] -rw-r--r-- 1 root root 1503248 Apr 10 00:51 /usr/lib/libLLVMX86Disassembler.a.hidden So, I think -DLLVM_LINK_LLVM_DYLIB=ON is probably the difference. > So: three persons; three different outcomes... > > Let me rebuild llvm with -DBUILD_SHARED_LIBS=ON. I'll give the results > tomorrow (my time), since llvm+rustc build time ~ 3 hours, and I'll be > sleeping when it ends. > > Pierre > Sorry to offer that different suggestion after you have gone to bed. I'll try a couple of manual DESTDIR llvm builds to confirm what gets installed, including clang and compiler-rt (does anybody know of anything that actually needs compiler-rt, I don't bother building it on all machines and so far nothing seems to need it ?). ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
> So: three persons; three different outcomes...
Most likely 4 differents outcome by tomorrow, I'll be getting a 2010 model Mac
Pro, with, I think, a
6 core nehalem as a minimum which will heat the place compiling software under
travis-ci (https://gi
thub.com/travis-ci/travis-ci ) or something similar. It'll be dedicated to
{A,B,}LFS only and
compile 24/7 unattended.
Alain
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 14/04/2018 19:18, Pierre Labastie wrote: > On 14/04/2018 18:18, Bruce Dubbs wrote: >> On 04/13/2018 11:38 PM, Bruce Dubbs wrote: >>> Using the new instructions in the book O could not get rustc to build. I was >>> getting: >>> >>> --- stderr >>> error: couldn't load codegen backend >>> "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": >>> "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: >>> undefined symbol: ffi_type_float" >>> >>> === >>> >>> Note: ffi_type_float is defined as a symbol in libffi.so. >>> >>> >> >> Do we need to adjust the book's instructions? >> > > I'd say not before understanding what is going on... Let me try building rust > with the new instructions, after installing llvm 6, and removing completely > llvm 5 (using porg). > And then... Another error on my side: - [...] cargo:rustc-link-search=native=/sources/rust/rustc-1.25.0-src/build/x86_64-unkno wn-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-7878 f9d37a1306fb/out --- stderr llvm-config: error: missing: /usr/lib/libLLVMDemangle.so llvm-config: error: missing: /usr/lib/libLLVMSupport.so llvm-config: error: missing: /usr/lib/libLLVMBinaryFormat.so llvm-config: error: missing: /usr/lib/libLLVMCore.so llvm-config: error: missing: /usr/lib/libLLVMAsmParser.so llvm-config: error: missing: /usr/lib/libLLVMBitReader.so llvm-config: error: missing: /usr/lib/libLLVMMC.so llvm-config: error: missing: /usr/lib/libLLVMMCParser.so llvm-config: error: missing: /usr/lib/libLLVMObject.so [... fifty so lines like that ...] llvm-config: error: missing: /usr/lib/libLLVMX86AsmParser.so llvm-config: error: missing: /usr/lib/libLLVMX86Disassembler.so thread 'main' panicked at 'command did not execute successfully: "/usr/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "asmparser" "bitreader" "bitwriter" "instrumentation" "interpreter" "ipo" "linker" "lto" "mcjit" "x86" --- And indeed, running the command: --- $ llvm-config --link-shared --libs --- returns the same list of errors as above, while --- $ llvm-config --libs --- returns a bunch of static libraries without errors. I think there is a switch for building shared libraries in llvm. The book was using it at a time, but there were problems with mesa IIRC. The switch is -DBUILD_SHARED_LIBS=ON, and the documentation still says: ``BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option.'' The book uses the LLVM_BUILD_LLVM_DYLIB option. So: three persons; three different outcomes... Let me rebuild llvm with -DBUILD_SHARED_LIBS=ON. I'll give the results tomorrow (my time), since llvm+rustc build time ~ 3 hours, and I'll be sleeping when it ends. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/14/2018 12:24 PM, Alain Toussaint wrote: Le samedi 14 avril 2018 à 19:18 +0200, Pierre Labastie a écrit : On 14/04/2018 18:18, Bruce Dubbs wrote: On 04/13/2018 11:38 PM, Bruce Dubbs wrote: When I removed the line llvm-config = "/usr/bin/llvm-config" from config.toml, it seem to work (still building, but past the problem area.) The build completed and everything seems OK. I do not know why rustc does not like my version of clang. $ clang --version clang version 6.0.0 (tags/RELEASE_600/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Do we need to adjust the book's instructions? I'd say not before understanding what is going on... Let me try building rust with the new instructions, after installing llvm 6, and removing completely llvm 5 (using porg). Pierre I have a nearly ready made system done with llvm 6 and rust 1.22.1: root [ ~ ]# llvm-config --version 6.0.0 root [ ~ ]# rust rustc rustdocrust-gdb rust-lldb root [ ~ ]# rustc --version rustc 1.22.1 root [ ~ ]# I can try to build rust 1.25 and report back but are there any pitfall of doing so when rust 1.22.1 is installed? That would be helpful. The more people that do this, the more confident we can be with the instructions. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
Le samedi 14 avril 2018 à 19:18 +0200, Pierre Labastie a écrit : > On 14/04/2018 18:18, Bruce Dubbs wrote: > > On 04/13/2018 11:38 PM, Bruce Dubbs wrote: > > > Using the new instructions in the book O could not get rustc to build. I > > > was > > > getting: > > > > > > --- stderr > > > error: couldn't load codegen backend > > > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64- > > > unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": > > > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64- > > > unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: > > > undefined symbol: ffi_type_float" > > > > > > === > > > > > > Note: ffi_type_float is defined as a symbol in libffi.so. > > > > > > > > > When I removed the line > > > > > > llvm-config = "/usr/bin/llvm-config" > > > > > > from config.toml, it seem to work (still building, but past the problem > > > area.) > > > > The build completed and everything seems OK. I do not know why rustc does > > not > > like my version of clang. > > > > $ clang --version > > clang version 6.0.0 (tags/RELEASE_600/final) > > Target: x86_64-unknown-linux-gnu > > Thread model: posix > > InstalledDir: /usr/bin > > > > Do we need to adjust the book's instructions? > > > > I'd say not before understanding what is going on... Let me try building rust > with the new instructions, after installing llvm 6, and removing completely > llvm 5 (using porg). > > Pierre > I have a nearly ready made system done with llvm 6 and rust 1.22.1: root [ ~ ]# llvm-config --version 6.0.0 root [ ~ ]# rust rustc rustdocrust-gdb rust-lldb root [ ~ ]# rustc --version rustc 1.22.1 root [ ~ ]# I can try to build rust 1.25 and report back but are there any pitfall of doing so when rust 1.22.1 is installed? Alain -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 14/04/2018 18:18, Bruce Dubbs wrote: > On 04/13/2018 11:38 PM, Bruce Dubbs wrote: >> Using the new instructions in the book O could not get rustc to build. I was >> getting: >> >> --- stderr >> error: couldn't load codegen backend >> "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": >> "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: >> undefined symbol: ffi_type_float" >> >> === >> >> Note: ffi_type_float is defined as a symbol in libffi.so. >> >> >> When I removed the line >> >> llvm-config = "/usr/bin/llvm-config" >> >> from config.toml, it seem to work (still building, but past the problem >> area.) > > The build completed and everything seems OK. I do not know why rustc does not > like my version of clang. > > $ clang --version > clang version 6.0.0 (tags/RELEASE_600/final) > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > > Do we need to adjust the book's instructions? > I'd say not before understanding what is going on... Let me try building rust with the new instructions, after installing llvm 6, and removing completely llvm 5 (using porg). Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sat, Apr 14, 2018 at 11:18:06AM -0500, Bruce Dubbs wrote: > > The build completed and everything seems OK. I do not know why rustc does > not like my version of clang. > > $ clang --version > clang version 6.0.0 (tags/RELEASE_600/final) > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > > Do we need to adjust the book's instructions? > > -- Bruce As for any reported problem, potentially yes. I'm just going out now, I'll take a look later at my newest system to see if I an gain any insights. All that I have found since my previous reply is that the problem is only if system llvm has the -D flag to enable FFI: but I checked my llvm script in git blame and I've been building like that for years. ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/14/2018 11:20 AM, Ken Moffat wrote: On Fri, Apr 13, 2018 at 11:38:26PM -0500, Bruce Dubbs wrote: Using the new instructions in the book O could not get rustc to build. I was getting: --- stderr error: couldn't load codegen backend "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: undefined symbol: ffi_type_float" === Note: ffi_type_float is defined as a symbol in libffi.so. When I removed the line llvm-config = "/usr/bin/llvm-config" from config.toml, it seem to work (still building, but past the problem area.) With that change, it should be building its shipped llvm. If you have a log, you should see something like: Compiling rustc-main v0.0.0 (file:///scratch/working/rustc-1.25.0-src/src/rustc) Finished release [optimized] target(s) in 458.11 secs Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) Building LLVM for x86_64-unknown-linux-gnu running: "cmake" "/scratch/working/rustc-1.25.0-src/src/llvm" "-DLLVM_ENABLE_ASSERTIONS=OFF" "-DLLVM_TARGETS_TO_BUILD=X86" "-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly" "-DLLVM_INCLUDE_EXAMPLES=OFF" "-DLLVM_INCLUDE_TESTS=OFF" "-DLLVM_INCLUDE_DOCS=OFF" "-DLLVM_ENABLE_ZLIB=OFF" "-DWITH_POLLY=OFF" "-DLLVM_ENABLE_TERMINFO=OFF" "-DLLVM_ENABLE_LIBEDIT=OFF" "-DLLVM_PARALLEL_COMPILE_JOBS=4" "-DLLVM_TARGET_ARCH=x86_64" "-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-linux-gnu" "-DLLVM_LINK_LLVM_DYLIB=ON" "-DCMAKE_C_COMPILER=cc" "-DCMAKE_CXX_COMPILER=c++" "-DCMAKE_C_FLAGS=-ffunction-sections -fdata-sections -fPIC -march=native -m64" "-DCMAKE_CXX_FLAGS=-ffunction-sections -fdata-sections -fPIC -march=native -m64" "-DCMAKE_INSTALL_PREFIX=/scratch/working/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/llvm" "-DCMAKE_BUILD_TYPE=Release" -- The C compiler identification is GNU 7.3.0 Yes, I have that. I can only find old references on this. I think arch used to have something, but their current build seems to use the shipped llvm (they force ninja, which will only be used by cmake, i.e. building llvm). There was a suggestion from several years ago that this used to happen if _static_ llvm libs were used. Latest issue was https://github.com/rust-lang/rust/issues/39880 but that should have been fixed. I have not removed the static clang libraries. I don't know why I didn't get the libffi problem (building on 8.2 and newer). I don't know if it makes a difference, but I have: $ ls -l /usr/lib/clang/* -d drwxr-xr-x 4 root root 4096 Feb 18 13:34 /usr/lib/clang/5.0.1 drwxr-xr-x 4 root root 4096 Mar 26 17:21 /usr/lib/clang/6.0.0 -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Fri, Apr 13, 2018 at 11:38:26PM -0500, Bruce Dubbs wrote: > Using the new instructions in the book O could not get rustc to build. I was > getting: > > --- stderr > error: couldn't load codegen backend > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": > > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: > undefined symbol: ffi_type_float" > > === > > Note: ffi_type_float is defined as a symbol in libffi.so. > > > When I removed the line > > llvm-config = "/usr/bin/llvm-config" > > from config.toml, it seem to work (still building, but past the problem > area.) > With that change, it should be building its shipped llvm. If you have a log, you should see something like: Compiling rustc-main v0.0.0 (file:///scratch/working/rustc-1.25.0-src/src/rustc) Finished release [optimized] target(s) in 458.11 secs Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) Building LLVM for x86_64-unknown-linux-gnu running: "cmake" "/scratch/working/rustc-1.25.0-src/src/llvm" "-DLLVM_ENABLE_ASSERTIONS=OFF" "-DLLVM_TARGETS_TO_BUILD=X86" "-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly" "-DLLVM_INCLUDE_EXAMPLES=OFF" "-DLLVM_INCLUDE_TESTS=OFF" "-DLLVM_INCLUDE_DOCS=OFF" "-DLLVM_ENABLE_ZLIB=OFF" "-DWITH_POLLY=OFF" "-DLLVM_ENABLE_TERMINFO=OFF" "-DLLVM_ENABLE_LIBEDIT=OFF" "-DLLVM_PARALLEL_COMPILE_JOBS=4" "-DLLVM_TARGET_ARCH=x86_64" "-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-linux-gnu" "-DLLVM_LINK_LLVM_DYLIB=ON" "-DCMAKE_C_COMPILER=cc" "-DCMAKE_CXX_COMPILER=c++" "-DCMAKE_C_FLAGS=-ffunction-sections -fdata-sections -fPIC -march=native -m64" "-DCMAKE_CXX_FLAGS=-ffunction-sections -fdata-sections -fPIC -march=native -m64" "-DCMAKE_INSTALL_PREFIX=/scratch/working/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/llvm" "-DCMAKE_BUILD_TYPE=Release" -- The C compiler identification is GNU 7.3.0 I can only find old references on this. I think arch used to have something, but their current build seems to use the shipped llvm (they force ninja, which will only be used by cmake, i.e. building llvm). There was a suggestion from several years ago that this used to happen if _static_ llvm libs were used. Latest issue was https://github.com/rust-lang/rust/issues/39880 but that should have been fixed. I don't know why I didn't get the libffi problem (building on 8.2 and newer). ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/13/2018 11:38 PM, Bruce Dubbs wrote: Using the new instructions in the book O could not get rustc to build. I was getting: --- stderr error: couldn't load codegen backend "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: undefined symbol: ffi_type_float" === Note: ffi_type_float is defined as a symbol in libffi.so. When I removed the line llvm-config = "/usr/bin/llvm-config" from config.toml, it seem to work (still building, but past the problem area.) The build completed and everything seems OK. I do not know why rustc does not like my version of clang. $ clang --version clang version 6.0.0 (tags/RELEASE_600/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Do we need to adjust the book's instructions? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
