Re: [multiarch] Proposal for *-dev packages
Daniel Kobras <kobras@debian.org> writes:
> 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...
Which should result in int64_t for every debian arch. No problem there.
> > > 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.
Which is fine. Just keep it out of the -dev arch: all package. I don't
see a problem with splitting them out.
MfG
Goswin
Reply to: