MacOS X vs. libtool

While compiling a software project, I ran into this bug:

ld: warning table of contents of library: ./.libs/libfoo.a not sorted slower link editing will result (use the ranlib(1) -s option)
ld: multiple definitions of symbol _bar

A Google search shows that this bug seems to be specific to Mac OS X.
I tried different libtool versions, but the problem remained. I tried patching libtool with a patch from the Fink people to fix the “libtool convienience library bug” as libfoo is a libtool convienience library, but no luck either.
Anyone out there developing software with libtool on MacOS X who has an idea how to fix this?

3 thoughts on “MacOS X vs. libtool”

  1. I ran into this problems and solved it (i think) with compiling libtool 1.5.2 seperately, but it may be i’m wrong.

  2. Okay, it turned out to be a problem with the project. The MacOS X linker seems to be pickier about duplicate symbols than other Unices’ linker.
    The problem was solved by making the variables static and avoiding “extern” definition.

  3. It’s not a question of MacOS X being pickier. It’s about ANSI C standard. The MacOS X one (and *BSD ones, if I understood what happened) behave correctly. The Linux one links code that according to standard should not link.
    The rule is that there should be only defined variable for simbol, the other ones should be declared extern (but not defined). Of course if you use static everywhere it works, but it probably makes something different from what you wanted.
    Or have I misanderstood?

Comments are closed.