On 11 jan 2007, at 16.56, Fred Dushin wrote:

This is a macports issue, specifically, but I'm canvassing unix- porting for an understanding of libtool. Thanks for your patience.

...

This looks like an old issue. See: http://trac.macports.org/projects/ macports/ticket/9162

If you could file a new ticket with the complete output of `sudo port -dv install evolution-data-server` that would help in figuring out what the problem might be.

I see that someone submitted full log of the build failure (thanks for doing that), but I don't see any movement on the ticket.

Yeah that was me. I figured that was needed since the first one wasn't debug+verbose. It got obscenely large however and I had to gzip it for Trac to accept it as an attachment. I haven't actually tried the build but got the log from rjhansen. For clarification the ticket in question is not the one above but http://trac.macports.org/ projects/macports/ticket/10940.

I've looked into this a bit more. What seems to be happening is that the evolution-data-server includes a shell script called libtool (not to be confused with Apple's libtool), which goes through a list of system paths, constructing a set of hard coded shlibs that ultimately get linked together though gcc. This list includes libiconv out of /usr/lib (2.2) and out of <macports>/lib (2.4). The result is a big call to gcc, where all -l<name>s are replaced with their hard coded paths. Why someone would write a shell script to do what gcc does is beyond me, but hey, this is free software, so quitchyerbitchin.

gcc presumably calls off to the (real) Darwin /usr/bin/libtool, which fails on account of the duplicate symbols (presumably, though libtool does not say that explicitly -- the "errors" are actually reported as warnings). E.g.:

ld: warning multiple definitions of symbol __libiconv_version /usr/lib/libiconv.dylib(iconv.o) definition of __libiconv_version /opt/local/lib/libiconv.dylib(iconv.o) definition of __libiconv_version ... /usr/bin/libtool: internal link edit command failed

There is also another issue with linking against another shlib that's built locally in the evolution-data-server build, again for the same reason. The issue seems to boil down to the fact that / usr/bin/libtool will refuse to link libraries where there is some ambiguity as to which symbols to resolve.

I can get the shlib to link by hand if I remove these libraries from the link line, but of course this just pops up again on the next call to the gnome libtool [sic] shell script.

So... Does anyone know about flags to /usr/bin/libtool, to maybe turn off this behavior (if I understand it correctly). Actually, these would presumably need to be flags to gcc, since the li'l gnome script is calling gcc, not libtool directly.

Not too much time atm. Have a look at the manpages for libtool, ld and gcc. -Xlinker flag to pass arbitary linker arguments to gcc might help here... -multiply_defined <behaviour> will change how the linker treats multiple definitions of symbols. (Heading "MULTIPLY DEFINED SYMBOLS" in ld(1)). - Daniel