Re: error building clang in HEAD

From: Gary Jennejohn <gljennjohn_at_gmail.com>
Date: Wed, 27 Jun 2018 09:27:59 +0200
On Tue, 26 Jun 2018 12:51:29 -0700
Bryan Drewery <bdrewery_at_FreeBSD.org> wrote:

> On 6/26/2018 12:40 PM, Kevin Oberman wrote:
> > On Tue, Jun 26, 2018 at 11:00 AM, Gary Jennejohn <gljennjohn_at_gmail.com
> > <mailto:gljennjohn_at_gmail.com>> wrote:
> > 
> >     On Tue, 26 Jun 2018 18:24:12 +0200
> >     Gary Jennejohn <gljennjohn_at_gmail.com <mailto:gljennjohn_at_gmail.com>>
> >     wrote:
> >   
> >     > On Mon, 25 Jun 2018 11:28:18 -0700
> >     > Bryan Drewery <bdrewery_at_FreeBSD.org> wrote:
> >     >  
> >     > > On 6/24/2018 12:57 AM, Gary Jennejohn wrote:__  
> >     > > > On Sat, 23 Jun 2018 17:05:16 +0200
> >     > > > Dimitry Andric <dim_at_FreeBSD.org> wrote:
> >     > > >__ __ __  
> >     > > >> On 23 Jun 2018, at 15:40, Gary Jennejohn  
> >     <gljennjohn_at_gmail.com <mailto:gljennjohn_at_gmail.com>> wrote:__ __  
> >     > > >>>
> >     > > >>> There is a strange error building clang with this use case:
> >     > > >>>
> >     > > >>> cd /usr/src
> >     > > >>> make -j10 makeworld__ __ __  
> >     > > >>
> >     > > >> What's the "makeworld" target?__ I've not heard of this.
> >     > > >>__ __  
> >     > > >
> >     > > > A typo.__ I meant buildowrld.
> >     > > >__ __ __  
> >     > > >>> which produces this error output:
> >     > > >>>__ __ __ __  
> >     > > >>> ===> lib/clang/libclang (all)__ __ __  
> >     > > >>> error: unable to rename temporary  
> >     'Sema/SemaTemplate-12ad7e30.o.tmp' to output file
> >     'Sema/SemaTemplate.o': 'No such file or directory'  
> >     > > >>> 1 error generated.
> >     > > >>> --- Sema/SemaTemplate.o ---
> >     > > >>> *** [Sema/SemaTemplate.o] Error code 1__ __ __  
> >     > > >>
> >     > > >> This typically happens if "make obj" was not run before the  
> >     rest of the  
> >     > > >> make targets.__ Normally, the order is: make obj, then make  
> >     depend, then  
> >     > > >> make (a.k.a. make all).
> >     > > >>
> >     > > >> Is there a directory /usr/obj/usr/src/lib/libclang/Sema ?
> >     > > >>__ __  
> >     > > >
> >     > > > Well, I would hope/expect that make buildworld does make obj.
> >     > > >
> >     > > > Yes, the directory was there.
> >     > > >__ __ __  
> >     > >
> >     > > Actually neither 'make obj' nor 'make depend' is done or needed  
> >     anymore  
> >     > > in buildworld.
> >     > >
> >     > > The directory above is incorrect, please check for
> >     > >
> >     > >__ __ __/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/Sema
> >     > >__ __  
> >     >
> >     > Well, now everything is there because I ran a buildworld without -j.
> >     >  
> >     > > Do you have another Makefile or script that is executing
> >     > > buildworld for you?
> >     > >__ __  
> >     >
> >     > No, I use a bash alias named mw:
> >     > mw is aliased to `pushd /usr/src;time make -s -j$NCPU buildworld;popd'
> >     >
> >     > NCPU is defined as 10.
> >     >  
> >     > > What's in your src.conf and make.conf?
> >     > >__ __  
> >     >
> >     > The only changes I made recently were to /etc/src.conf when I added:
> >     >
> >     > WITHOUT_LLVM_TARGET_AARCH64=yes
> >     > WITHOUT_LLVM_TARGET_ARM=ys
> >     > WITHOUT_LLVM_TARGET_MIPS=yes
> >     > WITHOUT_LLVM_TARGET_POWERPC=yes
> >     > WITHOUT_LLVM_TARGET_SPARC=yes
> >     > WITH_LLVM_TARGET_X86=yes
> >     >
> >     > Otherwise, I haven't touched src.conf or make.conf in__ a long time.
> >     >  
> > 
> >     I removed some old cruft from src.conf and now make -j10 buildworld is
> >     succeeding, even after rm -rf /usr/obj/usr.
> > 
> >     Thanks for pointing me in the right direction.
> > 
> > I'd like to hear what triggered this as removing unneeded LLVM targets
> > seems like a good idea if you know that you won't need them. Building  
> 
> I don't think the options are related to the build error.
> 

Correct, these options were not the cause of the errors.  I had
some really old options from several years ago which were the cause.
Don't remeber now exactly which ones, but they were all related to
using CLANG instead of GCC.

-- 
Gary Jennejohn
Received on Wed Jun 27 2018 - 05:28:04 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC