alex @3.2.7.1: Undefined symbols: _iconv occurs when user has not installed the command-line tools

[jsalort (Julien Salort)]

alex fails to build on Ventura arm64. The log file reports undefined symbols _iconv for architecture arm64.

[kencu (Ken)]

because of the way we have built ghc, against the system libiconv (which is appropriate) we will have to always force cabal and ghc to link preferentially against the system libiconv too.

This can be done by passing the full path to the libiconv dylib (or libiconv tbd file in such systems as have tbd files) on the cabal build line or via cabal config.

[jsalort (Julien Salort)]

I have tried to fix the Portfile, but I do not have experience with Haskell build systems. I only need alex because it is a build dependency of pandoc.

This is what I tried:

configure.ldflags-append \
    -L${configure.sdkroot}/usr/lib -liconv
destroot.env-append \
    "LDFLAGS=${configure.ldflags}"
configure.args-append \
    --extra-lib-dirs=${configure.sdkroot}/usr/lib \
    --ghc-options="-L${configure.sdkroot}/usr/lib -liconv"
build.args-append \
    --extra-lib-dirs=${configure.sdkroot}/usr/lib \
    --ghc-options="-L${configure.sdkroot}/usr/lib -liconv"

Are there other ways to provide link options ?

Side note: there is also a "stack" variant, and it yields the same iconv link error.

[kencu (Ken)]

if libiconv is installed, it’s going to be necessary to force the build to ignore it, as above…. the maintainer is aware of this lbiconv issue.

luckily, as of yesterday, there is a buildbot for arm ventura. It builds alex without any libiconv being installed, so no problem.

​https://build.macports.org/builders/ports-13_arm64-builder/builds/2122

you should be able to just install that binary now, assuming you have the default install prefix

[kencu (Ken)]

homebrew does not place libiconv into the default header and library search paths, so they never see these libiconv issues we see on MacPorts.

If it wouldn’t require rebuilding about 10,000 ports I’d push for MacPorts to do that too, as libiconv is very static and newer versions offer almost nothing over the system version, even on very old systems, it seems

[jsalort (Julien Salort)]

That is a great news about the build bot! Indeed, it now successfully installs. I am a bit mystified as to how could the build bot actually succeeds though.

[kencu (Ken)]

when the buildbot builds alex, libiconv is not installed by MacPorts.

So it uses the system libiconv, which works.

[saagarjha (Saagar Jha)]

Presumably this isn't really a fix for upcoming releases of macOS. What should we do for those?

[CodingMarkus]

I now have the same problem with alex-3.3.0.0_0 on macOS 14.1 (Sonoma).

fetch alex-3.3.0.0_0+haskell_cabal_use_prebuilt.darwin_23.arm64.tbz2 is not found and building fails because the symbol _iconv is not found.

What I don't quite understand is:

1. Why do you force ghc to build against the system libiconv in the first place? ("because of the way we have built ghc, against the system libiconv")

2. If libiconv is so static ("as libiconv is very static"), how can there be undefined symbols? If it really was that static, then any version of it would offer the same symbols. Apparently the current version of it misses a symbol that the system version has, which sounds anything but static to me.

To me this can only be solved in two ways: MacPorts always uses the system library and MacPorts never uses it. Make up your mind and then go with it. Any other concept was totally flawed to begin with and relying on a buildbot is no solution at all, it's a bloody workaround in lack of a real solution.

[ryandesign (Ryan Carsten Schmidt)]

Replying to saagarjha:

Presumably this isn't really a fix for upcoming releases of macOS. What should we do for those?

Are you referring to the situation of new OS versions being released and buildbot workers not being immediately set up for them, or some other issue with a specific new version of macOS?

Replying to CodingMarkus:

I now have the same problem with alex-3.3.0.0_0 on macOS 14.1 (Sonoma).

fetch alex-3.3.0.0_0+haskell_cabal_use_prebuilt.darwin_23.arm64.tbz2 is not found

That's correct. There are no "darwin_23.arm64" binaries for any port yet. I haven't set up that buildbot worker yet.

and building fails because the symbol _iconv is not found.

What I don't quite understand is:

1. Why do you force ghc to build against the system libiconv in the first place? ("because of the way we have built ghc, against the system libiconv")

Explanations have been offered which I am too stupid to understand.

2. If libiconv is so static ("as libiconv is very static"), how can there be undefined symbols? If it really was that static, then any version of it would offer the same symbols. Apparently the current version of it misses a symbol that the system version has, which sounds anything but static to me.

A system version of libiconv intentionally uses different symbol names from a non-system version of libiconv. This is how libiconv was designed to work. It was intended to avoid conflicts, but with the way that ghc apparently misuses libiconv, it instead causes conflicts. If you have concerns about this, please have a dialog with the developers of ghc and libiconv.

To me this can only be solved in two ways: MacPorts always uses the system library and MacPorts never uses it. Make up your mind and then go with it. Any other concept was totally flawed to begin with and relying on a buildbot is no solution at all, it's a bloody workaround in lack of a real solution.

MacPorts did decide, 20 years ago when libiconv was added to MacPorts, that ports would use a MacPorts version of libiconv. Same goes for most other libraries, even those already provided by the OS. Those decisions are not set in stone, of course, and could be changed if there were a good reason to, but I don't think there is. My uninformed view is that ghc is badly designed and why should MacPorts be changed to accommodate badly-designed software? I suggest finding a well-designed alternative to anything ghc-related.

I agree that the buildbot is a nicety and designing ports that rely on its existence is a flawed strategy.

[kencu (Ken)]

see:

​https://github.com/macports/macports-ports/pull/20722

for more similar discussion.

The long-term solutions to this problem would appear to be:

1. ghc upstream might statically link against libiconv.a and therefore not need to find a particular specific libiconv.dylib implementation at runtime/link time.
2. macports might move libiconv into a sequestered location where it is not found opportunistically by 800 ports. This would solve all libiconv problems on macports forever, but require some work to 800 ports if using the new version was preferred over the system version.

[jsalort (Julien Salort)]

Replying to kencu:

The long-term solutions to this problem would appear to be:

1. ghc upstream might statically link against libiconv.a and therefore not need to find a particular specific libiconv.dylib implementation at runtime/link time.
2. macports might move libiconv into a sequestered location where it is not found opportunistically by 800 ports. This would solve all libiconv problems on macports forever, but require some work to 800 ports if using the new version was preferred over the system version.

Is it not possible to build ghc in Macports with a statically linked libiconv, without the need to convince upstream ?

[kencu (Ken)]

ghc builds using an upstream ghc as the boot compiler.

this boot compiler has a component that is a prebuilt static library that needs the symbols found only in the system libiconv to link successfully.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

2. macports might move libiconv into a sequestered location where it is not found opportunistically by 800 ports. This would solve all libiconv problems on macports forever, but require some work to 800 ports if using the new version was preferred over the system version.

I don't feel that there is any reason why a standard library like libiconv, where we do indeed want all ports that use libiconv to use the MacPorts one, should be moved to a nonstandard location which would require extra effort in all of the ports that use it to continue to use it.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #68989.

[mouse07410 (Mouse)]

we do indeed want all ports that use libiconv to use the MacPorts one

Would you care to elucidate why?

For example, offhand, I don't want any port to use the MacPorts libiconv.

MacPorts did decide, 20 years ago when libiconv was added to MacPorts, that ports would use a MacPorts version of libiconv.

Bad decisions tend to not age well. And time period of 20 years can turn even originally-reasonable decisions into pretty-darn-bad ones now.

[raimue (Rainer Müller)]

Replying to mouse07410:

we do indeed want all ports that use libiconv to use the MacPorts one

Would you care to elucidate why?

For example, offhand, I don't want any port to use the MacPorts libiconv.

This is not how the MacPorts system is designed and meant to be used. The policy is that ports should prefer libraries from other ports over the system. There are very few exceptions to this.

Please see the related FAQ: ​https://trac.macports.org/wiki/FAQ#syslibs

[kencu (Ken)]

Replying to ryandesign:

I don't feel that there is any reason why a standard library like libiconv, where we do indeed want all ports that use libiconv to use the MacPorts one, should be moved to a nonstandard location which would require extra effort in all of the ports that use it to continue to use it.

The hope would be that no ports find a need to ever use it, and we just mostly stop using it.

libiconv is unusually troublesome because the incompatible libraries (system vs macports) have the same names, so the wrong one is often linked in.

As before, when I listed all the urls I found complaining about the issue, I believe is is the single biggest complaint against macports.

I realize bugfixes, etc, happen over time but libiconv seems quite static… I’d have to see if and where the system libiconv might truly be inferior to the current one.

[kencu (Ken)]

here’s the libiconv changelog over the years

​https://fossies.org/linux/libiconv/ChangeLog

most of the changes are build system changes, which would be irrelevant to using the system installed version.

Anyway, this is pie in the sky, as MacPorts will never do this, we all know.

With respect to this alex ticket, I just built alex on my Sonoma arm system with libiconv installed, and it built with no issues.

I also note in the original log in this ticket this OP has also forgotten to install the command line tools, so perhaps that is all that is needed here to fix this issue:

Install the command line tools.

[kencu (Ken)]

if anyone sees this linking issue, and they have the CLTs installed as MacPorts requires to build pretty much anything, please open a new ticket about that, with a fresh log.