Package Details: ifcopenshell-stable 0.8.5-4

Git Clone URL: https://aur.archlinux.org/ifcopenshell-stable.git (read-only, click to copy)
Package Base: ifcopenshell-stable
Description: Open source IFC library and geometry engine. Provides static libraries, python3 wrapper and blender addon.
Upstream URL: https://ifcopenshell.org/
Licenses: GPL-3.0-or-later, LGPL-3.0-or-later
Conflicts: ifcopenshell, ifcopenshell-git
Submitter: oxalin
Maintainer: oxalin
Last Packager: oxalin
Votes: 1
Popularity: 0.094248
First Submitted: 2026-01-05 18:31 (UTC)
Last Updated: 2026-10-02 05:38 (UTC)

Pinned Comments

oxalin commented on 2026-01-07 00:32 (UTC) (edited on 2026-05-01 08:32 (UTC) by oxalin)

If your system becomes unresponsive while building, let it be known that this code is memory hungry. On my system, I had to limit the number of parallel build processes to 8. Over 10 parallel build processes, it would sometime eat out all the RAM (32GB), making the system unresponsive and breaking the build.

Add "-j X" option at the end of "ninja -C build", where X is the number of parallel processes to build with.

Latest Comments

oxalin commented on 2026-10-02 05:43 (UTC)

We'll be staying to 0.8.5 for a bit. I just tested updating to 0.9.0, identified a few patches needed, but I still hit an error that seems to still be ironed out in the latest commits.

But 0.8.5 is now fixed against SWIG 4.5 and sha256sum values have been updated.

oxalin commented on 2026-10-01 23:20 (UTC)

@sjm : Thanks for flagging this out. I just tested the build process on my dev folder and I had no error. To be sure, I tested the version in AUR and it failed. A quick comparison of the patch files shows that the index numbers containt one more character than the files I had locally for some reason.

After updating the sha256sum values, I hit an error that was not there before, probably because of an updated Python component. Instead of debugging it, I just found out that a new stable version is available.

I'll be updating the package to 0.9.0 soon.

sjm commented on 2026-09-30 15:48 (UTC)

All patches except 004 are failing checksum validation.

oxalin commented on 2026-06-20 00:19 (UTC)

cgal 6.2 regression fixed.

oxalin commented on 2026-06-19 23:51 (UTC)

There is currently a regression when using cgal version 6.2 and later. The build will fail.

Please, keep (or downgrade to) cgal version 6.1.1 for now until a fix is made available.

oxalin commented on 2026-06-19 23:48 (UTC)

@willimei thank you for pointing this out.

willimei commented on 2026-06-08 13:25 (UTC)

After installing the packages the import of ifcopenshell in python failed because the python-lark-parser package is missing. Maybe you should add this package as dependency.

oxalin commented on 2026-05-01 08:33 (UTC)

@lukerb52 I just updated the version to 0.8.5 and with some updated and new patches. You should be able to compile the code without any problem. And I simply removed the "-j 8" option, but I left a comment about it.

lukerb52 commented on 2026-04-30 18:38 (UTC) (edited on 2026-04-30 19:47 (UTC) by lukerb52)

There appear to be two current build issues with this package on an up-to-date Arch/Artix toolchain.

  1. The PKGBUILD hardcodes parallel ninja jobs:

    ninja -C build -j 8

This ignores MAKEFLAGS / makepkg.conf and can easily cause OOM during compilation, especially in VMs or systems with 8–16 GB RAM. A safer option would be something configurable, e.g.:

ninja -C build -j "${NINJA_JOBS:-1}"

or otherwise respecting CMAKE_BUILD_PARALLEL_LEVEL / the user’s makepkg settings.

  1. The current 0.8.4 source also fails to compile with recent Boost/GCC. I am seeing this on Artix with GCC 15 and Boost 1.91. The error is:

    converting to 'const boost::optional<double>' from initializer list would use explicit constructor

This is not limited to one file. It affects several profile mapping files under:

src/ifcgeom/mapping/*ProfileDef.cpp

So far I have hit it in at least:

IfcCShapeProfileDef.cpp
IfcIShapeProfileDef.cpp
IfcLShapeProfileDef.cpp
IfcTShapeProfileDef.cpp
IfcUShapeProfileDef.cpp

The failures occur around profile_helper calls where entries like this are used:

{{-x,-y},{f2}}
{{x - d1,-y + d1},{f1}}
{{x1,-y + ft1}, {fe1}}
{{x,-y + d2 - dy2},{f2} }

Changing these to explicitly construct boost::optional<double> fixes the local compile errors, e.g.:

{{-x,-y}, boost::optional<double>(f2)}
{{x - d1,-y + d1}, boost::optional<double>(f1)}
{{x1,-y + ft1}, boost::optional<double>(fe1)}
{{x,-y + d2 - dy2}, boost::optional<double>(f2)}

So the package currently has both a packaging/build-control issue and a newer Boost/GCC source compatibility issue. The Boost issue appears to be a repeated pattern across multiple *ProfileDef.cpp files, not a one-off error in IfcCShapeProfileDef.cpp.

oxalin commented on 2026-01-07 00:32 (UTC) (edited on 2026-05-01 08:32 (UTC) by oxalin)

If your system becomes unresponsive while building, let it be known that this code is memory hungry. On my system, I had to limit the number of parallel build processes to 8. Over 10 parallel build processes, it would sometime eat out all the RAM (32GB), making the system unresponsive and breaking the build.

Add "-j X" option at the end of "ninja -C build", where X is the number of parallel processes to build with.