Compiling on MacOS

[mporetvivint]

Trying to compile on MacOS and running into linker trouble. the gradle build results in this warning: "clang: warning: -lstdc++fs: 'linker' input unused [-Wunused-command-line-argument]"

The result of that unused argument is: "devolay.cpp:4:10: fatal error: 'filesystem' file not found"

[mporetvivint]

After further investigation it appears that the default apple compiler (clang/ apple llvm) doesn't support c++17 experimental calls unless you upgrade to MacOS 10.15 Catalina. So I'm going to have to use gcc instead. Although I'm not familiar enough with gradle to know how to change that

[WalkerKnapp]

I don't have a Mac to test this, but will it work if you install GCC with Homebrew or Macports and put it on the path before clang? https://docs.gradle.org/current/userguide/building_cpp_projects.html#macos The Gradle docs just say it chooses the first toolchain it can find.

[WalkerKnapp]

Also, there's a chance that the library loading code won't work for MacOS. I've only tried it with Linux and Windows. Let me know if there are any other build or runtime errors.

[mporetvivint]

OK it appears that those instructions don't account for the fact that homebrew renames gcc to avoid conflict. So it's called gcc-[version] instead. but a simple "ln -s gcc-9 gcc" solved the problem.

However now I'm getting a Null Pointer Exception at org.gradle.nativeplatform.toolchain.internal.gcc.GccPlatformToolProvider.versionAwareCompiler(GccPlatformToolProvider.java:119)

[mporetvivint]

OK using JDK 9 solved the null pointer exception, but now I'm getting java.lang.Cleaner doesn't exist

[WalkerKnapp]

Hm. Now it seems like this is a similar issue to #3. I'll do some research and get back to you to see if I can avoid using Cleaner and release a hotfix.

[mporetvivint]

Great. Thanks!

[WalkerKnapp]

Release 1.1.0 should hopefully solve this issue now. Let me know if it works!

[mporetvivint]

Know I'm back to a null pointer exception in gradle, I've tried with JDK 8, 9, and 13 with no luck

[WalkerKnapp]

Is it the same as before? Can you post the whole stacktrace? Likely this is an issue with gradle and gcc on MacOS, but I might be able to work around it. I'd need to look more into how gradle handles compilers.

[mporetvivint]

It doesn't give me the complete stacktrace, but it here's the extent of what it will give me: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':devolay-natives:compileDebugCpp'. at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:38) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52) at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:416) at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:406) at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165) at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250) at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158) at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:102) at org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36) at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52) at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:41) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:374) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:361) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:354) at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:340) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182) at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) Caused by: java.lang.NullPointerException at org.gradle.nativeplatform.toolchain.internal.gcc.GccPlatformToolProvider.versionAwareCompiler(GccPlatformToolProvider.java:119) at org.gradle.nativeplatform.toolchain.internal.gcc.GccPlatformToolProvider.createCppCompiler(GccPlatformToolProvider.java:104) at org.gradle.nativeplatform.toolchain.internal.AbstractPlatformToolProvider.newCompiler(AbstractPlatformToolProvider.java:119) at org.gradle.language.nativeplatform.tasks.AbstractNativeSourceCompileTask.getCompilerVersion(AbstractNativeSourceCompileTask.java:99) at org.gradle.language.cpp.tasks.CppCompile_Decorated.getCompilerVersion(Unknown Source) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.gradle.api.internal.tasks.properties.bean.AbstractNestedRuntimeBeanNode$BeanPropertyValue$1$1.create(AbstractNestedRuntimeBeanNode.java:80) at org.gradle.util.SingleMessageLogger.whileDisabled(SingleMessageLogger.java:507) at org.gradle.api.internal.tasks.properties.bean.AbstractNestedRuntimeBeanNode$BeanPropertyValue$1.get(AbstractNestedRuntimeBeanNode.java:76) at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:167) at org.gradle.api.internal.tasks.properties.bean.AbstractNestedRuntimeBeanNode$BeanPropertyValue.call(AbstractNestedRuntimeBeanNode.java:148) at org.gradle.api.internal.tasks.properties.annotations.NestedBeanAnnotationHandler.visitPropertyValue(NestedBeanAnnotationHandler.java:63) at org.gradle.api.internal.tasks.properties.bean.AbstractNestedRuntimeBeanNode.visitProperties(AbstractNestedRuntimeBeanNode.java:59) at org.gradle.api.internal.tasks.properties.bean.RootRuntimeBeanNode.visitNode(RootRuntimeBeanNode.java:32) at org.gradle.api.internal.tasks.properties.DefaultPropertyWalker.visitProperties(DefaultPropertyWalker.java:41) at org.gradle.api.internal.tasks.TaskPropertyUtils.visitProperties(TaskPropertyUtils.java:42) at org.gradle.api.internal.tasks.properties.DefaultTaskProperties.resolve(DefaultTaskProperties.java:64) at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:55) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56) at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36) ... 23 more

[WalkerKnapp]

Sorry for the wait, but I finally got my hands on a MacOS VM. I couldn't replicate the issue you're having, but I was able to build using it and a Linux system, so release 1.1.1 should finally be universal! Just bump your version number and hopefully, you'll be able to use the version on bintray.

[mporetvivint]

Great! Thanks! I've added it to my project and let you know how it goes

[mporetvivint]

Ok we're getting close! When testing the finder, I get this runtime error. I'm not exactly sure what it means. Is it possible that i'm getting this because I'm on MacOS 10.14.6? dyld: lazy symbol binding failed: Symbol not found: ZNSt314fs10filesystem8statusERKNS1_4pathEPNS_10error_codeE Referenced from: /private/var/folders/sj/xl8b60411rd_sc213tsy365c0000gp/T/devolay-natives8226013661759208515.dylib (which was built for Mac OS X 10.15) Expected in: /usr/lib/libc++.1.dylib

[WalkerKnapp]

This looks like the libc++ bundled with Mojave doesn't support the c++17 spec. Can you try doing something like this (Under the Installing a more modern llvm section)? https://blog.knatten.org/2018/04/06/trying-out-c17-on-macos/

Edit: This might work without much hassle if you install Xcode 11 Beta instead of manually updating the llvm, https://stackoverflow.com/a/56435964/5960285

The only other solution would be upgrading MacOS, unfortunately. Sorry you're having so many issues here, I didn't expect MacOS to have so many issues with using the new spec.

[mporetvivint]

Finally was able to update to Catalina and now it runs! Thanks a bunch!

[WalkerKnapp]

That's great! Thanks for the update, and let me know about any other issues.