Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenGL 3.2 symbol breaks install on legacy macOS #152

Open
Zweihorn opened this issue Jan 2, 2023 · 6 comments
Open

OpenGL 3.2 symbol breaks install on legacy macOS #152

Zweihorn opened this issue Jan 2, 2023 · 6 comments

Comments

@Zweihorn
Copy link

Zweihorn commented Jan 2, 2023

This Issue found great help by teamwork from both the combined MT community and MacPorts community.

This Issue became closed and was made obsolete by macports/macports-ports#17241

help wanted

Needs help for technical support and expertise on legacy OpenGL for Minetest with IrrlichtMT.

Any advice and/or some technical expert with knowledge of legacy OpenGL would be highly welcome.

Description

Unfortunately, the "irrlichtmt" port fails to install on Mac OS 10.6 with MacPorts including but not limited to the "minetest" port. Currently, it appears difficult to determine particularly when GL_TEXTURE_CUBE_MAP_SEAMLESS was added to Mac OS X. This symbol was added in OpenGL 3.2 supposedly in the longer past.

Apparently, this needs a workaround to support the legacy MacOS X 10.6 platform if possible.

Background

This is raised to find some help for technical support aiming at the benefit to Mac OS X 10.6 Snow Leopard users for hopefully soon again enjoying the Minetest game as a "minetest" port user experience.

Please note:

  • At MacPorts the "irrlichtmt " port is long standing and integrates very well into the "minetest" port as dependency.
  • The one liner sudo port install minetest will just install both and more ports seamlessly.

However, I am not the maintainer of the "irrlichtmt " port, but would like to raise this issue to promote a more seamless user experience for a much legacy platforms as reasonably possible.

Again, any advice and/or some technical expert with knowledge of legacy OpenGL would be welcome.

Ref ce0d29d#commitcomment-94815069
Ref https://trac.macports.org/ticket/66439

@Zweihorn
Copy link
Author

Zweihorn commented Jan 2, 2023

Last not least, in general (and parallel in being the maintainer of the a.m. "minetest" port) I am quite happy with both the IrrLichtMT fork for Minetest and the excellent quality of the MT core code in particular.

@sfan5 sfan5 changed the title legacy OpenGL breaks install OpenGL 3.2 symbol breaks install on legacy macOS Jan 2, 2023
@sfan5
Copy link
Member

sfan5 commented Jan 2, 2023

IrrlichtMt supports OpenGL 1.4 and newer but requires reasonably up-to-date OpenGL headers to build (actual support is checked at runtime), which you can get from Khronos.
Irrlicht used to bundle these headers but we no longer do to simplify maintenance.

Alternatively if it's just this symbol you can try to #define GL_TEXTURE_CUBE_MAP_SEAMLESS 0x884F somewhere.

@Zweihorn
Copy link
Author

Zweihorn commented Jan 7, 2023

Found two header files which solved this issue and the arm64 issue on top. Good catch thanks to @sfan5

The combined build and install by 'minetest' rev 2 has no problems with the new & amended 'irrlichtmt' API and 'minetest' was installed without any error.

ref macports/macports-ports#17153 (comment)
ref #17161

@Zweihorn Zweihorn closed this as completed Jan 7, 2023
@Zweihorn
Copy link
Author

Zweihorn commented Jan 7, 2023

Zweihorn added a commit to Zweihorn/macports-ports that referenced this issue Jan 7, 2023
* backport fixes to irrlicht 1.9.0mt8

* amend MT 5.6.1 rev2
  * introduce new variants: [+]GLES, benchmark, debug, gprof, noclient, psql, server
  * fix minetest/irrlicht#152

* introduce irrlichtmt rev1
  * Fix01: irrlichtmt fails to install on Mac OS 10.6 <https://trac.macports.org/ticket/66439>
  * Fix02: minetest arm64 support <https://trac.macports.org/ticket/66600>
@Zweihorn Zweihorn reopened this Jan 8, 2023
@sfan5
Copy link
Member

sfan5 commented Feb 17, 2024

FYI possibly fixed by #276.

@eddieh
Copy link

eddieh commented Mar 13, 2024

The GL loader seems to assume OpenGL 3. It doesn't do a compile time or runtime check from what I can tell. At the end of GL.LoadAllProcedures it does GetIntegerv(NUM_EXTENSIONS, &ext_count); which sets the GL error to GL_INVALID_ENUM. As GL_NUM_EXTENSIONS is GL3+ only.

After that the base driver calls GL.DebugMessageCallback(debugCb, this); but DebugMessageCallback never gets a valid procedure address since it isn't available until GL3+. This causes a crash.

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

No branches or pull requests

3 participants