imodeljs-native/imodeljs-darwin-x64 logs an error on macbook for nodejs > version 11

[PeterJBassett]

Describe the bug A clear and concise description of what the bug is.

Running unit tests on a bridge application linking iModel and FutureOn FieldTwin. If I run the tests using nodejs v11.15.0, the tests run and pass If I run the tests using nodejs v14.17.0, after a full npm install, I get the following error:

Bridge Downloader FutureOnBridge

updateExistingData()

dyld: lazy symbol binding failed: Symbol not found: _IOMasterPort Referenced from: my-working-directory/node_modules/@bentley/imodeljs-native/imodeljs-darwin-x64/imodeljs.node Expected in: flat namespace

dyld: Symbol not found: _IOMasterPort Referenced from: my-working-directory/node_modules/@bentley/imodeljs-native/imodeljs-darwin-x64/imodeljs.node Expected in: flat namespace

Killed: 9

I am running the tests on a Macbook Pro, 2.9 GHz Quad-Core Intel Core i7, MacOS version 11.4

The iModel versions in package.json are as follows: "dependencies": { "@bentley/backend-itwin-client": "2.17.0-dev.35", "@bentley/bentleyjs-core": "2.17.0-dev.35", "@bentley/bis-core-schema": "^1.0.11", "@bentley/config-loader": "^1.14.1", "@bentley/ecschema-metadata": "2.17.0-dev.35", "@bentley/frontend-authorization-client": "2.17.0-dev.35", "@bentley/geometry-core": "2.17.0-dev.35", "@bentley/imodel-bridge": "2.17.0-dev.35", "@bentley/imodelhub-client": "2.17.0-dev.35", "@bentley/imodeljs-backend": "2.17.0-dev.35", "@bentley/imodeljs-common": "2.17.0-dev.35", "@bentley/imodeljs-i18n": "2.17.0-dev.35", "@bentley/itwin-client": "2.17.0-dev.35", "@bentley/logger-config": "2.17.0-dev.35", "@bentley/rbac-client": "2.17.0-dev.35", "@bentley/telemetry-client": "2.17.0-dev.35", "bunyan": "^1.8.13", "bunyan-seq": "^0.2.0", "draco3d": "1.3.6", "open": "^7.0.4", "request-promise": "^4.2.5", "three": "^0.116.1", "username": "^5.1.0" }, "devDependencies": { "@bentley/build-tools": "^1.14.1", "@bentley/oidc-signin-tool": "2.17.0-dev.35", "@types/chai": "^4.2.11", "@types/jquery": "^3.5.0", "@types/mocha": "^5.2.6", "@types/node": "^10.17.26", "chai": "^4.2.0", "mocha": "^5.2.0", "nock": "^12.0.3", "tslint": "^5.20.1", "typescript": "^3.9.5" }

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

The iModel application should run using nodejs v14 on a Mackbook.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the applicable information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]
• iTwin.js Version [e.g. 2.5.3]

Additional context Add any other context about the problem here.

[pmconne]

My understanding is that issues with macOS and Node 14 should be resolved in imodeljs-backend 2.19.0 - @calebmshafer can you confirm?

[calebmshafer]

Yes, this should now be fixed in 2.19.0. Please update and let us know if this issue still occurs.

[PeterJBassett]

Yes I have tried 2.19.0, and can confirm that it now supports nodejs v14 on MacOS. I had to make a code change in order for the ts code to compile. This didn't compile in 2.19.0

public static flushTxns(iModelDb: IModelDb): boolean { iModelDb.nativeDb.startCreateChangeSet(); const status = iModelDb.nativeDb.finishCreateChangeSet(); if (ChangeSetStatus.Success !== status) return false; return true; }

[kabentley]

Yes I have tried 2.19.0, and can confirm that it now supports nodejs v14 on MacOS. I had to make a code change in order for the ts code to compile. This didn't compile in 2.19.0

public static flushTxns(iModelDb: IModelDb): boolean { iModelDb.nativeDb.startCreateChangeSet(); const status = iModelDb.nativeDb.finishCreateChangeSet(); if (ChangeSetStatus.Success !== status) return false; return true; }

I would be interested to understand why you’re “flushing” the txns. My guess is this is leftover cruft from some old code.

This code improperly uses an internal api. If you really want to delete existing txns (why?), you can use nativeDb.deleteAllTxns, which is also internal and equally dangerous.

HTH, Keith

[PeterJBassett]

Thank you for your guidance. This is code that was written internally at Bentley, so I don't know the background reason for it. It is a function in a TestUtils module. I have now done a search through the code and found that this function is never used, so I have deleted it.

[pmconne]

Thanks for the feedback @PeterJBassett. Closing issue as resolved.