In libiconv, renaming of symbols from _iconv to _libiconv. Why?

[cath.gasnier@…]

Fighting for a long time to compile SRILM (a language processing software), I realized (using command nm) that the macports libiconv has symbols _libiconv, _libiconv_open and _libiconv_close, while the original Mac OS X libiconv, in /usr/lib in my case, has symbols _iconv, _iconv_open and _iconv_close (so I had to use the library in /usr/lib for my program to compile). Why this renaming?

[neverpanic (Clemens Lang)]

This rename is transparent for you if you use the headers matching the library. The headers installed by the MacPorts libiconv port contain #define iconv libiconv. If this doesn't work for you out of the box, your header include path is probably wrong.

This isn't a change introduced by MacPorts. We package libiconv with the default options from upstream. It seems Apple either uses a different implementation or defines the LIBICONV_PLUG preprocessor constant while building libiconv.

Please don't set the milestone field when reporting bugs against ports. Also, Cc the maintainer of the port(s), if any.

[ryandesign (Ryan Carsten Schmidt)]

Right, this is not a bug.

[mouse07410 (Mouse)]

If the developers were concerned about a conflict with an OS-provided iconv - why didn't they change the name of this library to, e.g., liblibiconv, to make sure a binary linked with one would not mistake the other one for the right lib and fail?

[ryandesign (Ryan Carsten Schmidt)]

I don't know why the developers chose to do things the way they did; you'll have to ask them. In any case, everything should work fine, provided you use the iconv.h header that matches the libiconv.dylib library you're using. Don't, for example, try to use Apple's iconv.h together with MacPorts' libiconv.dylib or vice versa.

[mouse07410 (Mouse)]

I don't know why the developers chose to do things the way they did

I don't want to call that choice stupid, but you can guess how I feel about it.

everything should work fine, provided you use the iconv.h header that matches the libiconv.dylib library you're using

The problem is - I'm using Macports tools (like gcc8), and other tools like Haskell Platform.Tools - tools like in binaries. Which saved me (so far!) from the huge work of rebuilding every tool myself from source, and maintaining all that stuff - but it also means that I have little to no control over how those binaries are built. And in many cases, I cannot even force *rebilding* of those tools (Haskell). So, a lot of Macports tools are built with Macports libiconv and require it to be the first in the search path to run, while other tools (Haskell) are built with Apple iconv and require that one to be the first. And, as Haskell Platform is a tool for building other software, it and whatever I build with it* needs to see the system version of iconv first. Your suggestion from the other ticket would work, except that it would make it impossible to use tools from Macports packages together with those I build on Haskell Platform...

None of the options are impossible. After all, Macports is open source, so it is possible to hack it and force all the ports I use - less than 600 in total - to use Apple's iconv. Equally, Haskell Platform is open source, so it is possible to rebuild it by hand, forcing it to use Macports iconv. But neither of these is either practical or appealing.

Perhaps there could be a configuration option or variant for Macports libiconv that does not mangle the names? So I don't have to rebuild large packages by hand to overcome the damage libiconv developers upstream did?

[ryandesign (Ryan Carsten Schmidt)]

Since your issue has a unique cause that is more specific than the issue discussed in this ticket, I'll reply in your ticket #57821.