Re: dpkg-cross libidl fix

[Wookey <wookey wookware org>]

+++ Neil Williams [2011-03-16 09:48 +0000]:

This mail copied to orbit-list as place to ask libIDL development
questions.

It currently doesn't cross-build without an autoconf value for
libIDL_cv_long_long_format being supplied. I'd like to agree on a way
to have the upstream configurey DTRT when cross-building, or at least
make a good guess, and not just bail saying "can't".

Further discussion in debian bugrep:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618488

> 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). 

OK. I just checked and '%llu' has _always_ been wrong.
libIDL_cv_long_long_format was introduced in libidl 0.8.1 in 2003 and
has always been of the form
AC_MSG_RESULT(%${libIDL_cv_long_long_format}u)

So there is no need for a version check and dpkg-cross should at least
set this value correctly if it's setting it at all. 

> 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.

Hmm, but glib2.0 has almost the exact same .m4 stuff for this test.
It's just surrounded by a 'if we know this is windows native then
don't bother running the test set it to I64'. For linux it looks like
it should do exactly the same as libIDL. However dpkg-cross does not
have glib_cv_long_long_format defined and glib2.0 ./configure just
sets it to 'none', rather than bailing, so something different is
happening. I dont think 'none' is actually a very good answer though,
and glib falls over a couple of tests later with 
"checking for growing stack pointer... configure: error: in
/home/wookey/debian/squeeze/build/glib2.0-2.28.2/debian/build/deb':
configure: error: cannot run test program while cross compiling
"
so it's not realy doing any better than libIDL here. 

The two ./configure files are somewhat different. I assume that's down
to autoconf generating them differently as the input is extremely
similar.


> 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.). 

In this case 'll' is always the right answer on Linux. I64 is there
for Windows support. I don't know when 'q' might be right.

I think the question here boils down to "when cross compiling who
should be responsible for guessing this value". 

It seems to me that this 'll' is actually a system value and supplying
it in some kind of debian system cache file makes sense, rather than
implementing defaults in every app that used it. The problem there is
that every app uses it under a different name

libIDL_cv_long_long_format 
glib_cv_long_long_format
are exactly the same thing.



> 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.

It's a genuinely useful facility as a mechanism to fix code which
doesn't cross-build properly yet. We are nowhere near being able to
get rid of it yet. I quite agree that these things should be pushed
upstream as much as possible for reasons of maintainability and
remaining synchronised.

> 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.

I'll leave it to upstream to comment on what would be the most
appropriate mechanism for setting this. 

> > > The value we do have is probably only usable for ARM anyway.

Nope. We have the 'linux', or more accurately 'glibc' value. 

> 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.

Do you have any examples of this we can point them at. This is a
2003-vintage test so there is indeed likely to be a 'better way' by
now. 

> I think this bug should be cloned and the clone re-assigned to libidl
> with a view to getting it forwarded upstream. 

I shall certainly clone it. I'm not sure it's clear what the best
solution is yet. 

> 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.

The cache support will need to stay until we've upstreamed all 29
packages currently catered for using this mechanism.

> cross-config.cache is my fault, it's my error and dpkg-cross should
> move away from providing it. It cannot survive Multi-Arch.

I don't agree with that assessment, but this bug report isn't the
place to argue about it. We'll just deal with the libIDL issue here.


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/