macOS compilation and libiconv support

Crystal Contrib
1

Hello folks,

(wasn’t sure if this fits here or the issue tracker, so asking as question).

Wondering if there is a particular reason why crystal/iconv doesn’t allow libiconv to be used?

The specific code: crystal/iconv.cr at master · crystal-lang/crystal · GitHub

Checks that only under win32 lib_iconv will be used, otherwise it falls back to whatever c/platform is defined.

For the case of macOS, that will be the bundled iconv.

You might be wondering why am I asking this question?

I’ve been trying to cross-compile to macOS from Linux. I was able to successfully produce valid executables thanks to Zig CC being used as Mach-O linker.

However, the symbols it looks for _iconv_open, _iconv_close and _iconv which are not part of macOS libc (if we can call it that way)

Wondering if is ok to adjust the macro to something like flag?(:use_libiconv) || flag?(:win32)?

Here are some relevant threads about this on Zig itself:

Any comments on why this could be a bad idea, before I submit a PR with support for this? :grin:

Thank you in advance for your time reading all this!
:heart: :heart: :heart:

2

Sounds like a good idea :+1:

Usually we would do such things with linker configuration, but here we actually need to target different symbols. Thus it needs to be a compile time flag.

Note that there is already the without_iconv flag. I suppose that should perhaps be more correctly be named without_libiconv.

3

Thank you for your quick response!

Thought about that, but considering libiconv is just one implementation of iconv, perhaps will make it use_libiconv as option to force it’s usage.

Will send a PR shortly and let others comment there.

Thank you again for your time!
:heart: :heart: :heart:

1 Like
4

Yes I meant that as well. Sorry if that wasn’t clear. I just mentioned there is already a without_iconv flag which avoids linking against libiconv - but it also avoids linking against libc’s iconv. The latter should not be an issue on supported platforms. So we could consider changing the existing flag to mean without_libiconv. But that’s of course a separate issue and shouldn’t interfere with the action to add the use_libiconv flag.