Re: [multiarch] Proposal for *-dev packages
On Thu, Jan 15, 2004 at 10:50:39AM +0100, Goswin von Brederlow wrote:
> Daniel Kobras <kobras@debian.org> writes:
> > I don't see why it would make sense to re-run configure on a user's
> > system when the information is already present at compile/configure
> > time. And I don't see the stupidity in
> >
> > foo.h:
> > /* Want to be portable to systems w/o int64_t */
> > typedef long foo_int64;
>
> Thats just plain wrong on 32bit systems. You need an #ifdef construct
> there already, you have to check the size of long at some point.
That's precisely the point. I'm talking about configure here, so foo.h
would be auto-generated from
foo.h.in:
typedef @FOO_INT64_T@ foo_int64;
Thought that was obvious...
> > foo.pc:
> > Libs: -L${libdir} -lpthread
> >
> > You're trying to shoehorn data into binary-all that is inherently
> > architecture dependent.
>
> foo.pc files aparently are in /usr/lib/, that means they go to
> /usr/lib64/ for 64bit multiarch. But even though there is no
> architecture dependend information in your example.
In fact it is, and that's why I chose this example. Looks innocent, but
there are at least 12 different ways you have to link with pthreads on
different architectures. Furthermore, just because you link with libfoo
on x86 doesn't necessarily mean you have to link with it on ppc. Might
be an optimized x86-only lib, for instance.
> That foo.pc file could be copied or linked to both places in the -dev
> arch: all package.
But one does not know the contents of foo.pc for architecture bar before
the package has been built on that arch.
Daniel.
Reply to: