Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
Am 10.11.2009 um 19:22 schrieb Martin Costabel: > Max Horn wrote: > [] >> (1) Get rid of these UpdateFOO fields completely. Instead, require >> package which have to update config.guess etc. to insert these >> updates >> some other way: By rerunning auto-tools; by adding the correct >> config.guess etc. version as a SourceN (care required to avoid name >> clashes, though), as part of the patch (would lead to pretty big >> patches, though) etc. > [] > >> Personally, I prefer approach (1). > > Ther is a practical problem with this approach: It requires real > maintainer work, not just cosmetics. But if you look at the packages > that use Update fields (a quick grep shows more than a hundred with > UpdateConfigGuess and more than 50 with UpdateLibtool and even a dozen > with UpdateLibtoolInDirs), you see that most of them are very old and > haven't really been maintained for a long time. It will be difficult > to > do more than cosmetic changes in all of these. Indeed, thank you for clarifying this. I was somehow under the (wrong) impression that there are fewer affected packages :/. (Though note that for UpdateLibtoolInDirs, looking at the grep output closer reveals that only 7 packages in unstable actually use it ;). Still too many, of course). Well, then let me propose approach (1'): We don't touch "UpdateFOO" at all, but deprecate it (in the docs, and maybe the validator should print "this is a deprecated field, don't use it"). Code which needs to update config.guess etc. uses one of the approaches suggested in (1) and in other emails in this thread, but *not* UpdateFOO. Cheers, Max -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
Max Horn wrote: [] > (1) Get rid of these UpdateFOO fields completely. Instead, require > package which have to update config.guess etc. to insert these updates > some other way: By rerunning auto-tools; by adding the correct > config.guess etc. version as a SourceN (care required to avoid name > clashes, though), as part of the patch (would lead to pretty big > patches, though) etc. [] > Personally, I prefer approach (1). Ther is a practical problem with this approach: It requires real maintainer work, not just cosmetics. But if you look at the packages that use Update fields (a quick grep shows more than a hundred with UpdateConfigGuess and more than 50 with UpdateLibtool and even a dozen with UpdateLibtoolInDirs), you see that most of them are very old and haven't really been maintained for a long time. It will be difficult to do more than cosmetic changes in all of these. -- Martin -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
Am 09.11.2009 um 19:10 schrieb David R. Morrison: > > On Nov 9, 2009, at 9:54 AM, Peter O'Gorman wrote: > >> >> This is the problem fink now has with its Update* fields. Updating >> the files that will be copied may fix some things, but may break >> others. >> > > Maybe we should introduce new fields for the new updates? With names > like ModernizeConfigGuess, ModernizeLibtool ? > > The idea would be that if you want the 2001 version, you use Update* > and if you want the 2009 version, you use Modernize*. And in 2011 we introduce UseReallyModernConfigGuess, UseReallyModernLibtool ? :) Nah... this seems like the wrong way to go about this. I see two major alternatives to go with. Note that the following is just meant as a *sketch*; I can think of tons of ways to vary each approach myself, and I am sure each of you can think of additional ones. (1) Get rid of these UpdateFOO fields completely. Instead, require package which have to update config.guess etc. to insert these updates some other way: By rerunning auto-tools; by adding the correct config.guess etc. version as a SourceN (care required to avoid name clashes, though), as part of the patch (would lead to pretty big patches, though) etc. Pro: No funky special rare field which requires extra code to handle, and in general makes things more complex. The fink package manager code gets simpler. Con: Somewhat less convenient to use. No problem IMO for the current uses of the UpdateFOO field, but this is a drawback if we want to use this to tackle the "64bit issues". Slight variation: Make a package which contains current versions of config.guess, config.sub, etc., and let things that need those depend on that package. If at some point we need even newer versions, we make a new package. We also could make a package which contains the old fink/update/ versions of the files, and migrate all packages using UpdateFOO to use these, thus allowing us to completely get rid of UpdateFOO. (2) Keep the UpdateFOO fields, but modernize them. That is, extend the values allowed from true/false to a fixed list multiple values indicating the file "version", like this: UpdateConfigGuess: 2009-09-18 For backward compatibility, we'd still allow UpdateConfigGuess: true but treat it as UpdateConfigGuess: 2001-09-13 Pro: Simple upgrade path from the existing system, still flexible enough for us to add support for those funky 128bit config.guess versions and libtool updates which supports OS X 10.7 or whatever ;). Very convenient to use. Con: If we include a specific config.guess version once, we may potentially have to keep it forever, for backward compatibility. We could mitigate it by including code which tells fink that e.g. anything using config.guess 2001-09-13 can safely also use 2001-11-10. Also, this retains the somewhat special UpdateFOO fields, with the implied complexity. Personally, I prefer approach (1). Cheers, Max -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On Mon, Nov 09, 2009 at 10:10:27AM -0800, David R. Morrison wrote: > > On Nov 9, 2009, at 9:54 AM, Peter O'Gorman wrote: > > > > > This is the problem fink now has with its Update* fields. Updating > > the files that will be copied may fix some things, but may break > > others. > > > > Maybe we should introduce new fields for the new updates? With names > like ModernizeConfigGuess, ModernizeLibtool ? > > The idea would be that if you want the 2001 version, you use Update* > and if you want the 2009 version, you use Modernize*. IMO more self-documenting (and less ongoing fink-core headache) to have .info explicitly rerun autotools or copy the files from their private stashes. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On Nov 9, 2009, at 9:54 AM, Peter O'Gorman wrote: > > This is the problem fink now has with its Update* fields. Updating > the files that will be copied may fix some things, but may break > others. > Maybe we should introduce new fields for the new updates? With names like ModernizeConfigGuess, ModernizeLibtool ? The idea would be that if you want the 2001 version, you use Update* and if you want the 2009 version, you use Modernize*. -- Dave -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On 11/09/2009 11:38 AM, David R. Morrison wrote: > > On Nov 9, 2009, at 9:33 AM, Daniel Macks wrote: > >> On Mon, Nov 09, 2009 at 09:19:14AM -0600, Peter O'Gorman wrote: >>> On 11/09/2009 03:11 AM, Martin Costabel wrote: >>> On 10.6/64bit, the 'Update' fields could have a renewed interest, because many packages have config.guess versions that guess wrong. In fact, does there even exist a config.guess that gives the right answer "x84_64-apple-darwin10"? Apple's own version in /usr/share/libtool/config/ doesn't. >>> >>> The config project committed some variation of Jack's patch a while ago, >>> the config.guess that reports x86_64-apple-darwin on 64 bit >>> intel mac systems has probably made it into a few released projects >>> by now. >> >> Any word on when an automake release will have it? Whenever the next automake release is :) I know Ralf (automake maintainer) is presently busy updating all the auto* in gcc and src for gcc-4.5 etc. So I doubt it will be that soon. > > Does this new version work properly when we are trying to compile on > 10.6/32bit? Or does it cause libtool to think that all of the included > libs are supposed to be 64bit, since that is what config.guess reported? config.guess reports x86_64-apple-darwin on 10.6 intel, or if CC='gcc -arch x86_64' CC='gcc -m64' etc. i386 on intel macs otherwise. Upstream libtool uses pass_all for dep libs check method, so it will just give whatever it sees to ld (which will then complain if the arch is wrong). I don't see any problem using the new config.guess in new packages, but blindly using it for older packages has the potential to cause problems. This is the problem fink now has with its Update* fields. Updating the files that will be copied may fix some things, but may break others. Peter -- Peter O'Gorman http://pogma.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On Nov 9, 2009, at 9:33 AM, Daniel Macks wrote: > On Mon, Nov 09, 2009 at 09:19:14AM -0600, Peter O'Gorman wrote: >> On 11/09/2009 03:11 AM, Martin Costabel wrote: >> >>> On 10.6/64bit, the 'Update' fields could have a renewed interest, >>> because many packages have config.guess versions that guess wrong. >>> In >>> fact, does there even exist a config.guess that gives the right >>> answer >>> "x84_64-apple-darwin10"? Apple's own version in >>> /usr/share/libtool/config/ doesn't. >>> >> >> The config project committed some variation of Jack's patch a while >> ago, >> the config.guess that reports x86_64-apple-darwin on 64 bit >> intel mac systems has probably made it into a few released projects >> by now. > > Any word on when an automake release will have it? > Does this new version work properly when we are trying to compile on 10.6/32bit? Or does it cause libtool to think that all of the included libs are supposed to be 64bit, since that is what config.guess reported? -- Dave -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On Mon, Nov 09, 2009 at 09:19:14AM -0600, Peter O'Gorman wrote: > On 11/09/2009 03:11 AM, Martin Costabel wrote: > > > On 10.6/64bit, the 'Update' fields could have a renewed interest, > > because many packages have config.guess versions that guess wrong. In > > fact, does there even exist a config.guess that gives the right answer > > "x84_64-apple-darwin10"? Apple's own version in > > /usr/share/libtool/config/ doesn't. > > > > The config project committed some variation of Jack's patch a while ago, > the config.guess that reports x86_64-apple-darwin on 64 bit > intel mac systems has probably made it into a few released projects by now. Any word on when an automake release will have it? dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On 11/09/2009 03:11 AM, Martin Costabel wrote: > On 10.6/64bit, the 'Update' fields could have a renewed interest, > because many packages have config.guess versions that guess wrong. In > fact, does there even exist a config.guess that gives the right answer > "x84_64-apple-darwin10"? Apple's own version in > /usr/share/libtool/config/ doesn't. > The config project committed some variation of Jack's patch a while ago, the config.guess that reports x86_64-apple-darwin on 64 bit intel mac systems has probably made it into a few released projects by now. Peter -- Peter O'Gorman http://pogma.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
Peter O'Gorman wrote: [] > Feel free to change it in fink's ltconfig, etc., and the problem should > be "fixed" with the next fink release, but really I think that the > 'Update*' fields should be deprecated, in favor of rerunning some > version of autotools. It is true that both packages gtk+ and recode are ancient and have had the 'Update' lines since the days of MacOSX 10.2 (maybe earlier, I didn't look further back). Apparently this didn't hurt until now (and even on 10.6/64bit you don't notice the breakage in the packages themselves, only when something wants to dlopen a binary linked to one of their dylibs.) On 10.6/64bit, the 'Update' fields could have a renewed interest, because many packages have config.guess versions that guess wrong. In fact, does there even exist a config.guess that gives the right answer "x84_64-apple-darwin10"? Apple's own version in /usr/share/libtool/config/ doesn't. -- Martin -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On 11/08/2009 06:07 PM, Martin Costabel wrote: > In the 2 threads "lablgtk 1.2.7-1002 on 10.6 64bit fails to build" and > "python-bibtex-py26-1.2.4-1 build failed on 10.6 64bit" the error was > caused by dylibs not linking with libintl.dylib, > /sw/lib/libgtk-1.2.0.dylib in the first case and > /sw/lib/librecode.0.dylib in the second case. > > Both dylibs do link with libintl on 10.5/32bit (probably on 10.6/32bit, > too). > > The packages gtk+ and recode have in common that they use > > UpdateConfigGuess: true > UpdateLibtool: true > > This brings in particular the extremely old /sw/lib/fink/update/ltconfig > which defines > > deplibs_check_method='file_magic Mach-O dynamically linked shared > library' > It's been pass_all in upstream libtool for several years. Feel free to change it in fink's ltconfig, etc., and the problem should be "fixed" with the next fink release, but really I think that the 'Update*' fields should be deprecated, in favor of rerunning some version of autotools. Peter -- Peter O'Gorman http://pogma.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
[Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
In the 2 threads "lablgtk 1.2.7-1002 on 10.6 64bit fails to build" and "python-bibtex-py26-1.2.4-1 build failed on 10.6 64bit" the error was caused by dylibs not linking with libintl.dylib, /sw/lib/libgtk-1.2.0.dylib in the first case and /sw/lib/librecode.0.dylib in the second case. Both dylibs do link with libintl on 10.5/32bit (probably on 10.6/32bit, too). The packages gtk+ and recode have in common that they use UpdateConfigGuess: true UpdateLibtool: true This brings in particular the extremely old /sw/lib/fink/update/ltconfig which defines deplibs_check_method='file_magic Mach-O dynamically linked shared library' In reality, the 64bit dylibs have "Mach-O 64-bit dynamically linked shared library". The result is that libtool does not recognize that /sw/lib/libintl.dylib is a dynamic library, and it removes it from the linker list, accompanying this deed with the lie *** Warning: This library needs some functionality provided by -lintl. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. Is there a reason why we have these old versions of ltconfig, ltmain.sh etc in fink, versions that date from before the release of MacOSX 10.0? -- Martin -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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
