was: Mactel 10.4.8 evolution-data-server build failure

[Daniel Ericsson]

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