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

[MacPorts]

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

Comment (by kencu):

 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.

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