Alexander Hansen wrote: > > On Feb 6, 2009, at 8:23 PM, Alexander Hansen wrote: > >> >> On Feb 6, 2009, at 1:50 PM, Jess H. Brewer wrote: >> >>> The compilation failure of libx264-57-shlibs-0.0.20071214-4 >>> and the cascade of associated problems >>> all seem to include the error message >>> >>> failed to load "x264.ico": >>> Couldn't recognize the image file format for file 'x264.ico' >>> >>> That is an icon graphic, is it not? Has anyone checked to see if >>> said file (wherever it may be located) is actually just a corrupted >>> file? >>> People do edit their icons from time to time, especially when new >>> versions come out -- maybe the problem is as simple as an icon file >>> edited with the "wrong" image editor and/or output in the "wrong" >>> format? >>> >>> Please forgive me if this is a dumb suggestion, but I haven't seen it >>> in the Archive. >>> >>> Cheers -- Jess >>> >>> >> >> There has been a relatively extensive discussion of build issues with >> libx264 on fink-beginners: >> >> http://article.gmane.org/gmane.os.apple.fink.beginners/22579/match=libx264 >> >> >> (the resolution hasn't shown up yet, though). >> >> The answer is to run a "fink selfupdate" and update to a newer version >> of shared-mime-info. > > One reason that we knew that it wasn't a problem with a corrupt file in > the source (which definitely could happen--I had to patch a property > list file that generated a non-functional application for wxmaxima-mac > at on point) is that this version of libx264* had been in the > distribution for a while, and initially had built OK. So nothing had > changed in it. >
Perhaps I should switch my subscription to fink-beginners; there doesn't seem to be much of a sophistication gradient between it and fink-users, but I may have missed the nuances of discrimination. Any guidance in this is appreciated. Your suggestion seems to be working, inasmuch as fink update-all is still working through the list of updates that accumulated behind *x264* while that was broken. I presume that update-all carefully determines the order of packages to satisfy dependences smoothly, but since "fink update shared-mime-info" worked, my previous version must have needed updating -- in which case, shouldn't it have been scheduled before *x264* by update-all? That would presumably have avoided this whole bottleneck for everyone in my shoes (10.5.6 on Intel). Can this be forced "manually" or does update-all have its own dynamic algorithm? fink-beginners for me, eh? Thanks for the help! -- Jess ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
