Hello.
Sorry for not replying that long.
I don't feel ready to work on cross things this times. I've just uploaded
dpkg-cross with maintainer set to debian-embedded, and with interested
people listed in Uploaders.
Please redirect discussion to the list.
Nikita
> On Tue, Apr 18, 2006 at 11:16:17AM +0400, Nikita V. Youshchenko wrote:
> > I think that archtable appeared at some point to add more
> > architectures than dpkg-architecture supports. However, to
> > cross-compile packages for architectures we need these architectures
> > to be supported by
> > dpkg-architecture anyway. So I think the way to go us remove
> > archtable, and make dpkg-architecture to understand additional
> > architectures. Maybe by wrapping dpkg-architecture, or by pushing
> > patch to dpkg-architecture that will make it to consult external
> > tables (so we could easilly add architectures when needed).
>
> dpkg/ostable and dpkg/cputable do have some drawbacks, which need to be
> solved.
>
> > Just adding lines to current dpkg-architecture
> > tables won't fit IMHO, because to define new architectures for
> > dpkg-cross, we have to define more than just architecture name and GNU
> > string.
>
> That's true. However, dpkg-architecture should just consult *other*
> tables, not "additional external" tables, shouldn't it?
>
> I'm concerned about making a chaos of dpkg-architecture, maybe creating
> more infinite recursion traps, etc.
>
> The whole dpkg-cross should get a design plan, before changing anything
> to other tools, such as dpkg-architecture.
>
>
> dpkg-architecture has one advantage over dpkg-cross, which is a also
> disadvantage: It separates CPU and OS type. Currently, it supports
> any combination of the existing CPU and OS type without any additional
> entries, while the internal tables of dpkg-cross allow just a small
> subset of those combinations.
>
> Either cut dpkg-architecture back to the "old" CPU/OS model, which
> dpkg-cross uses, or make dpkg-cross use the "new" CPU/OS model of
> dpkg-architecture.
>
> While this looks very theoretical, this question is essential, because
> it is equivalent to the question whether "i586-mingw32msvc" is
>
> * w32-i386
> or
> * w32-i586
>
> Do we force all i386 and *-i386 Debian architectures to be "i486",
> or is it feasible to map Debian "hurd-i386" to GNU "i486-hurd..."
> and "w32-i386" to GNU "i586-mingw32msvc"?
>
> > > > Btw, does dpkg-cross -b preserve *-config files? Not sure...
> > >
> > > As you tell it ... let's see ...
> > > No, currently it doesn't. It seems to me that *-config scripts
> > > aren't handled by dpkg-cross at all.
> >
> > So dpkg-crosst should be fixed to do detect *-config scripts, maybe
> > patch them, and to put to /usr/$(DEB_TARGET_GNU_TYPE)/bin/
> > Then code that sets up directory for gccross, should symlink existing
> > *-config scripts to gccross temporary directory. This will make cross
> > build to use those.
> >
> > Hopely somebody will do this :).
>
> I'd really like to do this, but I'm still not sure how it should be
> done. If we put e.g. /usr/i586.../bin/sdl-config on top of the PATH,
> a cross compiled program would work, but e.g. a source generator
> would maybe not compile because it takes the wrong sdl-config
> (/usr/i586.../bin/sdl-config instead of /usr/bin/sdl-config)
>
> This is the general problem that I don't understand: How will
> cross compiling an native compiling (e.g. for code generation)
> work together? That's the whole point about the "strip" wrapper,
> and about the internal dpkg-cross.pl tables.
>
> My other question is: Why should gccross patch the sdl-config
> script if it modifies the -L.. and -I.. parameters anyway?
>
> If we don't patch it, it won't matter whether /usr/i5.../bin/sdl-config
> is used, or accidently the (eventually also installed)
> /usr/bin/sdl-config.
>
> Maybe all we need is to tell dpkg-cross to pack /usr/bin/*-config
> as well?
> (BTW, should it package /usr/bin/*.dll as well? You don't need the
> dll file to compile it, and you don't want to run any cross compiled
> program, but if you package it, you may want to put the used DLL
> files into the package as well)
>
> > > > No it should not. It should check the binary arch, and choose
> > > > proper tool.
> > >
> > > Here is a misunderstanding. Of course you first check the arch,
> > > which is then passed as argument $arch to get_tool(). If that $arch
> > > is equal to DEB_HOST_ARCH, one should also have a look at
> > > $crossprefix.
> >
> > Maybe. But won't this will break concept of dpkg-cross 'mode'? Or this
> > is not needed any longer? Don't know.
>
> Here someone should talk to us who is really using the 'mode'.
>
> > > Arghh ... the only solution that doesn't need a complete redesign of
> > > dpkg-cross is to remember the original problem:
> > > Do I use $(crossprefix)ranlib or ranlib?
> > > Exactly this and nothing else does my patch:
> > >
> > > patch-dpkgcross-fix-std_tools_2.diff
> >
> > Ok, committed this to CVS. Maybe not the best thing, but could be done
> > fast :).
>
> As the current version in CVS was "broken", this patch was needed
> anyway. First make it run, then make it better. :-)
>
> > > > It is important to have these parameters constant for a given
> > > > architecture, and not allow to overwrite them for standard
> > > > architectures. This makes depending on -arch-cross packages
> > > > reliable.
> > >
> > > Okay, so the ideal solution would be to ignore dpkg-architecture,
> > > right?
> > >
> > > Of course, it would be even better to make dpkg-architecture use the
> > > tables of dpkg-cross, or to make it more flexible to reflect at
> > > least the default values correctly. But this is completely
> > > unrealistic, isn't it?
> >
> > Not sure. If I'm not mistaken, dpkg maintainers seem to have changed
> > recently, and now are more open to changes than previously. So it
> > could be possible to push cross stuff into dpkg-dev tools, making at
> > least some of dpkg-cross wrappers not necessary.
>
> That would be very nice.
>
> > > This isn't the case. For example:
> > > * %archtable maps "i386" to "i486-linux-gnu",
> > > * `dpkg-architecture -ai386` shows "i486-linux-gnu"
> > > * but $crossprefixtable{'i386'}[0] is "i386-linux-gnu-"
> > >
> > > Why?
> >
> > Because of historical reasons? Fixed, comitted.
>
> So my next questions: Should we use $crossprefixtable{'i386'}[0]
> instead of $archtable{'i386'} ?
>
> > > In addition, the "dpkg-architecture" tables are somewhat too
> > > simplified. If I add w32 to dpkg/ostable, "dpkg-architecture
> > > -aw32-i386" will always return "i486-...". The only change to make
> > > dpkg-architecture use "i586-..." is to add another dpkg/cputype,
> > > too, and refer tp w32-i586 instead of w32-i386. But as this won't be
> > > really a new entry, and will overlap with i386, I really don't like
> > > that situation. dpkg-architecture is simply too inflexible, isn't
> > > it?
> > >
> > > Do you have any idea how I should handle this? Is a new dpkg/cputype
> > > for i586 really justified?
> > >
> > > And what about adding w32 to dpkg/ostable? Should it be included in
> > > dpkg permanently, or should dpkg-cross bypass dpkg-architecture
> > > instead?
> >
> > My opinion on this is that we should either wrap dpkg-architecture, or
> > better push needed changes to dpkg-dev. See above.
>
> This still doesn't solve the main problem: Do we need/want a new CPU
> type or do we want w32-i386 map to i586-mingw32msvc.
>
> (currently, dpkg-architecture maps i386 to the GNU CPU type i486, so
> "dpkg-architecture -aw32-i386" will always say "i486-mingw32msvc"
> instead of "i586-mingw32msvc")
>
> How should this problem be handled in general?
>
> Do we need more Intel CPU types beside i386, or do we need a more
> flexible dpkg-architecture?
>
> > > Anyway, I wrote a patch which adds the correct w32-i386 entries to
> > > %archdetecttable and %crossprefixtable:
> > >
> > > patch-dpkgcross-w32-entries.diff
> >
> > Applied, committed.
>
> These patches currently work only if you set
>
> crossprefix = i586-mingw32msvc-
> crossdir = /usr/i586-mingw32msvc
>
> Otherwise, it would take "i486-mingw32msvc", because of the above
> mentioned design of dpkg-architecture.
>
>
> Greets,
>
> Volker
Attachment:
pgpdDoud3Uh2L.pgp
Description: PGP signature