Opened 4 years ago
Closed 5 weeks ago
#61222 closed defect (fixed)
ghc @8.10.1: testing fails because the symbol _iconv is not found
| Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | essandess (Steve Smith) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.6.3 |
| Keywords: | Cc: | ||
| Port: | ghc |
Description
Running sudo port test ghc fails:
:info:test Linking mk/ghc-config ... :info:test Undefined symbols for architecture x86_64: :info:test "_iconv", referenced from: :info:test _hs_iconv in libHSbase-4.14.0.0.a(iconv.o)
This was previously mentioned in #57821 but needs to be tracked as a separate issue.
It is difficult to say why this happens, since it does not show us how it is "Linking mk/ghc-config". Is there a way to turn off silent rules so that we see the link command?
The problem may be that it is not using -liconv when linking, or that it is not using -L/opt/local/lib when linking (and in any case, the port needs to declare a dependency on port:libiconv as mentioned in #60171), or that libHSbase-4.14.0.0.a has been built against /usr/lib/libiconv.dylib whereas the test is now trying to link against /opt/local/lib/libiconv.dylib (in which case, fix libHSbase-4.14.0.0.a so that it is linked against /opt/local/lib/libiconv.dylib or use libHSbase-4.14.0.0.dylib instead of libHSbase-4.14.0.0.a).
Attachments (1)
Change History (8)
Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
comment:1 Changed 4 years ago by essandess (Steve Smith)
comment:2 Changed 4 years ago by essandess (Steve Smith)
comment:3 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
You mentioned that
ghc must be bootstrapped from a pre-compiled binary
and I see that the binary distribution contains libraries/base/dist-install/build/libHSbase-4.14.0.0.a, so I now assume that that is the library mentioned in the error message. I had originally assumed that it was a library that had been built on the user's system. But if it's a library distributed from upstream, then it is logical to assume that it was built with macOS libiconv, not MacPorts libiconv, and that using that library would therefore require that we use macOS libiconv, not MacPorts libiconv.
Again, we need to see the command that the build system is using when it is "Linking mk/ghc-config" so that we can see where in the source code it is happening so that we can change it. For example, if it is linking with libiconv using -L/opt/local/lib -liconv, then it needs to be changed to /usr/lib/libiconv.dylib.
comment:4 Changed 4 years ago by kencu (Ken)
Of the 1% of people who ever try to build ghc against a non-system-installed libiconv, probably 99% of those will be building it against a libiconv installed into /usr/local where the compiler and system find it automatically, and so they would never see this error.
MacPorts building in /opt/local, and in particular this libiconv failure, which as Josh pointed out one time appears to have been specifically designed to flag this problem, are great at demonstrating tiny build issues even with very mature and advanced software projects like ghc.
The ghc build system is quite complex, as I found building ghc for SnowLeopard. Some useful resources:
<https://gitlab.haskell.org/ghc/ghc/-/wikis/building>
<https://gitlab.haskell.org/ghc/ghc/-/wikis/building/using>
comment:5 Changed 4 years ago by essandess (Steve Smith)
comment:6 Changed 4 years ago by essandess (Steve Smith)
comment:7 Changed 5 weeks ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
This is an old, well-known, and annoying problem with
ghcwhen there are multipleiconvlibraries installed. I've looked for and haven't been able to identify the actual fix, which preferably would be to make the build completely dependent on native/usr/lib/libiconv.dylib, or the portlibiconv.If MacPorts's
libiconvis installed, the simple solution is to runbefore running
sudo port test ghc, then re-activating after you're done.In
ghc's Portfile, all the obvious things I and others have tried appear not to work, e.g. specifyingLIBRARY_PATHso that the build finds/opt/local/lib/libiconv.dylib.See also: