On Thu, Feb 14, 2013 at 11:23:24PM +0100, Martin Costabel wrote:
> On 14/02/13 17:57, Alexander Hansen wrote:
>> On 2/14/13 7:24 AM, Jack Howarth wrote:
>>> Thomas,
>>> I am seeing the same failure with undefined symbols on fink 10.6 under
>>> Xcode 4.2. I believe you
>>> need to add the following change which eliminates the linkage failures here.
>
> I do not believe you when you say you had the same error as the one
> reported here by Fabio Diaolio and you fixed it as you claim you did. I
> does not make sense.
>
> The macports bugreport is different, it is in fact the opposite of what
> has been reported here. Look closely at the missing symbols. They are
> not the same.
>
> In their case, there was in fact a -L%p/lib missing on the link line. In
> our case, this is not missing, and the error message indicates indeed
> that the linker picked up Fink's libiconv.dylib (which has
> _libiconv_open) and not /usr/lib/libiconv.dylib (which has _iconv_open).
>
> In our case, the problem was not at the linker stage, but at the
> compilation stage, where a wrong iconv.h was picked up.
>
> []
>>> This hack has been used by MacPorts for the last three years to eliminate
>>> the same problem
>>> with libiconv symbols.
>>>
>>> https://trac.macports.org/changeset/57665/trunk/dports/textproc/doxygen/Portfile
>>> https://trac.macports.org/ticket/20415
>
> Not the same.
>
>>> Thanks in advance for fixing this.
>>> Jack
>>>
>>
>> Seems like a good idea to me. I've added this with a slightly different
>> implementation. I also didn't do a rev-up because even without this
>> change doxygen built for me and linked to Fink's libiconv.
>
> Pure voodoo. It is inoffensive (a no-op), so if it contributes to
> someone's peace of mind, leave it there.
Martin,
I suspect the need for this hack might just be broken linkers on some
Xcodes. Without
the MacPorts' hack, I had to resort to removing -Wl,-search_paths_first from
TMAKE_LFLAGS.
This is equally bizarre since according to the ld manpage in Xcode 4.2 Build
4C199...
-search_paths_first
This is now the default (in Xcode4 tools). When processing
-lx the linker now searches each directory in its
library search paths for `libx.dylib' then `libx.a' before the
moving on to the next path in the library search
path.
this is already the default so adding it should be a no-op and removing it
should have no effect on the linker.
Jack
>
> --
> Martin
>
>>
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Fink-users mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
