Loïc Minier <[EMAIL PROTECTED]> writes:

> On Sat, Jan 13, 2007, Goswin von Brederlow wrote:
>  Could you complement the above list of arches / unames / personalities
>  combination for powerpc / powerpc64 and sparc / sparc64 if it makes
>  sense?  Does it make sense to support m68k, arm etc. for a 64-bits
>  personality?  Or should this be revisited for bi-arch?

I'm not quite sure but I think powerpc can be both __ppc__ and
__powerpc__ and don't even start about mips with its 12+ abis.

>  Why not test for 32-bits/64-bits instead of defined(__i386__) or
>  defined(__x86_64__)?

Yeah, testing sizeof(long) or sizeof(void*) soulds like a general
solution that circumvents testing for all the archs seperately.

So in pango_get_lib_subdirectory() you would have something like

#if sizeof(long) = 4
    result = "/usr/lib32/pango";
#else
    result = "/usr/lib64/pango";
#endif
    if (access(result ....

and else fallback to /usr/lib/pango.

>> >  Do you intend to conflict with other packages providing pango module
>> >  files?
>> Why would I? With the stat test for /usr/lib32/pango there is no
>> change for any package except for ia32-libs-gtk. Only ia32-libs-gtk
>> would have /usr/lib32/pango and ia32-libs-gtk is the only package with
>> 32bit pango modules for amd64. Nothing to conflict against.
>
>  Hmm, it was simpler for me to unconditionnally prepend the /usr/lib32
>  path before /usr/lib; but it's cleaner to disable /usr/lib when
>  /usr/lib32 is found.

Having it spew out errors for every 64bit and 32bit module on both
64bit and 32bit pango apps respectively would be quite anoying.

>> >  In the initial bug report, you requested support for /usr/lib64 in the
>> >  64-bits pango; first, I don't see an ia32-libs-gtk for 32-bits arches,
>> >  and second, could you give me a list or arches and "defined()" tests
>> >  for these arches?
>> There isn't an amd64-libs-gtk package (yet?) but it is kind of a
>> chicken&egg problem. Without support for /usr/lib64 there can't be
>> one.
>
>  Ok, but we can implement it nevertheless, it's the same amount of work.
>  Could you hand me the relevant arches/"defined()" tests couples?  Of
>  perhaps we can switch to a 32-bits/64-bits test.

Go with a 32/64 bits test.

>> The number of requests for 32bit gtk support for amd64 made us (and
>> ubuntu way before that) create the ia32-libs-gtk package. I haven't
>> seen requests for 64bit gtk support on i386 yet so we can ignore that
>> for Etch. And for Lenny we can hopefully just use multiarch finaly.
>
>  Yeah, I am aware of the high demand and use of this setup; it's a
>  terrible pity that your package went into etch one month ago, and that
>  you file RCs for this support at this point of the release cycle...

Sorry.

>  For lenny, it might also make sense to work on biarch; there are some
>  functional package in the archives, and its support is close to the
>  requests in this report.
>
> -- 
> Loïc Minier <[EMAIL PROTECTED]>

MfG
        Goswin

Reply via email to