[MacPorts] #68026: rav1e @0.6.6: iconv linking fails, expecting symbols from MacOS's iconv lib

Tue Sep 26 12:06:21 UTC 2023

#68026: rav1e @0.6.6: iconv linking fails, expecting symbols from MacOS's iconv lib
---------------------+---------------------------------
  Reporter:  jgrg    |      Owner:  MarcusCalhoun-Lopez
      Type:  defect  |     Status:  closed
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:  fixed   |   Keywords:
      Port:  rav1e   |
---------------------+---------------------------------

Comment (by ryandesign):

 Replying to [comment:13 kencu]:
 > Oh, I don't know, Ryan -- it looks a lot more common than you suggest. I
 believe it is the single most-commonly reported issue with macports.

 I didn't realize how common it was. Thank you for collecting that set of
 links.

 > I didn't read all of these in endless detail, but It took me about 10
 minutes to find about 40 quick examples where simply having a libiconv
 port caused a build failure that stopped someone long enough that it led
 them to post about it, and that doesn't even include all of macports
 tickets about it. For most of these issues, the upstream solution is to
 "uninstall libiconv".  They don't all look like bizarro build systems or
 ghc idiosyncracies.
 >
 > They are build issues, sure. They can be addressed and fixed by people
 who understand such things. I can fix almost all of them of course, for
 example. They all take someone's time, however, trip up builds, tie people
 down, and ... induce some people to uninstall macports.
 >
 > I think the question really is how much benefit does having a libiconv
 port add to macports, vs how much of a headache is it? The system
 lilbiconv seems just fine on all the macos systems macports installs on,
 in particular all newer systems. The system software  is all linked to the
 system libiconv, so even if you install a newer one via macports you
 haven't avoided perils of the old one.

 Certainly I want to reduce the number of reasons why people might perceive
 MacPorts to be broken and uninstall it. But is removing libiconv from
 MacPorts really the solution?

 Let's look at a few of these.

 > http://archive.ambermd.org/201007/0130.html

 Caused by the user putting /opt/local/lib into DYLD_LIBRARY_PATH.
 Solution: don't set DYLD_LIBRARY_PATH.

 > http://blog.omega-prime.co.uk/2011/01/28/solving-ghc-iconv-problems-on-
 os-x-10-6/

 This is ghc which we know about.

 > http://cegui.org/forum/viewtopic.php?t=7565

 Caused by using MacPorts iconv.h headers but linking with the macOS
 libiconv.dylib. Log doesn't show how that happened but the solution is to
 use a matched set of libraries and headers.

 > http://qdpl.blogspot.com/2010/08/macrails-dyld-lazy-symbol-binding.html

 Caused by the user putting /opt/local/lib into DYLD_LIBRARY_PATH.
 Solution: don't set DYLD_LIBRARY_PATH.

 > https://apple.stackexchange.com/questions/448063/macos-symbol-not-found-
 libiconv-when-run-sudo-command

 Probably caused by the user setting DYLD_LIBRARY_PATH. Solution: don't set
 DYLD_LIBRARY_PATH.

 > https://apple.stackexchange.com/questions/69936/terminal-and-bash-cant-
 start-with-libiconv-error

 Probably caused by the user setting DYLD_LIBRARY_PATH. Solution: don't set
 DYLD_LIBRARY_PATH.

 > https://copyprogramming.com/howto/libiconv-or-iconv-undefined-symbol-on-
 mac-osx

 I'll skip this since it appears to be an aggregator site that scrapes
 questions and answers from other sites in order to get pageviews to show
 ads.

 > https://discourse.slicer.org/t/build-problem-unknown-libiconv-symbols-
 on-macos-using-macports/1796

 Hard to say since full build logs were not provided but this appears to
 have been because during a build of slicer, which builds dcmtk, the wrong
 order of include flags caused a header from MacPorts dcmtk to be included,
 which turned on its libiconv support, which caused the MacPorts libiconv
 header to be included. Since the build was apparently not expecting to be
 using libiconv, I guess /opt/local/lib wasn't in the link flags so the
 macOS libiconv library got used. The solution is to fix the order of
 include flags.

 > https://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/139915.html

 Noting that this was ten years ago, ffmpeg disabled libiconv by default
 because allegedly the configure script would detect libiconv without using
 any -I or -L flag and thus find the macOS libiconv, but by the time
 configure had ended, -I and -L flags for MacPorts had gotten added due to
 some other dependency like libsdl. I don't quite follow why that would be
 a problem though. As long as both the -I and -L flags are either used or
 not used at compile time, everything should be fine.

 > https://github.com/kbknapp/cargo-outdated/issues/187
 >
 > https://github.com/kbknapp/cargo-outdated/issues/256

 Rust definitely strikes me as the same kind of weird as ghc.

 > https://github.com/OpenModelica/OpenModelica/issues/10944

 A build of OpenModelica failed when it used the libiconv header from
 Homebrew but tried to link with the macOS libiconv library.

 So I don't know. Should we really remove MacPorts libiconv in order to
 accommodate users who set DYLD_LIBRARY_PATH improperly or build systems
 that use flags in the wrong order? Should we do the same for all other
 software that already ships with macOS—zlib, sqlite3, readline, ncurses,
 icu, libxml2, tcl, tk, libjpeg? It would be a complete reversal of the
 established policy which was reached for a variety of good reasons. Using
 libraries from MacPorts, not macOS, means we have more up-to-date versions
 with fixes for bugs that are not fixed in Apple's versions, and it means
 we don't have to test on every macOS version to see whether the software
 works with whatever version of the library was on that macOS version.

 Software development can be hard, and using some build systems can be
 hard, but I don't consider using a matched set of headers and libraries to
 be hard, or something we should need to work around.

-- 
Ticket URL: <https://trac.macports.org/ticket/68026#comment:46>
MacPorts <https://www.macports.org/>
Ports system for macOS