Skip to content

MSYS2 Mingw64 compilation#78

Closed
fbosche wants to merge 2 commits into
IfcOpenShell:masterfrom
fbosche:master
Closed

MSYS2 Mingw64 compilation#78
fbosche wants to merge 2 commits into
IfcOpenShell:masterfrom
fbosche:master

Conversation

@fbosche

@fbosche fbosche commented May 29, 2016

Copy link
Copy Markdown

Compiling IfcOpenShell using MSYS2 shell and mingw64 toolchain.
Some of the changes were suggested to me by some of the members here. There is one I created that 'works' but could be incorrect. This is the change to ColladaSerializer.cpp. Could it be due to the version of boost used in MSYS2 (1.60)?
For make, I encountered various issues for which work-arounds are listed here

  • when compiling IfcParse.cpp:
    • Problem: error: 'locale_t' does not name a type
    • Solution: add the proposed code covering the MINGW64 case.
  • when compiling ColladaSerializer.cpp:
    • Problem: no matching function for call to 'COLLADASW::Scene::Scene(COLLADASW::StreamWriter*&, COLLADASW::URI)' COLLADASW::Scene scene (mSW, COLLADASW::URI ("#" + scene_id));
    • Solution: add COLLADASW::URI ("#" + scene_id) as 3rd parameter of COLLADASW::Scene scene (); (same as 2nd parameter).
  • when compiling IfcGeomServer.cpp:
  • Error: error: no matching function for call to 'std::basic_ostream<char>::setf(const openmode&)'
  • Solution: change !defined(__CYGWIN__) to defined(__CYGWIN__) on line 30 of IfcGeomServer.cpp (note that removing it entirely didn't work).

Note: I only tried compilation for IFC2x3. I also didn't build IfcMax nor shared libraries.

Note: when compiling IfcGeomFunctions.cpp, I got the following message. I don't know if it is specific to compilation with MSYS2 though:
C:/msys64/IfcOpenShell/src/ifcgeom/IfcGeomFunctions.cpp:139:2: warning: #warning "You are linking against linking against an older version of Open CASCADE. Version 6.9.0 introduces various improvements with relation to boolean operations. You are advised to upgrade." [-Wcpp]

Fredounet added 2 commits May 28, 2016 09:43
…ing but the following:

- IFC4 (only IFC2x3 tried; should work)
- VLD
- IfcMax
- shared libraries
@aothms

aothms commented May 31, 2016

Copy link
Copy Markdown
Member

Thanks much. I will have a look and get back to you. As for the COLLADASW::Scene::Scene(), it seems you were unlucky enough to catch this moment in the OpenCollada repository. This was actually addressed by me some time ago: KhronosGroup/OpenCOLLADA@42fef78

@fbosche

fbosche commented May 31, 2016

Copy link
Copy Markdown
Author

Thanks for the openCollada link. Indeed, it would solve the problem.

Fred-


Dr. Frédéric Bosché
Associate Professor
Heriot-Watt University | School of Energy, Geoscience, Infrastructure and Society
RAE Centre of Excellence in Sustainable Building Design
Associate Editor of the international journal of Automation in Constructionhttp://www.journals.elsevier.com/automation-in-construction/.
Tel: +44 (0)131 451 4659
Web: http://web.sbe.hw.ac.uk/fbosche/ (CyberBuild Lab)

Heriot-Watt Univeristy Construction Project Management and Quantity Surveyinghttp://www.hw.ac.uk/schools/energy-geoscience-infrastructure-society/undergraduate/cpmqs.htm – Ranked #1 in Scotland and #3 in UK (NSS 2015)

From: Thomas Krijnen [mailto:notifications@github.com]
Sent: 31 May 2016 16:59
To: IfcOpenShell/IfcOpenShell IfcOpenShell@noreply.github.com
Cc: Bosche, Frederic N F.N.Bosche@hw.ac.uk; Author author@noreply.github.com
Subject: Re: [IfcOpenShell/IfcOpenShell] MSYS2 Mingw64 compilation (#78)

Thanks much. I will have a look and get back to you. As for the COLLADASW::Scene::Scene(), it seems you were unlucky enough to catch this moment in the OpenCollada repository. This was actually addressed by me some time ago: KhronosGroup/OpenCOLLADA@42fef78KhronosGroup/OpenCOLLADA@42fef78


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//pull/78#issuecomment-222734818, or mute the threadhttps://github.com/notifications/unsubscribe/AQrB2bCotSFRxvSQAa7oThKQJIsUOhbPks5qHFrKgaJpZM4IpVV_.

Founded in 1821, Heriot-Watt is a leader in ideas and solutions. With campuses and students across the entire globe we span the world, delivering innovation and educational excellence in business, engineering, design and science.

The contents of this e-mail (including any attachments) are confidential. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system.

@Stinkfist0

Copy link
Copy Markdown
Contributor

Thanks for the initial work @Fredounet. Do you happen to have any kind of build script for the dependencies or did you simply build each by hand?

@fbosche

fbosche commented May 31, 2016

Copy link
Copy Markdown
Author

With MSYS2, things are pretty simple. Everything is already built and only needs to be installed from the repository (not all packages are there in the default installation). The only thing I had to build is OCE. FOr this, I did the following (I could put this somewhere else on this website:

Using MSYS2, follow the "Building" procedure at https://github.com/tpaviot/oce/wiki/Build-%28MinGW-w64%29.
You don't need to use the bundle as all those libraries are already available under MSYS2.

For what follows, please note that I compiled with mingw64, not mingw32. So, adapt as needed. So, I installed the mingw-x86_64-toolchain and also add to install make as well as a few libraries that don't get installed by default such as boost (the command is simply pacman -S mingw-w64-x86_64_boost; apply the same for all packages missing for the compilation such as opencollada and swig, and possibly others).

For Cmake, use MSYS Makefiles, and set CMAKE_MAKE_PROGRAM to mingw64/bin/mingw32-make (but during the make stage, I had to use the command make instead; this confuses me... I must have done something wrong here, but it still worked...).
You must also add CMAKE_NEED_RESPONSE=YES to the CMakeLists file or pass to cmake. If you correct this after the error has occurred ("linking error, argument list too long"), Compilation will restart from scratch. So, I recommend adding this upfront, and not wait for the error. I recommend using cmake-gui (installed using MSYS2 and launched from its command line)

Like always with OCE, compilation takes forever (but it's a good idea to remember to use make -j4, or more if you have). But it went smoothly.

@fbosche

fbosche commented May 31, 2016

Copy link
Copy Markdown
Author

I could write a script for this, indeed. But, I always seem to experience slightly different issues. Anyways, I'll put this on my todo list.

@Stinkfist0

Copy link
Copy Markdown
Contributor

Thanks for the info.

@aothms

aothms commented Jun 5, 2016

Copy link
Copy Markdown
Member

I've created a new PR based on this #84. With some additional changes. Shuffled around the preprocessor macros a bit. The description also contains a small script. Overall building with MSYS2 is a breeze. I'll close this one and leave the other one open for feedback for a while.

@aothms aothms closed this Jun 5, 2016
Moult added a commit that referenced this pull request Jun 5, 2026
Define the boundary the Path-A web-bring-up refactor will move things
across:

- ViewportHost.h is the embedder interface — surface creation,
  framebuffer geometry, frame scheduling, quit, and notification
  callbacks (onObjectPicked, onToolModeChanged, …). Desktop hosts
  forward notifications to Q_SIGNALS; the future web host pushes
  them to JS callbacks.

- ViewportCore.{h,cpp} is the platform-agnostic render-core target.
  Empty today — the body fills in across the #78-#86 sequence as
  each Qt subsystem (matrices, vectors, strings, timers, render
  path, input) gets de-Qt'd and moved over.

- ViewportWindow now multiply-inherits ViewportHost alongside QWindow
  and implements the host overrides as thin forwarders: createSurface
  returns the cached surface_, requestFrame -> requestUpdate, quit ->
  QCoreApplication::quit, onObjectPicked -> emit objectPicked.
  Renamed the DPR accessor `dpr()` (vs `devicePixelRatio`) to avoid
  the inherited-virtual clash with QWindow's qreal-returning version.

No method movement yet — this is purely the architectural scaffold so
subsequent commits have a destination.
Moult added a commit that referenced this pull request Jun 5, 2026
Replace Qt math wrappers with Eigen across ViewportWindow, OverlayRenderer,
Federation, and the bonsai-side viewport modules. Eigen was already the
canonical type for the actually-important matrix work (InstanceCompose,
ModelGpuData, federation matrices); QVector3D/QVector4D/QMatrix4x4 were
leftover from when Qt was the path of least resistance. They offered
nothing over Eigen for our use case beyond a few graphics helpers
(lookAt / perspective / ortho) which were 30 lines to write.

Substitutions:
  QMatrix4x4 → Eigen::Matrix4f
  QVector2D  → Eigen::Vector2f
  QVector3D  → Eigen::Vector3f
  QVector4D  → Eigen::Vector4f

API rewrites:
  .lengthSquared()         → .squaredNorm()
  .length()                → .norm()
  .isNull()                → .isZero()
  .setToIdentity()         → .setIdentity()
  .constData()             → .data()
  .toVector3D()            → .head<3>()
  .inverted(&ok)           → tryInvert4f(M, out)
  Q::dotProduct(a,b)       → a.dot(b)
  Q::crossProduct(a,b)     → a.cross(b)
  QMat4x4(... row-major)   → Eigen::Map<const Matrix4f>(col-major buf)
  QMat4x4().lookAt(...)    → lookAtRH(eye, target, up)
  QMat4x4().perspective(.) → perspectiveYFovGL(fovy, aspect, n, f)
  QMat4x4().ortho(...)     → orthoGL(l, r, b, t, n, f)

Default-init divergence handled explicitly (QMatrix4x4() = identity,
QVector3D() = zero; Eigen leaves both uninitialized). Public API
(CameraState, HomeView, ViewportWindow::computeObjectAabb, the
addSectionPlaneAtSurface / pickSurfaceAt / raycast signatures) follows
through to Eigen too; bonsai-side View.cpp and Commands.cpp updated to
match.

Camera helpers (lookAtRH, perspectiveYFovGL, orthoGL, tryInvert4f)
extracted to a new CameraMath.h so OverlayRenderer's gizmo MVP and
ViewportWindow's buildViewProj share the same definitions. Federation
drops its <QVector3D> include in favour of <Eigen/Dense> (already had
the latter for the georef matrices).

Builds: desktop IfcViewerMinimal ✓, BonsaiViewer ✓, web IfcViewerWeb ✓.
Tests: 100/100 pass. Closes #78 + #79; opens the door for #80-#83.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants