zlib.net error when building iOS project

[rahulpatel]

Firstly, thank you for pkgx! 🙏

I'm trying to migrate to pkgx from asdf and I've installed node and npm through pkgx and uninstalled asdf.

I have an existing react-native project which is resulting in the following error when building for iOS:

ld: building for 'iOS-simulator', but linking in dylib (/Users/rahul.patel2/.pkgx/zlib.net/v1.3.0/lib/libz.1.3.dylib) built for 'macOS'

Is there a way to include a version of zlib that is built for macOS, iOS and iOS-simulator?

[rahulpatel]

On second thoughts, I guess this might be an issue for zlib.net to address by building for iOS and iOS-simulator.

I'll leave the issue open incase there is something that can be done via pkgx but feel free to close if not.

[mxcl]

Does asdf provide binaries that are also built for simulators? That's pretty badass though will bloat pkg sizes quite a lot!

We would love to support iOS as well, it's in the #607, but we want to get other platforms more solid first.

I think that the problem here is the dev env includes our zlib in the LIBRARY_PATH but that interferes with the tooling that is trying to build iOS related stuff.

Adding to LIBRARY_PATH is generally what we need to do but in this case it is breaking stuff. Will have to noodle this some more. One option is to depend on the mac system libs for stuff like zlib that is so fundamental. It's probably a good call, and what brew does ofc.

[rahulpatel]

Does asdf provide binaries that are also built for simulators?

Unsure, the only difference I can see is that asdf will pulls the node binary for the specific arch whereas pkgx does not. However, I don't actually know too much about how node is distributed so I'm not convinced that it's actually the issue.

We would love to support iOS as well, it's in the #607, but we want to get other platforms more solid first.

Is this to run pkgx on iOS? Not sure if that would address the issue I raised or am I misunderstanding?

I think that the problem here is the dev env includes our zlib in the LIBRARY_PATH but that interferes with the tooling that is trying to build iOS related stuff.

Adding to LIBRARY_PATH is generally what we need to do but in this case it is breaking stuff. Will have to noodle this some more. One option is to depend on the mac system libs for stuff like zlib that is so fundamental. It's probably a good call, and what brew does ofc.

Ah that's really good to know! Depending on mac system libs sounds like a good idea but I imagine that'll get difficult to manage if those libs change between MacOS versions, though you probably have more experience with that 😅

[rahulpatel]

Would appending the common_vars[key] to the key instead of prepending them in src/prefab/construct-env.ts:117 fix this issue? Would that introduce other side effects?

If you're happy with this approach then I'll happy to make the change and open a PR.