Package Details: python-open3d-git r2539.f3c7158a-1

Git Clone URL: (read-only, click to copy)
Package Base: open3d-git
Description: A Modern Library for 3D Data Processing
Upstream URL:
Licenses: MIT
Conflicts: python-open3d, python-py3d
Provides: python-open3d, python-py3d
Submitter: deltaecho
Maintainer: tallero
Last Packager: tallero
Votes: 4
Popularity: 0.000000
First Submitted: 2018-05-01 14:28 (UTC)
Last Updated: 2023-07-04 21:06 (UTC)

Required by (2)

Sources (2)

Latest Comments

MoRoBe commented on 2023-08-02 09:35 (UTC)

As of now, the build fails for me in the same way as described here: first on building assimp, and if I enforce cmake to use my systems assimp it fails on tbb. I do not understand enough of the build process to really contribute much but of course I'm willing to try suggestions.

emanus commented on 2022-01-25 20:56 (UTC)

The fix_3rdparty_path.patch does not work any more. Changing it to

diff --unified --recursive --text open3d/3rdparty/libjpeg-turbo/libjpeg-turbo.cmake open3d_patch/3rdparty/libjpeg-turbo/libjpeg-turbo.cmake --- open3d/3rdparty/libjpeg-turbo/libjpeg-turbo.cmake 2019-12-09 02:09:55.853560635 -0800 +++ open3d_patch/3rdparty/libjpeg-turbo/libjpeg-turbo.cmake 2019-12-09 02:09:31.837228165 -0800 @@ -69,5 +69,5 @@

ExternalProject_Get_Property(ext_turbojpeg INSTALL_DIR) set(JPEG_TURBO_INCLUDE_DIRS ${INSTALL_DIR}/include/) # "/" is critical. -set(JPEG_TURBO_LIB_DIR ${INSTALL_DIR}/${Open3D_INSTALL_LIB_DIR}) +set(JPEG_TURBO_LIB_DIR ${INSTALL_DIR}/lib64) set(JPEG_TURBO_LIBRARIES ${lib_name})

seems to work ( ). Could you please update the file and PKGBUILD?

firoz commented on 2021-10-14 14:16 (UTC)

With glibc 2.33 and LLVM/Clang 12 the config fails with the same error like in :

Could not find CPPABI_LIBRARY using the following names: c++abi

stevesp commented on 2020-02-13 09:15 (UTC)

@jgwak Thanks for fixing the dependency issue, it is working for me now.

stevesp commented on 2020-02-12 16:42 (UTC)

@jgwak A okay, thanks for the info. Was only building the master branch and that worked without a problem (only the fix_3rdparty_path.patch was necessary). So the git package is the way to go right now if you want to have the new features of 0.9.0.

I see, guess in that case it makes sense to leave them.

Your welcome, thanks for fixing it.

jgwak commented on 2020-02-12 16:00 (UTC) (edited on 2020-02-12 16:00 (UTC) by jgwak)

@stevesp There is a upstream bug blocking latest version build: Regarding the strange packaging, I am not the one who submitted this package. I recently adopted it to fix this abandoned package. I wonder the same but I decided to leave them for backward compatibility. I will fix typo and error in dependency. Thank you.

stevesp commented on 2020-02-12 10:57 (UTC)

Building the git version of open3d is not working since python-open3d-git is depending on open3d and open3d is an older version. I fixed this problem by adapting the "package_open3d-git" function to provide open3d and conflict with "open3d" instead of "open3d-git". Another possibility would be to make the python-open3d-git package dependent on open3d-git instead of open3d.

In addition, I was wondering why there is a python-py3d-git package function in the PKGBUILD which is basically the same as the python-open3d-git package function? In both of those functions, there is a typo: "privides" instead of "provides". Also, should both packages provide "python-open3d" and "python-py3d" and conflict with each other and the same package versions without git.

otaj commented on 2019-02-02 20:54 (UTC)

PKGBUILD is "out of date" - since version 0.3.0, it is required to cmake .., not cmake ../src plus it is necessary to init submodule 3rdparty, since otherwise the install fails.