Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
DorpsGek opened this issue Nov 14, 2009 · 18 comments
Closed

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

DorpsGek opened this issue Nov 14, 2009 · 18 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

planetmaker opened the ticket and wrote:

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)

Reported version: trunk
Operating system: Mac OS X


This issue was imported from FlySpray: https://bugs.openttd.org/task/3313
@DorpsGek
Copy link
Member Author

Rubidium wrote:

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?


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6946

@DorpsGek
Copy link
Member Author

Rubidium wrote:

Does this happen with 0.7 too?


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6948

@DorpsGek
Copy link
Member Author

Rubidium wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6950

@DorpsGek
Copy link
Member Author

planetmaker wrote:

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


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6951

@DorpsGek
Copy link
Member Author

planetmaker wrote:

void, senseless double-post removed. sorry :-(


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6954

@DorpsGek
Copy link
Member Author

michi_cc wrote:

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


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6955

@DorpsGek
Copy link
Member Author

planetmaker wrote:

Find the full configure output attached for ./configure --without-freetype

EDIT:
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

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6960

@DorpsGek
Copy link
Member Author

michi_cc wrote:

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?


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6961

@DorpsGek
Copy link
Member Author

planetmaker wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6963

@DorpsGek
Copy link
Member Author

michi_cc wrote:

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


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6964

@DorpsGek
Copy link
Member Author

planetmaker wrote:

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.

EDIT:
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!

EDIT2:
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)....


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6965

@DorpsGek
Copy link
Member Author

Rubidium wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6966

@DorpsGek
Copy link
Member Author

tyler wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6977

@DorpsGek
Copy link
Member Author

Rubidium wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6978

@DorpsGek
Copy link
Member Author

michi_cc wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6979

@DorpsGek
Copy link
Member Author

tyler wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment6980

@DorpsGek
Copy link
Member Author

michi_cc wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313#comment7091

@DorpsGek
Copy link
Member Author

michi_cc closed the ticket.

Reason for closing: Works for me

Likely a local problem. Fixing potentially broken libs is out-of-scope.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3313

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant