search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

FTBFS: file INSTALL cannot find "/builddir/build/BUILD/lldb-9.0.0.src/clr-build/./lib64/python3.7". #42822

Open Quuxplusone opened 5 years ago

Quuxplusone commented 5 years ago
Bugzilla Link PR43852
Status NEW
Importance P enhancement
Reported by Thiago Macieira (thiago@kde.org)
Reported on 2019-10-30 11:14:13 -0700
Last modified on 2019-11-19 05:25:28 -0800
Version 9.0
Hardware PC Linux
CC jdevlieghere@apple.com, llvm-bugs@lists.llvm.org, mgorny@gentoo.org
Fixed by commit(s)
Attachments build.log.gz (66187 bytes, application/gzip)
Blocks
Blocked by
See also 
(Failure to build from source)

When building lldb 9.0.0 on Clear Linux, with Python 3.7, lldb fails to build.

Configured as:
cmake -G 'Unix Makefiles' -DBUILD_SHARED_LIBS:BOOL=ON -
DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_SBINDIR=/usr/bin -
DCMAKE_INSTALL_LIBDIR=/usr/lib64 -DLIB_INSTALL_DIR=/usr/lib64 -DLIB_SUFFIX=64 -
DCMAKE_AR=/usr/bin/gcc-ar -DCMAKE_BUILD_TYPE=RelWithDebInfo -
DCMAKE_RANLIB=/usr/bin/gcc-ranlib ..  -DLLVM_HOST_TRIPLE=x86_64-generic-linux -
DLLVM_LIBDIR_SUFFIX=64 -DLLVM_LINK_LLVM_DYLIB:BOOL=ON -
DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3

Build succeeds, but fails to install:

-- Installing: /builddir/build/BUILDROOT/lldb-9.0.0-
2.x86_64/usr/include/lldb/Host/ProcessLauncher.h
-- Up-to-date: /builddir/build/BUILDROOT/lldb-9.0.0-2.x86_64/usr/include
-- Up-to-date: /builddir/build/BUILDROOT/lldb-9.0.0-2.x86_64/usr/include/lldb
-- Up-to-date: /builddir/build/BUILDROOT/lldb-9.0.0-
2.x86_64/usr/include/lldb/Host
-- Installing: /builddir/build/BUILDROOT/lldb-9.0.0-
2.x86_64/usr/include/lldb/Host/Config.h
CMake Error at scripts/cmake_install.cmake:41 (file):
  file INSTALL cannot find
  "/builddir/build/BUILD/lldb-9.0.0.src/clr-build/./lib64/python3.7".
Call Stack (most recent call first):
  cmake_install.cmake:50 (include)

make: *** [Makefile:74: install] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.GgR7lj (%install)

Python info:

$ python -c 'import sys; print(sys.implementation); print(sys.path)'
namespace(_multiarch='x86_64-linux-gnu', cache_tag='cpython-37',
hexversion=50791920, name='cpython', version=sys.version_info(major=3, minor=7,
micro=5, releaselevel='final', serial=0))
['', '/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-
dynload', '/usr/lib/python3.7/site-packages']

Full build log attached.
Quuxplusone commented 5 years ago

It should already be fixed in trunk and 9.x branch.

Quuxplusone commented 5 years ago

Attached build.log.gz (66187 bytes, application/gzip): build log

Quuxplusone commented 5 years ago 
I'm guessing it's this one:

    ------------------------------------------------------------------------
    r366513 | lanza | 2019-07-19 01:40:23 +0200 (Fri, 19 Jul 2019) | 9 lines

    [cmake] Update NATIVE build variables to account for standalone changes

    Summary:
    LLDB_PATH_TO_{CLANG,LLVM}_BUILD were removed and replaced with
    {LLVM,Clang}_DIR. Adjust the NATIVE build to account for this.

    Subscribers: mgorny

    Differential Revision: https://reviews.llvm.org/D64959
    ------------------------------------------------------------------------

Let me give it a try.
Quuxplusone commented 5 years ago 
(In reply to Michał Górny from comment #1)
> It should already be fixed in trunk and 9.x branch.

(In reply to Thiago Macieira from comment #3)
> I'm guessing it's this one:
>
>     ------------------------------------------------------------------------
>     r366513 | lanza | 2019-07-19 01:40:23 +0200 (Fri, 19 Jul 2019) | 9 lines

Well, that isn't the one. Can you point out which one it should be? There's
apparently only one commit in branches/release_90 beyond the final release and
it's unrelated.
Quuxplusone commented 5 years ago

Actually, I think it hasn't been pushed yet. The backport request is:

https://bugs.llvm.org/show_bug.cgi?id=43442

Also, you're using the wrong repository. The correct one is:

https://github.com/llvm/llvm-project/

Quuxplusone commented 5 years ago 
(In reply to Michał Górny from comment #5)
> Actually, I think it hasn't been pushed yet.  The backport request is:
>
> https://bugs.llvm.org/show_bug.cgi?id=43442

Thanks, backport works.

> Also, you're using the wrong repository.  The correct one is:
>
> https://github.com/llvm/llvm-project/

What do you mean? git.llvm.org is not the correct repository for llvm.org?
Quuxplusone commented 5 years ago 
(In reply to Thiago Macieira from comment #6)
> > Also, you're using the wrong repository.  The correct one is:
> >
> > https://github.com/llvm/llvm-project/
>
> What do you mean? git.llvm.org is not the correct repository for llvm.org?

Yes.  That's just the old svn→git mirror and since svn isn't being updated...
Quuxplusone commented 5 years ago 
(In reply to Michał Górny from comment #7)
> (In reply to Thiago Macieira from comment #6)
> > > Also, you're using the wrong repository.  The correct one is:
> > >
> > > https://github.com/llvm/llvm-project/
> >
> > What do you mean? git.llvm.org is not the correct repository for llvm.org?
>
> Yes.  That's just the old svn→git mirror and since svn isn't being updated...

Ah, got it. Thanks. Updating my clones then.
Quuxplusone commented 5 years ago 
(In reply to Thiago Macieira from comment #8)
> (In reply to Michał Górny from comment #7)
> > (In reply to Thiago Macieira from comment #6)
> > > > Also, you're using the wrong repository.  The correct one is:
> > > >
> > > > https://github.com/llvm/llvm-project/
> > >
> > > What do you mean? git.llvm.org is not the correct repository for llvm.org?
> >
> > Yes.  That's just the old svn→git mirror and since svn isn't being
updated...
>
> Ah, got it. Thanks. Updating my clones then.

A merged repo makes for more difficult patch management for packages, though.
Now the patches I need to apply to lldb are in the same repository as the
patches for clang. And git format-patch will (by default) create files with one
dir too many (a/lldb, b/lldb) compared to the package.

Oh well, need to rewrite the scripts too then.
Quuxplusone commented 5 years ago

I know how you feel. I've spent a few hours updating all our packages in Gentoo.

Apparently the original plan presumed all those mirrors would continue to be operational but so far it doesn't seem to be happening.

Quuxplusone commented 5 years ago 
Regenerating patches like this:

git format-patch -N --src-prefix=a/tools/ --dst-prefix=b/tools/ @{u} clang
rename 00 clang-00 00*.patch
git format-patch -N --no-prefix @{u} llvm
rename 00 llvm-00 00*.patch