Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#60938 closed defect (fixed)

exiv2 @0.27.3_0: undefined symbols _libiconv

Reported by: parafin Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.6.3
Keywords: Cc: michaelld (Michael Dickens)
Port: exiv2

Description (last modified by parafin)

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

Attachments (1)

main.log (147.1 KB) - added by parafin 4 years ago.
build log

Download all attachments as: .zip

Change History (7)

Changed 4 years ago by parafin

Attachment: main.log added

build log

comment:1 Changed 4 years ago by parafin

Description: modified (diff)

comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: michaelld added
Status: assignedaccepted

I doubt anything in MacPorts base changed that relates to this. It seems more likely to me that a change in cmake has caused this. Your log (and mine) also show that it's now finding macOS versions of zlib instead of the MacPorts one, yet it's still finding MacPorts expat.

comment:3 Changed 4 years ago by kencu (Ken)

similar thing just happened here in another port 60919

comment:4 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: acceptedclosed

In 459d817870bed7e0d97199444cbac1b13c392e63/macports-ports (master):

exiv2: Use MacPorts libiconv and zlib

Closes: #60938

comment:5 Changed 4 years ago by michaelld (Michael Dickens)

In bc5236adc362f024aebd41ca198130bc40db49d0/macports-ports (master):

cmake: tweak patch to more appropriately set CMAKE_SYSTEM_PREFIX_PATH

==> prepend MacPorts' prefix instead of appending it

Should fix issues such as #60951 , #60938 , #60896 ; without having to set ZLIB_ROOT and other variables

comment:6 in reply to:  4 Changed 4 years ago by michaelld (Michael Dickens)

Replying to ryandesign:

In 459d817870bed7e0d97199444cbac1b13c392e63/macports-ports (master):

exiv2: Use MacPorts libiconv and zlib

Closes: #60938

@kencu @ryandesign can you test by removing this commit & see if this port now works? It does for me now. If so, let's revert this commit since it is no longer needed.

Note: See TracTickets for help on using tickets.