On Jan 11, 2011, at 5:45 AM, Daniel E. Macks wrote: > Daniel Johnson <daniel.johnso...@gmail.com> said: >> On Jan 7, 2011, at 7:41 PM, Darren De Zeeuw wrote: >> >>> ld: warning: in /usr/local/lib/libexpat.dylib, missing required >>> architecture x86_64 in file >> >> This is the important line. You have a /usr/local/lib/libexpat.dylib >> which is contaminating the build. Temporarily rename /usr/local and >> try fink rebuild xml-parser-pm5100 again. Having things installed in >> /usr/local/include and /usr/local/lib is almost guaranteed to break >> building of fink packages since /usr/local is in the compiler's >> default search path. > > If TestScript had been run when user built this package, that would > have caught the problem ASAP. It would fail for the package that is > actually broken rather than "successfully" creating a broken package > that leads to failure in other packages later. Time to make -m mode > (or at least activated TestScript) the default mode? > > It seems tht perl-modules are especially susceptible to interference > from /usr/local/lib for the variant matching system-perl. The default > MakeMaker rule explicitly places that -L before -L/sw/lib rather than > the usual problem of "just" gcc not ignoring that location as a > fallback after all explicit -L paths. I wonder if we can hack our > MakeMaker to not do that? And/or push -arch_errors_fatal into some > variable to propagate to the linker? > > dan
Thanks to a patch from dmacks, I've updated extutils-makemaker-pm to not pass -L/usr/local/lib when linking. I've also updated xml-parser-pm to BDep on it so this shouldn't happen again. I'd strongly urge anyone with a perlmod package that uses fink-installed dylibs to BuildDepends on extutils-makemaker-pm%type_pkg[perl] (>= 6.56-3) to avoid /usr/local contamination. Daniel ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel