Re: [blfs-dev] rustc-1.25

2018-04-15 Thread Alain Toussaint

> 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

2018-04-15 Thread Ken Moffat
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

2018-04-15 Thread Ken Moffat
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

2018-04-15 Thread Bruce Dubbs

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

2018-04-15 Thread Ken Moffat
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

2018-04-15 Thread Ken Moffat
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

2018-04-15 Thread Bruce Dubbs

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

2018-04-15 Thread Pierre Labastie
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

2018-04-15 Thread Ken Moffat
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

2018-04-15 Thread Ken Moffat
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

2018-04-15 Thread Bruce Dubbs

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

2018-04-15 Thread Ken Moffat
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

2018-04-15 Thread Bruce Dubbs

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

2018-04-15 Thread Ken Moffat
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

2018-04-15 Thread Ken Moffat
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

2018-04-15 Thread Bruce Dubbs

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

2018-04-15 Thread balducci
> 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

2018-04-15 Thread Alain Toussaint

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

2018-04-15 Thread Bruce Dubbs

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

2018-04-15 Thread balducci
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

2018-04-15 Thread Alain Toussaint
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: 

Re: [blfs-dev] rustc-1.25

2018-04-15 Thread Pierre Labastie
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

2018-04-15 Thread Pierre Labastie
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

2018-04-14 Thread Bruce Dubbs

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

2018-04-14 Thread Bruce Dubbs

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

2018-04-14 Thread Ken Moffat
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

2018-04-14 Thread Ken Moffat
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

2018-04-14 Thread Ken Moffat
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

2018-04-14 Thread Ken Moffat
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

2018-04-14 Thread Alain Toussaint

> 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

2018-04-14 Thread Pierre Labastie
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

2018-04-14 Thread Bruce Dubbs

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

2018-04-14 Thread Alain Toussaint
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

2018-04-14 Thread Pierre Labastie
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

2018-04-14 Thread Ken Moffat
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

2018-04-14 Thread Bruce Dubbs

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

2018-04-14 Thread Ken Moffat
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

2018-04-14 Thread Bruce Dubbs

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