On Feb 7, 2009, at 9:32 AM, Jess H. Brewer wrote: > 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? >
In this case, libx264 doesn't have a versioned dependency on shared- mime-info (perhaps it should). Without a versioned dependency, the algorithm says "any version is as good as any other", and so if you have A depending on B, and have _some_ version of B, then A may get built first even with an update to B. I don't recall what the default ordering of update-all is--possibly alphabetical. > fink-beginners for me, eh? Not necessarily: I just happened to know that the thing worked before because it was already on my systems at the time the breakage showed up. > > > 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
