was: Mactel 10.4.8 evolution-data-server build failure

[Fred Dushin]

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