rav1e @0.6.6: iconv linking fails, expecting symbols from MacOS's iconv lib

[jgrg (James Gilbert)]

I'm installing MacPorts from source into my home directory. rav1e fails at the linking stage with:

Undefined symbols for architecture arm64:
  "_iconv", referenced from:
      _git_fs_path_iconv in liblibgit2_sys-ba9907996f69a118.rlib(fs_path.o)
     (maybe you meant: _git_fs_path_iconv_init_precompose, _git_fs_path_iconv_clear , _git_fs_path_iconv )
  "_iconv_close", referenced from:
      _git_fs_path_iconv_clear in liblibgit2_sys-ba9907996f69a118.rlib(fs_path.o)
  "_iconv_open", referenced from:
      _git_fs_path_iconv_init_precompose in liblibgit2_sys-ba9907996f69a118.rlib(fs_path.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I attach the main.log for the failed build.

I believe that MacPorts' libiconv would have symbols named e.g. _libiconv_close rather than _iconv_close found in MacOS's libiconv.

[jgrg (James Gilbert)]

main.log from failed build

[jmroot (Joshua Root)]

You usually see this when the header and library are mismatched, i.e. the system iconv.h is included but then the MacPorts libiconv.dylib is linked with. Another way it can happen is if LIBICONV_PLUG is defined before including the header.

[jgrg (James Gilbert)]

These are the iconv.h files on my system:

/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/iconv.h
/Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/usr/include/iconv.h
/Library/Developer/CommandLineTools/SDKs/MacOSX13.1.sdk/usr/include/iconv.h
/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/include/iconv.h
/Users/jgrg/MacPorts/include/iconv.h

Then there are these libiconv files:

/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/lib/libiconv.2.tbd
/Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/usr/lib/libiconv.2.tbd
/Library/Developer/CommandLineTools/SDKs/MacOSX13.1.sdk/usr/lib/libiconv.2.tbd
/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/libiconv.2.tbd
/Users/jgrg/MacPorts/lib/libiconv.2.dylib

The .tbd stub files all have the line install-name: '/usr/lib/libiconv.2.dylib' but there is no installed file /usr/lib/libiconv.2.dylib

[kencu (Ken)]

the basic problem is that the build is picking up this header:

/Users/jgrg/MacPorts/include/iconv.h

but the link link is not finding this libiconv:

/Users/jgrg/MacPorts/lib/libiconv.2.dylib

it's finding the system one instead.

This is an extremely common problem on MacPorts, and affects a great many builds that do not have perfect include and link lines.

When I look at your log, the link line that generates the error should have something like:

-L /Users/jgrg/MacPorts/lib

but I couldn't spot that.

For a workaround, you *might* be able to deactivate macports libiconv, build rav1e, and then activate libiconv again.

If there are things linked against MacPorts libiconv that prevent you from disabling it, then sometimes I temporarily will rename the header to make it not found, eg:

/Users/jgrg/MacPorts/include/iconv.h

to

/Users/jgrg/MacPorts/include/iconv.h-disabled

Those hacks are of course not proper fixes.

Fixing rust builds properly is very very hard to do, and only a few people on MacPorts would even consider approaching doing it.

The libiconv issue is such a pain that I have often thought MacPorts should not put it's libiconv installation loose in include and lilb, but tuck it away somewhere in libexec instead, so that ports have to specifically enable those paths to use it. But I have not wanted to open the inevitable long conversation about doing that, that would only end up back where we are now anyway.

[kencu (Ken)]

Another related issue is ports that use premade parts that are linked against the system libiconv, but then the build tries to link against MacPorts libiconv, and the two libiconv implementations are incompatible. This is currently affecting several ports as well (in the ghc/stack infrastructure), and has no great fix.

[jgrg (James Gilbert)]

I've tried doing port -f deactivate libiconv, but it immediately gets reactivated by port install rav1e. Is there a way to work around this?

I tried iconv.h-disabled but it made no difference.

My MacPorts lib is included in the link command:

-L rav1e-0.6.6/target/release/deps
-L rav1e-0.6.6/target/release/build/libgit2-sys-ab97ceeb80cad379/out/build
-L /Users/jgrg/MacPorts/lib
-L /Users/jgrg/MacPorts/lib/rustlib/aarch64-apple-darwin/lib
-L /Users/jgrg/MacPorts/lib/rustlib/aarch64-apple-darwin/lib

Yes, /Users/jgrg/MacPorts/lib/rustlib/aarch64-apple-darwin/lib is included twice. -liconv appears twice too.

If the build is intending to link against the MacPorts iconv, wouldn't be looking for _libiconv... symbols rather than _iconv...?

[kencu (Ken)]

Replying to jgrg:

If the build is intending to link against the MacPorts iconv, wouldn't be looking for _libiconv... symbols rather than _iconv...?

Oh, yes, I think you're right. It might be the other way around in this case, using the symbol names in the system iconv.h but then trying to link against macports libiconv.dylib and finding the wrong symbols there.

(or possibly it is the prelinked premade parts as above, harder to fix).

It is indeed a PITA, has been for years, and is probably going to continue to be for years more, especially with very opaque build systems like rust and ghc and similar.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jgrg:

but there is no installed file /usr/lib/libiconv.2.dylib

That's correct. That's how Apple, in their infinite wisdom, have decided to do things on macOS 11 and later. System libraries are no longer separate entities in the filesystem. They are only in the dyld cache. This is not supposed to be a problem.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

This is an extremely common problem on MacPorts, and affects a great many builds that do not have perfect include and link lines.

It's an extremely uncommon problem in MacPorts and elsewhere. It's very simple to get this right: use the iconv header and library from the same place. Do not mix and match. The problem only affects exceedingly weird software that's doing things very wrong.

Replying to kencu:

Another related issue is ports that use premade parts that are linked against the system libiconv, but then the build tries to link against MacPorts libiconv, and the two libiconv implementations are incompatible. This is currently affecting several ports as well (in the ghc/stack infrastructure), and has no great fix.

ghc/stack is an example of exceedingly weird software doing things very wrong. It only goes wrong because they ship a static library that was linked against the system iconv and require everyone else to link with that static library and hilarity ensues. Static libraries are not recommended on macOS; this is an example of what happens when developers ignore Apple's recommendations.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jgrg:

I've tried doing port -f deactivate libiconv, but it immediately gets reactivated by port install rav1e. Is there a way to work around this?

rav1e depends upon and links with MacPorts libiconv. Don't attempt to deactivate it.

We have ​successful builds of rav1e on all OS versions on the buildbot so there is something different about your system, or something has changed since our builds happened. We could compare your log with a buildbot log but those were so long ago that the logs have expired. Someone for whom the build works could try it on their system and compare their log to yours.

Your log is incomplete. Please sudo port clean rav1e and then try again and if it fails again attach the new complete main.log file.

[lukaso (Lukas Oberhuber)]

Here is the upstream issue report: ​https://github.com/rust-lang/git2-rs/issues/830

I'm attaching my log file as well. Oddly, this just started happening so something has changed. I suspect this is still rust not respecting the macos sdk versions, etc.

[kencu (Ken)]

this upstream issue seems quite relevant:

​https://github.com/rust-lang/git2-rs/issues/672

[kencu (Ken)]

Replying to ryandesign:

Replying to kencu:

This is an extremely common problem on MacPorts, and affects a great many builds that do not have perfect include and link lines.

It's an extremely uncommon problem in MacPorts and elsewhere. It's very simple to get this right: use the iconv header and library from the same place. Do not mix and match. The problem only affects exceedingly weird software that's doing things very wrong.

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 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.

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

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

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

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

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

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

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

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

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

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

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

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

​https://github.com/rabiaasif/git-osx-installer/issues/18

​https://github.com/rust-lang/git2-rs/issues/180

​https://github.com/rust-lang/git2-rs/issues/263

​https://gitlab.haskell.org/ghc/ghc/-/issues/18743

​https://gitlab.haskell.org/ghc/ghc/-/issues/22118

​https://gitlab.kitware.com/cmake/cmake/-/issues/18892

​https://itecnote.com/tecnote/macos-how-to-fix-libiconv-error-on-mac/

​https://jongampark.wordpress.com/2014/01/30/libiconv-from-macport-and-os-x-framework/

​https://lightrun.com/answers/rikvdkleij-intellij-haskell-fails-to-install-haskell-tools-because-its-using-the-wrong-compiler

​https://mailman.speech.sri.com/pipermail/srilm-user/2014q2/001665.html

​https://mattgumbley.wordpress.com/2021/06/21/rust-instrumentation-on-macos-in-the-presence-of-macports/

​https://mw.gl/posts/libiconv_mac/

​https://nostandardwork.com/tag/git/

​https://sourceforge.net/p/fontforge/mailman/message/36910268/

​https://stackoverflow.com/questions/1148450/unable-to-build-scipy-on-os-x-10-5-7

​https://stackoverflow.com/questions/12619600/libiconv-and-macos

​https://stackoverflow.com/questions/13059273/libiconv-2-dylib-not-found

​https://stackoverflow.com/questions/13301786/how-to-fix-libiconv-error-on-mac

​https://stackoverflow.com/questions/27392085/cant-link-to-iconv-on-os-x

​https://stackoverflow.com/questions/38880007/cant-compile-gdal-on-osx-1-11-6-due-to-libiconv-link-error

​https://stackoverflow.com/questions/43359289/architecture-x86-64-while-running-haskell-code-haskell-osx-iconv

​https://stackoverflow.com/questions/57734434/libiconv-or-iconv-undefined-symbol-on-mac-osx

​https://stackoverflow.com/questions/73418423/macports-opt-local-bin-python3-cant-find-libiconv-symbol-unless-run-under-she

​https://superuser.com/questions/394219/compiling-php-on-os-x-iconv-works-only-if-forced-to-64-bit

​https://superuser.com/questions/736210/how-do-i-remove-an-old-version-of-iconv-on-which-other-software-depends-and-ot

​https://trac.macports.org/ticket/43698

​https://trac.macports.org/ticket/50044

​https://trac.macports.org/ticket/57821

​https://www.cs.cmu.edu/~music/serpent/doc/installation-mac64.html

​https://www.mail-archive.com/haskell-cafe@haskell.org/msg69139.html

[lukaso (Lukas Oberhuber)]

If getting rid of the macports inconv library helps things, I'm all for it. It's the second most blocking thing after respecting the macos deployment targets.

[jgrg (James Gilbert)]

Replying to ryandesign:

Your log is incomplete. Please sudo port clean rav1e and then try again and if it fails again attach the new complete main.log file.

Done, but without the sudo, since I'm installing in my home dir, compiling from source, and did ./configure --prefix=/Users/jgrg/MacPorts --with-no-root-privileges

[jgrg (James Gilbert)]

rav1e rebuild after port clean

[Liontooth (David Liontooth)]

Same problem. This is now blocking lots of other ports.

I tried to disable rav1e in ffmpeg, unsuccessful. It would be useful to have an option to not go into this rabbit hole of rust and av1 if it's not needed.

[mascguy (Christopher Nielsen)]

Has duplicate issue:68098

[mascguy (Christopher Nielsen)]

Related issue, whereby rav1e is installed by way of git: issue:68051

[Christopher Nielsen <mascguy@…>]

In e692ad749145ed4b4ccf4320c67a90a2144e8c3e/macports-ports (master):

p5-uri: drop optional dep p5-business-isbn

• Said dep brings a boatload of backage, including graphic ports, impacting git and other ports.
• More importantly, p5-business-isbn causes a dependency cycle, for some ports that depend on git.

Fixes: #68051
See: #68026

[mascguy (Christopher Nielsen)]

Replying to Liontooth:

Same problem. This is now blocking lots of other ports.

I tried to disable rav1e in ffmpeg, unsuccessful. It would be useful to have an option to not go into this rabbit hole of rust and av1 if it's not needed.

We'll take a look at ffmpeg, and provide an option to avoid use of rav1e. Worst-case, it'll be completed by 9:00am tomorrow morning, if not sooner.

More to follow soon.

[Christopher Nielsen <mascguy@…>]

In af071c2b82dc0fdf7b554a440a04cac1c7b21459/macports-ports (master):

ffmpeg*: add new variant slim

See: #68026

[mascguy (Christopher Nielsen)]

Replying to mascguy:

We'll take a look at ffmpeg, and provide an option to avoid use of rav1e. Worst-case, it'll be completed by 9:00am tomorrow morning, if not sooner.

Okay, we've gone ahead and updated our various ffmpeg ports, to support a new variant: +slim.

At the moment, it only eliminates rav1e from the dependency chain. But eventually it may trim a few more as well, depending on users' needs.

In any event, the update should be available within 2-3 hours. At that point, re-sync your ports tree, and run port info --variants ffmpeg to verify that slim is listed:

$ port info --variants ffmpeg
variants: x11, libdc1394, librtmp, jack, darwinssl, gpl2, gpl3, nonfree, slim

If you don't see it in the list, it hasn't come through yet.

But once it's there, install ffmpeg via sudo port -N install ffmpeg +slim. (Along with any other variants, if you also have others enabled.)

And please let us know how it goes!

[Liontooth (David Liontooth)]

Fantastic, thanks! That worked:

--->  Deactivating ffmpeg @4.4.2_6+gpl2+universal
--->  Activating ffmpeg @4.4.4_1+gpl2+slim)

It doesn't currently satisfy the ffmpeg dependency of other packages -- but ffmpeg-4.4.4_1+gpl2+universal now also installs without pulling in rav1e:

--->  Computing dependencies for strigi
--->  Dependencies to be installed: ffmpeg
--->  Fetching archive for ffmpeg
--->  Attempting to fetch ffmpeg-4.4.4_1+gpl2+universal.darwin_22.arm64-x86_64.tbz2 from https://packages.macports.org/ffmpeg
--->  Attempting to fetch ffmpeg-4.4.4_1+gpl2+universal.darwin_22.arm64-x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/ffmpeg
--->  Attempting to fetch ffmpeg-4.4.4_1+gpl2+universal.darwin_22.arm64-x86_64.tbz2 from http://mirror.fcix.net/macports/packages/ffmpeg
--->  Fetching distfiles for ffmpeg
--->  Verifying checksums for ffmpeg
--->  Extracting ffmpeg
--->  Applying patches to ffmpeg
--->  Configuring ffmpeg
--->  Building ffmpeg                                    
--->  Staging ffmpeg into destroot                       
--->  Installing ffmpeg @4.4.4_1+gpl2+universal          
--->  Deactivating ffmpeg @4.4.4_1+gpl2+slim
--->  Cleaning ffmpeg
--->  Activating ffmpeg @4.4.4_1+gpl2+universal              

So as far as I can see, whatever you did worked. I see the portfile now has:

    # Available on 10.6+ 
    if {(${os.major} >= 10) && (${configure.build_arch} ne "ppc")} {
        # Only enable 'rav1e', for non-slim installation
        if {![variant_isset slim]} {
            configure.args-append \
                    --enable-librav1e
            depends_lib-append \
                    port:rav1e
        }
    }

I'm running this on an M2 with Ventura 13.1, but rav1e was not in fact enabled even for the default (non-slim) version:

$ port installed ffmpeg rav1e
The following ports are currently installed:
  ffmpeg @4.4.2_6+gpl2+universal
  ffmpeg @4.4.4_1+gpl2+slim
  ffmpeg @4.4.4_1+gpl2+universal (active)
  rav1e @0.6.3_0+universal (active)

However, yt-dlp also wants ffmpeg and in this case it pulls in rav1e and fails. To prevent this, I issued:

sudo port activate ffmpeg @4.4.4_1+gpl2+slim

And yt-dlp installed without pulling in rav1e. This triggered a rebuild request for strigi:

--->  Computing dependencies for strigi
--->  Dependencies to be installed: ffmpeg
--->  Deactivating ffmpeg @4.4.4_1+gpl2+slim
--->  Cleaning ffmpeg
--->  Activating ffmpeg @4.4.4_1+gpl2+universal
--->  Cleaning ffmpeg

After reverting to ffmpeg +gpl2+universal, no rebuild is triggered for yt-dlp. I tested yt-dlp and it works.

It seems a bit of a fluke that this is working. Strigi doesn't accept ffmpeg +slim, but builds ffmpeg +gpl2+universal without rav1e. yt-dpl accepts ffmpeg +slim and doesn't notice that ffmpeg has been changed back to ffmpeg +gpl2+universal.

If there's a way to resolve this ticket and build rav1e, that's of course the preferred solution. In the meantime, is it worth making ffmpeg +slim be accepted by default by all ports that need ffmpeg?

[mascguy (Christopher Nielsen)]

Replying to Liontooth:

It doesn't currently satisfy the ffmpeg dependency of other packages -- but ffmpeg-4.4.4_1+gpl2+universal now also installs without pulling in rav1e

Ah, so if you're installing universal, install with that variant too:

$ sudo port install ffmpeg +slim +universal

[mascguy (Christopher Nielsen)]

Replying to mascguy:

Replying to Liontooth:

It doesn't currently satisfy the ffmpeg dependency of other packages -- but ffmpeg-4.4.4_1+gpl2+universal now also installs without pulling in rav1e

Ah, so if you're installing universal, install with that variant too:

$ sudo port install ffmpeg +slim +universal

Since your other ports are universal, that's why it wants ffmpeg to be universal too. Doing the above should satisfy the dependency for other ports, for your case.

[jgrg (James Gilbert)]

Good news for ffmpeg, but I have a load of other ports I can't install. e.g. The dependency monster that is ImageMagick, and, surprisingly p5-sql-translator which pulls in p5.34-gd > gd2 > libavif > rav1e.

[mascguy (Christopher Nielsen)]

Replying to jgrg:

Good news for ffmpeg, but I have a load of other ports I can't install. e.g. The dependency monster that is ImageMagick, and, surprisingly p5-sql-translator which pulls in p5.34-gd > gd2 > libavif > rav1e.

Yes indeed. And trying to work around this in multiple ports isn't a great approach either. (We'll do it if we have to, but...)

So let's step back a bit, and understand the original goal here: Are you building MacPorts base from source? Or just ports?

[mascguy (Christopher Nielsen)]

On a separate note: We should probably double-check that this port is pulling in the optimal version of the crate for libgit2.

Perhaps it's already fine, and the iconv issues are due to something else. But since we're still spinning on this, it would help to step back, and verify the fundamentals...

[lukaso (Lukas Oberhuber)]

Is it worth reverting the update of rust from 1.70 to 1.71? Is that where the problem is arising? (Will it help?)

[lukaso (Lukas Oberhuber)]

No idea if this thread on a GIMP issue is helpful, but is also a libiconv related issue: ​https://gitlab.gnome.org/GNOME/gimp/-/issues/9818#note_1828061. I hope it helps.

[jgrg (James Gilbert)]

Replying to mascguy:

Replying to jgrg: So let's step back a bit, and understand the original goal here: Are you building MacPorts base from source? Or just ports?

I installed MacPorts base from source, i.e. ./configure --prefix=/Users/jgrg/MacPorts --with-no-root-privileges

I was recompiling my installed ports after moving my machine from to Monterey to Ventura.

[bnoctis (Blair Noctis)]

FYI, I made it work by adding a few lines in its Portfile:

configure.cflags-prepend -I/opt/local/include
configure.cxxflags-prepend -I/opt/local/include
configure.ldflags-prepend -I/opt/local/lib

[jgrg (James Gilbert)]

Thanks, that worked for me.

I added:

configure.cflags-prepend    "-I${prefix}/include"
configure.cxxflags-prepend  "-I${prefix}/include"
configure.ldflags-prepend   "-I${prefix}/lib"

to my Portfile since my prefix isn't /opt/local

[mascguy (Christopher Nielsen)]

Replying to jgrg:

Thanks, that worked for me.

I added:

configure.cflags-prepend    "-I${prefix}/include"
configure.cxxflags-prepend  "-I${prefix}/include"
configure.ldflags-prepend   "-I${prefix}/lib"

Well, it's good that there's an easy fix.

As for how we integrate it though, that's another story: While rav1e itself could be changed, it seems like we should be doing this via portgroups cargo and/or rust.

Adding @cjones for thoughts/comments.

[lukaso (Lukas Oberhuber)]

Replying to mascguy:

Well, it's good that there's an easy fix.

Given there's still debate about a fuller fix, would it make sense to fix this port for the time being? The issue has been open for 2 and a half weeks (and the GIMP nightly build is broken :( ). (Not trying to pressure the wrong solution, just mentioning some of the impact.)

[mascguy (Christopher Nielsen)]

Replying to lukaso:

Given there's still debate about a fuller fix, would it make sense to fix this port for the time being? The issue has been open for 2 and a half weeks (and the GIMP nightly build is broken :( ). (Not trying to pressure the wrong solution, just mentioning some of the impact.)

Agreed, fix forthcoming shortly.

[Christopher Nielsen <mascguy@…>]

In 975883b8e7a0bb0eb688ff4b96e85b4315631da6/macports-ports (master):

rav1e: fix iconv linking issues, for custom prefix

Fixes: #68026

[lukaso (Lukas Oberhuber)]

The fix, very sadly, does not appear to have worked (though I can't be certain because there isn't a new revision). See attached log.

[lukaso (Lukas Oberhuber)]

Build failure since fix uploaded

[mascguy (Christopher Nielsen)]

Replying to lukaso:

The fix, very sadly, does not appear to have worked (though I can't be certain because there isn't a new revision). See attached log.

Lukas, there are multiple back-to-back build attempts in your logfile, which confuses matters a bit.

But ignoring all but the final build, this appears to be a fundamentally different issue. And it may require updating the version of the git2 crate [used by rav1e], now that libgit2 has been updated to 1.7.1:

libgit2/src/util/array.h:59:19: error: no member named 'greallocarray' in 'git_allocator'
        if ((new_array = git__reallocarray(a->ptr, new_size, item_size)) == NULL)
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

libgit2/src/libgit2/annotated_commit.c:34:21: error: no member named 'gcalloc' in 'git_allocator'
        annotated_commit = git__calloc(1, sizeof(git_annotated_commit));
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

libgit2/src/libgit2/annotated_commit.c:48:34: error: no member named 'gstrdup' in 'git_allocator'
        annotated_commit->description = git__strdup(description);
                                        ^~~~~~~~~~~~~~~~~~~~~~~~

[lukaso (Lukas Oberhuber)]

I've now created: #68178

[lukaso (Lukas Oberhuber)]

The rav1e issue is still open: ​https://github.com/xiph/rav1e/issues/3226.

[Christopher Nielsen <mascguy@…>]

In 20dd1dc069d78e41cb7241c91d6f2ad39d0679b5/macports-ports (master):

lib{avif,heif}: add new variant rav1e; disabled by default

See: #68026
See: #68178

[Christopher Nielsen <mascguy@…>]

In c08417569d37bdbd835cbfe77c383c6028082bd8/macports-ports (master):

ffmpeg*: add variant rav1e, disabled by default

See: #68026
See: #68178

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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.