On 20/02/2019 23:07, Bruce Dubbs via blfs-dev wrote:
> On 2/20/19 3:34 PM, Douglas R. Reno via blfs-dev wrote:
>>
>> On 2/20/19 12:24 AM, Bruce Dubbs via blfs-dev wrote:
>>> On 2/19/19 10:40 PM, Douglas R. Reno via blfs-dev wrote:
>>>>
>>>> On 2/19/19 10:12 PM, Bruce Dubbs via blfs-dev wrote:
>>>>> I've run into a problem trying to validate SM and FF for 8.4,  First SM.
>>>>>
>>>>> It appears that SM prefers clang over gcc.  The build fails early because
>>>>> it uses clang by default and the sanity check fails because the CFLAGS we
>>>>> pass are incompatible with clang.
>>>>>
>>>>> I added CC=gcc CXX=g++ and SM built.  It seems to run OK, so I've added
>>>>> those variables to the book with a note that says if you want to use
>>>>> clang, don't set the flags.
>>>>>
>>>>> The problem with FF is more serious.  At the 29 minute point I get:
>>>>>
>>>>> 27:48.76    Compiling gkrust v0.1.0
>>>>> (/tmp/firefox/firefox-65.0/toolkit/library/rust)
>>>>> 29:17.59 error: Could not compile `gkrust`.
>>>>> 29:17.60 Caused by:
>>>>> ... (long command line here)
>>>>> (signal: 11, SIGSEGV: invalid memory reference)
>>>>>
>>>>> We use clang for FF so I tried gcc and got the same error.
>>>>>
>>>>> The funny thing is that I built FF a week ago with exactly the same
>>>>> instructions (the same script) on my Skylake workstation (basically a
>>>>> less complete 8.4 system) and it is fine.  My development system is a
>>>>> Haswell.  Both are running rustc 1.32.0.
>>>>>
>>>>> The only thing I could find on google is
>>>>>
>>>>> https://aur.archlinux.org/packages/icecat/?comments=all
>>>>>
>>>>> but it doesn't seem to have a solution.
>>>>>
>>>>> Any ideas?
>>>
>>>> I'm going to have to build Firefox so that I can configure CUPS probably
>>>> tonight or tomorrow. I'll get back to you with the results off that,
>>>> especially if we have the same problem.
>>>
>>> I'm beginning to think it might be a CPU HW issue, but it's mostly
>>> speculation.  Can you check it out on your Haswell?
>>>
>>>   -- Bruce
>>
>>
>> I can't confirm this with my Skylake.
>>
>>   0:20.37 make: Leaving directory
>> '/sources/firefox-65.0.1/firefox-65.0.1/firefox-build-dir'
>>   0:20.38 /usr/bin/notify-send --app-name=Mozilla Build System Mozilla Build
>> System Install complete
>> '/usr/lib/firefox/browser/plugins' -> '../../mozilla/plugins'
>> 'firefox.desktop' -> '/usr/share/applications/firefox.desktop'
>> '/usr/share/pixmaps/firefox.png' ->
>> '/usr/lib/firefox-65.0.1/browser/icons/mozicon128.png'
>> 5792.9 Elasped Time - firefox-65.0.1
>> SBU=47.482
>> 270332 /sources/firefox-65.0.1.source.tar.xz size (263.996 MB)
>> 12421704 kilobytes build size (12130.570 MB)
>> md5sum : 38c01a14e58cce894dda513739bd15d3 
>> /sources/firefox-65.0.1.source.tar.xz
>> sha1sum: 5b3a64d5c843f4e23cb3220a3211077bc58cba34
>> /sources/firefox-65.0.1.source.tar.xz
>>
>> It works fine on it.
> 
> I got it to work.  I rebuilt rustc and then FF built.
> 
> To really start over, I renamed ~/.cargo.
> 
> At first I used the wrong script and installed rust in /usr.
> 
> The original script had
> 
> 
> [llvm]
> targets = "X86"
> link-shared = true
> 
> [build]
> extended = true
> 
> [install]
> prefix = "/usr"
> docdir = "share/doc/rustc-$VER"
> 
> [rust]
> channel = "stable"
> rpath = false
> 
> codegen-tests = false
> 
> [target.x86_64-unknown-linux-gnu]
> llvm-config = "/usr/bin/llvm-config"

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is what generated the error: You used system llvm,
which is broken. That's why it was removed.

> 
> -----
> 
> The working script has
> 
> [llvm]
> ninja = true
> targets = "X86"
> experimental-targets = ""
> 
> [build]
> docs = false
> extended = true
> 
> [install]
> prefix = "/opt/rustc-$VER"
> docdir = "share/doc/rustc-$VER"
> 
> [rust]
> channel = "stable"
> rpath = false
> codegen-tests = false
> backtrace-on-ice = true
> 
> ------
> 
> The old script has a sed for Cargo.lock and did not have the option
> 
> --exclude src/tools/miri
> 
> My best guess as to the problem is the original build did not use
> ninja = true
> 
> or that it did use
> link-shared = true
> 

That could be, but the main reason is system llvm

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to