Re: [PATCH 0 of 1] Remove use of companion libs for binutils

[Mike Frysinger <vapier at gentoo dot org>]

On Monday, August 23, 2010 03:30:43 Yann E. MORIN wrote:
> On Monday 23 August 2010 09:17:57 Mike Frysinger wrote:
> > speaking of gdb, i see you miss the optional expat dependency.  newer
> > versions have support for describing target memory via xml among other
> > things.
> 
> Patch? ;-)

sorry, cant say ive used crosstool-ng before or have plans on ever using it.  
nothing personal of course ... it's just that the tools i have already (Gentoo 
+ crossdev) can do everything crosstool-ng does and more.

> > going further, i'm a bit surprised you dont have pdcurses in
> > companion_libs as this is necessary/useful for Windows targets.  using
> > gdb under Windows really sucks without curses support.
> 
> Yes, PDcurses is in there already, but it's in the mingw32 scripts. I
> already suggested moving it to the companion libs, and it's on the TODO
> list.
> 
> Basically, the companion libs were intended for the host, not the target,
> while PDcurses is definitely for the target. But in the end, there are a
> bunch of companion libs, both for host and target, and there is no hard
> reason for differentiation.

mmm i think you're mixing up "host" and "target" a bit.  if i'm doing a 
canadian build (build==x86_64-linux host=mingw target=bfin-linux), then 
pdcurses is for the host.  i guess if you're doing host=mingw target=mingw, 
then pdcurses can be considered for both the host and target.

> > and on an unrelated note, you can find a git repo of elf2flt here:
> > 	http://blackfin.uclinux.org/git/?p=users/vapier/elf2flt.git
> > 
> > should be nicer than CVS from uclinux.org
> 
> That tree is definitely a mirror of the CVS tree. The CVS tree is
> considered the real upstream, and I'd rather base the scripts on the real
> upstream (no matter how close the mirror tree follows).

i'd point out that the "real upstream" uclinux.org website refers to my git 
tree, and most of the recent elf2flt commits have come from that git tree, but 
eh.  your choice.

> And I'd definitely prefer to have tarballs rather than use some
> (pseudo-)random tree snapshots...

which the gitweb interface provides ...
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.