On Wed, 16 Mar 2011 01:31:14 +0000 Wookey <wookey@wookware.org> wrote: > +++ Neil Williams [2011-03-15 22:29 +0000]: > > > i.e the % and the u are now not part of libIDL_cv_long_long_format > > > > > > can you fix that upstream? I'll fix it in the ubuntu version. > > > > The change may need to have a version check sorted out somewhere around: > > if [ "$PACKAGE" = "libidl" -o "$PACKAGE_NAME" = "libIDL" ]; then > > I wondered if we could supply values for different versions. That > would indeed be more correct (except that I have no idea what cutoff > version to use). :-( Upstream would know and their VCS will reveal where the value is expanded and hence when the code changed. > > In other words, it's about time that this change and all the others > > like it, get pushed upstream and handled properly. > > How would this be handled upstream? For a configure-time compiled test > which needs to be run on the host arch dpkg-cross cached supply of the > answers is correct is it not? Upstream need to change their m4 support to explicitly handle cross-compiling just like glib do - when cross-compiling, the m4 macros fall back to a set of values which upstream determine based on the $host_alias value. Yes, the m4 can produce a warning and moan about cross-compiling being unsupported or whatever, just as glib does, but upstream have a FAR better understanding of what this value should be and they are the only ones who can ensure that it remains in sync with the rest of their code. dpkg-cross caches are/were *never* the right long term answer - except where the value is absolutely identical across all packages on the relevant architecture (so endianness etc.). Caches need to be expendable, caches need to be temporary and I already regret adding this support to dpkg-cross in the first place. I see no reason for this to survive when dpkg-cross finally merges into the Multi-Arch dpkg. The genuinely architecture-specific config files can merge, the cache cannot. The other choice for upstream is that they change to using #ifdef and other mechanisms in the compile-time code itself, exactly as glib does - or, indeed, change to using glib as a dependency and get this information via glib macros. > > The value we do have is probably only usable for ARM anyway. > > I did wonder about that. It's the same on amd64 so 'll' may be quite > widespread. The other options or 'i' and 'I64' which may well only > apply on strange systems with funny C-libraries. All the more reason for this to be handled upstream in a series of #ifdef sections or by using a library which uses such sections to expose a macro which does the work for them. There are ways to do this, the libidl upstream just need to be told that the current system was never usable, never properly supported and only ever worked due to a series of horrible hacks like dpkg-cross - hacks which are going way quite soon now. This specific test is a solved problem. Numerous libraries already implement precisely this kind of support and do it in ways that do not rely on executing a compiled test during the ./configure. libidl needs to do the same. I think this bug should be cloned and the clone re-assigned to libidl with a view to getting it forwarded upstream. Then I can remove the libidl support and possibly the entire cache support from dpkg-cross (closing this bug in the process) so that it is easier to convince the dpkg maintainers to take the configs which we DO need in dpkg - the actual arch-specific ones, not the package-specific ones which, frankly, I added in error during the development of Crush. cross-config.cache is my fault, it's my error and dpkg-cross should move away from providing it. It cannot survive Multi-Arch. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpuTTcOb89F2.pgp
Description: PGP signature