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 Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users