FS#3313 - [OSX] linking fails to iconv for configure --without-freetype

Attached to Project: OpenTTD
Opened by Ingo von Borstel (planetmaker) - Saturday, 14 November 2009, 11:01 GMT
Last edited by Michael Lutz (michi_cc) - Sunday, 20 December 2009, 15:53 GMT
Type Bug
Category Core
Status Closed
Assigned To No-one
Operating System Mac OS X
Severity Very Low
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Compiling trunk (r18069):

./configure --without-freetype && make
checking libfreetype... disabled
checking iconv... found
checking if iconv has non-const inbuf... yes
checking whether to link to iconv... yes

Undefined symbols:
"_iconv", referenced from:
convert_tofrom_fs(void*, char const*)in unix.o
convert_tofrom_fs(void*, char const*)in unix.o
"_iconv_open", referenced from:
FS2OTTD(char const*)in unix.o
OTTD2FS(char const*)in unix.o
ld: symbol(s) not found

Linking works, if freetype is enabled.

Not sure whether it's an OSX-only issue (OSX 10.6.2)
This task depends upon

This task blocks these from closing
 FS#2782 - [OSX] Port hopelessly outdated 
Closed by  Michael Lutz (michi_cc)
Sunday, 20 December 2009, 15:53 GMT
Reason for closing:  Works for me
Additional comments about closing:  Likely a local problem. Fixing potentially broken libs is out-of-scope.
Comment by Remko Bijker (Rubidium) - Saturday, 14 November 2009, 11:25 GMT
On my Linux system I don't have that error; it doesn't need to link to iconv either. What makes it work when freetype is enabled/fail when it's disabled is beyond me. Probably it has already linked to iconv or so.

Is this specific to an particular flavor; x86, x86_64, ppc, ppc64?
Comment by Remko Bijker (Rubidium) - Saturday, 14 November 2009, 11:31 GMT
Does this happen with 0.7 too?
Comment by Remko Bijker (Rubidium) - Saturday, 14 November 2009, 12:23 GMT
  • Field changed: Summary (linking fails to iconv for configure --without-freetype → [OSX] linking fails to iconv for configure --without-freetype)
  • Field changed: Operating System (All → Mac OS X)
Done some research: in Linux and Solaris 10 iconv is part of glibc, which means you don't even have to link to it. This makes me think that the issue is likely OSX only.
Comment by Ingo von Borstel (planetmaker) - Saturday, 14 November 2009, 12:37 GMT
I tested on x86_64. Compiling the 0.7.x branch fails on my OSX 10.6 completely due to missing fixes which are already in trunk.

testing for 32bit is more difficult... CFLAGS = -m32 produces minilzo errors:
[SRC] Compiling 3rdparty/minilzo/minilzo.c
In file included from /Users/ingo/ottd/trunk/src/3rdparty/minilzo/lzoconf.h:72,
from /Users/ingo/ottd/trunk/src/3rdparty/minilzo/minilzo.h:57,
from /Users/ingo/ottd/trunk/src/3rdparty/minilzo/minilzo.c:1831:
/Users/ingo/ottd/trunk/src/3rdparty/minilzo/lzodefs.h:1079:10: warning: "LZO_CC_GNUC" is not defined
/Users/ingo/ottd/trunk/src/3rdparty/minilzo/lzodefs.h:1427:37: warning: "LZO_CC_GNUC" is not defined

[SRC] Compiling saveload/saveload.cpp
In file included from /Users/ingo/ottd/trunk/src/saveload/../3rdparty/minilzo/lzoconf.h:72,
from /Users/ingo/ottd/trunk/src/saveload/../3rdparty/minilzo/minilzo.h:57,
from /Users/ingo/ottd/trunk/src/saveload/saveload.cpp:1187:
/Users/ingo/ottd/trunk/src/saveload/../3rdparty/minilzo/lzodefs.h:1079:10: warning: "LZO_CC_GNUC" is not defined
/Users/ingo/ottd/trunk/src/saveload/../3rdparty/minilzo/lzodefs.h:1427:37: warning: "LZO_CC_GNUC" is not defined

followed during linking statements that basically every object file is not of the required architecture...
Comment by Ingo von Borstel (planetmaker) - Saturday, 14 November 2009, 15:11 GMT
void, senseless double-post removed. sorry :-(
Comment by Michael Lutz (michi_cc) - Saturday, 14 November 2009, 15:23 GMT
I can't reproduce this on 10.5.8. LDFLAGS does contain -liconv even when doing
./configure --without-freetype. Please post the full output from configure.

For a 32-bit compile you should probably use CFLAGS="-arch i386".
Comment by Ingo von Borstel (planetmaker) - Sunday, 15 November 2009, 08:52 GMT
Find the full configure output attached for ./configure --without-freetype

Generating a diff to my usual configure output (which yields good results) shows these changes to the CFLAGS and LDFLAGS:
CFLAGS = -DWITH_FREETYPE -I/opt/local/include/freetype2
LDFLAGS = -lfreetype -lz
Comment by Michael Lutz (michi_cc) - Sunday, 15 November 2009, 13:38 GMT
Do you have a non-standard iconv in /opt/local/lib or /usr/local/lib? Did you compile
FreeType yourself? Does /opt/local/include/freetype2 by any chance contain iconv.h?

As the LDFLAGS do contain -liconv, the only explanation is that somehow a broken header
or a broken libiconv is picked up. Does "nm libfreetype.dylib | grep iconv" (insert proper
path to FreeType) and the same for any libiconv.dylib on your computer ouput anything?
Comment by Ingo von Borstel (planetmaker) - Sunday, 15 November 2009, 21:02 GMT
I'm using the default installtions of freetype and iconv which come with macports (v. 1.8.1). Thus, yes, they're compiled locally - as any macports installation. But they shouldn't be non-standard.

/opt/local/include/freetype2 does not contain any iconv files nor is it found as include in any of the header files in that dir.

ingo: ~/ottd/trunk> nm /opt/local/lib/libfreetype.dylib | grep iconv
ingo: ~/ottd/trunk> nm /opt/local/lib/libiconv.dylib | grep iconv
00000000000fe780 D __libiconv_version
0000000000018740 T _iconv_canonicalize
000000000000c450 T _libiconv
0000000000016200 T _libiconv_close
0000000000017f30 T _libiconv_open
0000000000018a60 T _libiconv_open_into
0000000000019400 t _libiconv_relocate
0000000000019330 T _libiconv_set_relocation_prefix
000000000000c8f0 T _libiconvctl
000000000000c4a0 T _libiconvlist

Note that the symbols searched for are "just" missing the preceeding "lib" of the actually available symbols.
Comment by Michael Lutz (michi_cc) - Sunday, 15 November 2009, 21:12 GMT
There's your problem, the apple iconv does have those symbols:
$ nm /usr/lib/libiconv.dylib | grep iconv
/usr/lib/libiconv.dylib(single module):
000f5020 D __libiconv_version
0000b892 T _iconv
0001582e T _iconv_canonicalize
0000b8e8 T _iconv_close
000150bd T _iconv_open
0000b8fd T _iconvctl
0000baef T _iconvlist
0000bc8d T _libiconv
0000fe45 T _libiconv_close
00015825 T _libiconv_open
00015fd6 T _libiconv_relocate
00015fc7 T _libiconv_set_relocation_prefix
0000bc96 T _libiconvctl
0000bc9f T _libiconvlist

Either the macports iconv is broken or it's using non-matching header and lib.
The Apple iconv.h e.g. does not contain any reference to libiconv_open, only to
Comment by Ingo von Borstel (planetmaker) - Sunday, 15 November 2009, 21:21 GMT
Thanks. Right... it slipped my previous check in that dir, but it's actually also available and has those symbols...
Having it twice with different symbols certainly doesn't help, but mercurial, subversion, git, etc. all depend on macports. Anyway, but now "just" needs to link the correct iconv... I wonder why it works one way but not another.

I de-activated libiconv which comes with macports. Maybe this can be put somewhere in the readme / or FAQ. Then linking works nicely. Thanks a lot, michi_cc for your patience and your error analysis!

while it solves the linking problem for OpenTTD to disable macport's iconv library (version 8), it brings problems in other places when the programmes linked against that only find mac's (native) iconv library (version 7)....
Comment by Remko Bijker (Rubidium) - Monday, 16 November 2009, 10:43 GMT
I think the 'problem', or rather the reason why it works with freetype, is that freetype passes the path to its library to the linker and then the linker sees the macports library first. For the headers it apparantly takes the macports header over the Apple header.

Is there some iconv-config or so that we might look for? If it exists use the information from that, otherwise use the current detection mechanism.
Comment by Tyler (tyler) - Friday, 20 November 2009, 20:05 GMT
I can't reproduce on 10.6.2. I have both Apple's and Macports' libiconv installed, and I see the difference in the symbols as posted above, but even when telling configure explicitly to link to one or the other (--with-iconv=/usr/ and --with-iconv=/opt/local/) it links successfully. There's no iconv-config as far as I can tell, so I guess our options are either: a) leave this as won't-fix and expect people who are compiling to be able to figure it out on their own or b) [comedy option] change all instances in unix.cpp of "iconv" to "libiconv" since it seems that that set of functions is supported across the board.
Comment by Remko Bijker (Rubidium) - Friday, 20 November 2009, 20:09 GMT
Does that work with all Apple SDKs? Especially the 10.4u one?
Linux's iconv doesn't have libiconv functions, so 'just' replacing won't work.
Comment by Michael Lutz (michi_cc) - Friday, 20 November 2009, 20:14 GMT
It's actually the opposite as far as I can see. 10.4u iconv.h has a define
one can enable to turn on libiconv_... and friends, but this switch seems
to be missing in the 10.5 SDK.
Comment by Tyler (tyler) - Friday, 20 November 2009, 20:43 GMT
Yeah, I didn't think that was a viable solution. At any rate, it seems like this is an issue with the setup of whoever's doing the compilation, not a bug in the app itself. I think a note in the wiki like we have is sufficient, since we can assume most Mac users aren't compiling from source.
Comment by Michael Lutz (michi_cc) - Sunday, 20 December 2009, 15:51 GMT
I had a look at this again with my (fake) 10.5, and it seems to work as expected.
Both /opt/local/include and /opt/local/lib are searched before /usr/local and
thus matching includes and lib should be found. Looks very much like a
specific problem with your setup.

I'm going to close this bug, request a reopen if you have new information.