Mac OS

Discussion related to the LuxCore functionality, implementations and API.
jensverwiebe
Supporting Users
Posts: 141
Joined: Tue Jan 09, 2018 6:48 pm

Re: Mac OS

Post by jensverwiebe »

Nono, in the top cmakelists.txt, line 30ff

under

Code: Select all

# Fresh start
cmake_minimum_required(VERSION 3.0)
cmake_policy(VERSION 3.0)
Later Dade can ifdef such.
patrickwalker
Posts: 28
Joined: Sun Jan 28, 2018 2:10 pm
Location: Canada

Re: Mac OS

Post by patrickwalker »

Well, a.out is usually the filename of compile code out of a C compiler so was just wondering. Might just be an option for a CC command in the script.

I added the lines to CMakeLists.txt and cmake still generates the missing pthread.h error.

(Assuming that +eventually above that was sandwiched between cmake_policy() entries isn't to be added in).
jensverwiebe
Supporting Users
Posts: 141
Joined: Tue Jan 09, 2018 6:48 pm

Re: Mac OS

Post by jensverwiebe »

patrickwalker wrote: Sun Jan 28, 2018 10:05 pm Well, a.out is usually the filename of compile code out of a C compiler so was just wondering. Might just be an option for a CC command in the script.

I added the lines to CMakeLists.txt and cmake still generates the missing pthread.h error.
Those a.out may be from the cmake compiler testrun.
TBH: this all can become a big hazzle on untested macOS version. I'am not even sure Apple
updated bison and yacc to working version in between.
You must go through this step by step.

..and sure, the proposed testing was:

Code: Select all

# Fresh start
cmake_minimum_required(VERSION 3.0)
cmake_policy(VERSION 3.0)
if(APPLE)
	cmake_policy(SET CMP0043 OLD)
	cmake_policy(SET CMP0003 NEW)
	cmake_policy(SET CMP0005 NEW)
	cmake_policy(SET CMP0010 NEW)
	cmake_policy(SET CMP0014 NEW)
endif(APPLE)
Jens
patrickwalker
Posts: 28
Joined: Sun Jan 28, 2018 2:10 pm
Location: Canada

Re: Mac OS

Post by patrickwalker »

Okay, so could the pthread.h file path be hardcoded into the cmake configuration for macOS? Not sure if this is true for any other version of Xcode but most people will have the latest one, or if they don't, they'll end up having to get the latest one from the App Store anyways.

This is the file path for it:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/pthread.h

Well, bison can be installed via Homebrew, and the current version for High Sierra is 3.0.4.1. yacc is hard linked into /usr/bin and *could* be changed by disabling CSR. Can macOS users be told to install bison using brew then set LD flags to '/usr/local/opt/bison/lib'?
jensverwiebe
Supporting Users
Posts: 141
Joined: Tue Jan 09, 2018 6:48 pm

Re: Mac OS

Post by jensverwiebe »

You can answer some questions yourself if you read the old "macos" repo documentation.
Finding threads is a module in cmake, you can lookup there if the pathes are correct.
Compile bison and yacc statically, really investigate the lux macos repo, you will see what i did there.
Disabling System Integrity Protection (SIP) is not needed, in case you need newer binaries, install to /usr/local.
This will override /usr.

Make yourself clear, its a huge task. When getting libs from homebrew or whatever thus not compile yourself,
make sure with otool that those are linked with the proper sdk ( 10.9 ideally ). I also mentioned Blender
darwin repo consists of almost all libs already in c++11 you need for luxcore.

Jens
patrickwalker
Posts: 28
Joined: Sun Jan 28, 2018 2:10 pm
Location: Canada

Re: Mac OS

Post by patrickwalker »

I did read it, I updated all dependencies that were listed in the document, the exception being embree but I remember something being said about that.

In my hopes to get this working, these are the versions currently installed:
bison (3.0.4_1)
boost (1.66.0)
freeimage (3.17.0_1)
glew (2.1.0)
OpenEXR (2.2.0)
OpenImageIO (1.7.17)
libpng (1.6.34)
libtiff (4.0.9_1)
libjpeg (9b)

When I attempt to use the cmake commands with any options, I get errors.

I just have to say that I'm at a point in my life where I have fewer days ahead of me than behind me, and I really don't want to be wasting them on the intricacies and vagaries of "software engineering." My job description doesn't really include time for that and I spent way too much of my youth wasted on computers and have no desire to repeat that. Like a car, I should be able to turn it on and use it, not rebuild it from scratch every so often.
patrickwalker
Posts: 28
Joined: Sun Jan 28, 2018 2:10 pm
Location: Canada

Re: Mac OS

Post by patrickwalker »

I erased and redownloaded everything. Managed to get GUI version of cmake generate the Xcode file, however, I'm getting errors. The root cause might be that Xcode cannot find embree2/rtcore_builder.h as referenced in bvhembreebuild.cpp.

I had hoped it was included in TBB, but I cannot find it in the usual locations. The macos block of files does seem to have all the other rtcore_* files.

Another thread had someone else with a similar missing header file issue. So, I downloaded a tar.gz and copied those header files into the luxcore source tree and seems to have cleared that problem. Unsure whether this is a proper solution and wondering how I'll pay for it later in the compilation/linking process, but it moves right on into the next error. And this error I have no clue how to handle. The only thing I can say is that CG probably means CoreGraphics but it's been six or seven years since I even did any macOS programming at all and that was using Objective-C.

Now, in the method OpenCLDeviceDescription::GetOCLContext() found in device.cpp, it is saying that CGLGetCurrentContext is an undeclared identifier.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Mac OS

Post by Dade »

patrickwalker wrote: Mon Jan 29, 2018 2:54 am I erased and redownloaded everything. Managed to get GUI version of cmake generate the Xcode file, however, I'm getting errors. The root cause might be that Xcode cannot find embree2/rtcore_builder.h as referenced in bvhembreebuild.cpp.

I had hoped it was included in TBB, but I cannot find it in the usual locations. The macos block of files does seem to have all the other rtcore_* files.
The cmake/SpecializedConfig/Config_OSX.cmake file reference Embree path with the following lines:

Code: Select all

SET(EMBREE_LIBRARY ${OSX_DEPENDENCY_ROOT}/lib/embree2/libembree.2.8.0.dylib)
You have probably only to fix the right path there and to use the latest Embree available from https://embree.github.io/downloads.html (older versions do not include the embree2/rtcore_builder.h).
patrickwalker wrote: Mon Jan 29, 2018 2:54 am Another thread had someone else with a similar missing header file issue. So, I downloaded a tar.gz and copied those header files into the luxcore source tree and seems to have cleared that problem. Unsure whether this is a proper solution and wondering how I'll pay for it later in the compilation/linking process, but it moves right on into the next error. And this error I have no clue how to handle. The only thing I can say is that CG probably means CoreGraphics but it's been six or seven years since I even did any macOS programming at all and that was using Objective-C.

Now, in the method OpenCLDeviceDescription::GetOCLContext() found in device.cpp, it is saying that CGLGetCurrentContext is an undeclared identifier.
The OpenGL/OpenCL interoperability is not even used by LuxCoreRender so if you want try to move on instead than fixing that problem, you can just comment the code:

Code: Select all

		/*if (enableOpenGLInterop) {
#if defined (__APPLE__)
			CGLContextObj kCGLContext = CGLGetCurrentContext();
			CGLShareGroupObj kCGLShareGroup = CGLGetShareGroup(kCGLContext);
			cl_context_properties cps[] = {
				CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE, (cl_context_properties)kCGLShareGroup,
				0
			};
#else
#ifdef WIN32
			cl_context_properties cps[] = {
				CL_GL_CONTEXT_KHR, (intptr_t)wglGetCurrentContext(),
				CL_WGL_HDC_KHR, (intptr_t)wglGetCurrentDC(),
				CL_CONTEXT_PLATFORM, (cl_context_properties)platform(),
				0
			};
#else
			cl_context_properties cps[] = {
				CL_GL_CONTEXT_KHR, (intptr_t)glXGetCurrentContext(),
				CL_GLX_DISPLAY_KHR, (intptr_t)glXGetCurrentDisplay(),
				CL_CONTEXT_PLATFORM, (cl_context_properties)platform(),
				0
			};
#endif
#endif
			oclContext = new cl::Context(devices, cps);
		} else {*/
			cl_context_properties cps[] = {
				CL_CONTEXT_PLATFORM, (cl_context_properties)platform(), 0
			};

			oclContext = new cl::Context(devices, cps);
		//}
P.S. the solution to the last problem is probably about adding the right "#include" header where the CGL* functions are declared on your platform.
Support LuxCoreRender project with salts and bounties
jensverwiebe
Supporting Users
Posts: 141
Joined: Tue Jan 09, 2018 6:48 pm

Re: Mac OS

Post by jensverwiebe »

patrickwalker wrote: Mon Jan 29, 2018 2:54 am I erased and redownloaded everything. Managed to get GUI version of cmake generate the Xcode file, however, I'm getting errors. The root cause might be that Xcode cannot find embree2/rtcore_builder.h as referenced in bvhembreebuild.cpp.

I had hoped it was included in TBB, but I cannot find it in the usual locations. The macos block of files does seem to have all the other rtcore_* files.

Another thread had someone else with a similar missing header file issue. So, I downloaded a tar.gz and copied those header files into the luxcore source tree and seems to have cleared that problem. Unsure whether this is a proper solution and wondering how I'll pay for it later in the compilation/linking process, but it moves right on into the next error. And this error I have no clue how to handle. The only thing I can say is that CG probably means CoreGraphics but it's been six or seven years since I even did any macOS programming at all and that was using Objective-C.

Now, in the method OpenCLDeviceDescription::GetOCLContext() found in device.cpp, it is saying that CGLGetCurrentContext is an undeclared identifier.
This looks as you are coming along in a way :)
Keep in mind macOS has changed in every iteration, so some functions could have been gone ( metal transition ).
Also always keep an eye Apple often does little special things with pathes.
I guess you setup a macos repo ? aka ${OSX_DEPENDENCY_ROOT} ? Hint: embree/tbb headers are in an embree2 subdir.
Embree libs come with symlinks so SET(EMBREE_LIBRARY ${OSX_DEPENDENCY_ROOT}/lib/embree2/libembree.2.dylib)
should do.

I can just emphasize my 2 1/2 years old osx 10.11 repo for lux c++11 is still doing fine, so it is mainly to find the
changes made in 10.13 sdk to make the last bits work.
Don't complain about lux devs for not having ootb compile, its Apple being a moving target.

I bet you will get it done asap ;) Keep on ...

Jens
patrickwalker
Posts: 28
Joined: Sun Jan 28, 2018 2:10 pm
Location: Canada

Re: Mac OS

Post by patrickwalker »

Dade wrote: Mon Jan 29, 2018 9:30 am

Code: Select all

SET(EMBREE_LIBRARY ${OSX_DEPENDENCY_ROOT}/lib/embree2/libembree.2.8.0.dylib)
So, here's where some fun begins. I did a full HDD search and it is not finding this dylib. I've gone through the usual spots and cannot find them. That error seems to have disappeared as


Dade wrote: Mon Jan 29, 2018 9:30 am The OpenGL/OpenCL interoperability is not even used by LuxCoreRender so if you want try to move on instead than fixing that problem, you can just comment the code:

Code: Select all

		/*if (enableOpenGLInterop) {
#if defined (__APPLE__)
			CGLContextObj kCGLContext = CGLGetCurrentContext();
			CGLShareGroupObj kCGLShareGroup = CGLGetShareGroup(kCGLContext);
			cl_context_properties cps[] = {
				CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE, (cl_context_properties)kCGLShareGroup,
				0
			};
#else
#ifdef WIN32
			cl_context_properties cps[] = {
				CL_GL_CONTEXT_KHR, (intptr_t)wglGetCurrentContext(),
				CL_WGL_HDC_KHR, (intptr_t)wglGetCurrentDC(),
				CL_CONTEXT_PLATFORM, (cl_context_properties)platform(),
				0
			};
#else
			cl_context_properties cps[] = {
				CL_GL_CONTEXT_KHR, (intptr_t)glXGetCurrentContext(),
				CL_GLX_DISPLAY_KHR, (intptr_t)glXGetCurrentDisplay(),
				CL_CONTEXT_PLATFORM, (cl_context_properties)platform(),
				0
			};
#endif
#endif
			oclContext = new cl::Context(devices, cps);
		} else {*/
			cl_context_properties cps[] = {
				CL_CONTEXT_PLATFORM, (cl_context_properties)platform(), 0
			};

			oclContext = new cl::Context(devices, cps);
		//}
P.S. the solution to the last problem is probably about adding the right "#include" header where the CGL* functions are declared on your platform.
As soon as I try to comment it out, I get more undeclared identifiers.

Not sure how to handle this now. I've looked up the reference at the Developer website hoping for some info about header file locations and not seeing anything. Throw in the fact the source code is in C++, which I have always avoided, doesn't help. I wouldn't be so lost if it was in Objective-C.
Last edited by patrickwalker on Mon Jan 29, 2018 1:59 pm, edited 2 times in total.
Post Reply