[MacPorts] #60938: exiv2 @0.27.3_0: undefined symbols _libiconv

[MacPorts]

#60938: exiv2 @0.27.3_0: undefined symbols _libiconv
----------------------+------------------------
  Reporter:  parafin  |      Owner:  ryandesign
      Type:  defect   |     Status:  assigned
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.6.3
Resolution:           |   Keywords:
      Port:  exiv2    |
----------------------+------------------------
Description changed by parafin:

Old description:

> exiv2 0.27.3_0 fails to build with the following error:
> {{{
> :info:build Undefined symbols for architecture x86_64:
> :info:build   "_libiconv", referenced from:
> :info:build
> Exiv2::convertStringCharset(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> >&, char const*,
> char const*) in convert.cpp.o
> :info:build   "_libiconv_close", referenced from:
> :info:build
> Exiv2::convertStringCharset(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> >&, char const*,
> char const*) in convert.cpp.o
> :info:build   "_libiconv_open", referenced from:
> :info:build
> Exiv2::convertStringCharset(std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> >&, char const*,
> char const*) in convert.cpp.o
> :info:build ld: symbol(s) not found for architecture x86_64
> }}}
>
> Full build log is attached.
>
> The problem seems to be that exiv2 finds and links to system libiconv,
> which uses iconv prefix for exported symbols instead of libiconv. But
> libiconv installed by macports uses libiconv prefix and its header gets
> pulled into include path before system one it seems. I'm not sure how/why
> it worked before... When building manually this doesn't happen, so maybe
> new macports version (it got upgraded from 2.6.2 to 2.6.3) now force
> /opt/local/include into include path?..

New description:

 exiv2 0.27.3_0 fails to build with the following error:
 {{{
 :info:build Undefined symbols for architecture x86_64:
 :info:build   "_libiconv", referenced from:
 :info:build       Exiv2::convertStringCharset(std::__1::basic_string<char,
 std::__1::char_traits<char>, std::__1::allocator<char> >&, char const*,
 char const*) in convert.cpp.o
 :info:build   "_libiconv_close", referenced from:
 :info:build       Exiv2::convertStringCharset(std::__1::basic_string<char,
 std::__1::char_traits<char>, std::__1::allocator<char> >&, char const*,
 char const*) in convert.cpp.o
 :info:build   "_libiconv_open", referenced from:
 :info:build       Exiv2::convertStringCharset(std::__1::basic_string<char,
 std::__1::char_traits<char>, std::__1::allocator<char> >&, char const*,
 char const*) in convert.cpp.o
 :info:build ld: symbol(s) not found for architecture x86_64
 }}}

 Full build log is attached.

 The problem seems to be that exiv2 finds and links to system libiconv,
 which uses iconv prefix for exported symbols instead of libiconv. But
 libiconv installed by macports uses libiconv prefix and its header gets
 pulled into include path before system one it seems. I'm not sure how/why
 it worked before... When building manually this doesn't happen, so maybe
 new macports version (it got upgraded from 2.6.2 to 2.6.3) now force
 /opt/local/include into include path?.. But given that libiconv is in
 exiv2 dependencies I guess the intention is to use libiconv from ports?..

--

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