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. 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. Thanks! -Fred