Re: [Mspgcc-users] New MSP430 GCC version release available!

2015-10-18 Thread Lev Serebryakov
Hello DJ,

Sunday, October 18, 2015, 10:44:10 PM, you wrote:

>>   To be honest, your (RedHat + TI) way is worst possible one :-(
> Worst for your purposes, perhaps.  We just have a different goal - a
> turnkey custom collection that "just works" for our customers.  That
> means we normally include things that wouldn't be included in a system
> package.
  Yep, because my goal is to do system package for yet another system :)

> And BTW I know all about packaging rules, I do after all work for Red
> Hat, we have a distro or two ourselves :-)
 :-)

 Anyway, I'm pleased, that it could be built on BSD system with clang
compiler almost flawlessly. I've remember days, when such package for Agenda
VR3 (did you remember this very first Linuix-based PDA with MIPS-based CPU?)
was hopeless to built anywhere but one distributive of Linux!

 Could you please clear situation with debugging (in separate thread in
mailing list)?

-- 
Best regards,
 Levmailto:l...@serebryakov.spb.ru


--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users


Re: [Mspgcc-users] New MSP430 GCC version release available!

2015-10-18 Thread DJ Delorie

> Agenda VR3 (did you remember this very first Linuix-based PDA with
> MIPS-based CPU?)

Yup, I was involved with the project way back then.

>  Could you please clear situation with debugging (in separate thread in
> mailing list)?

Sorry, that's a TI question, they provide the DLLs and SOs for that.

--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users


Re: [Mspgcc-users] New MSP430 GCC version release available!

2015-10-18 Thread DJ Delorie

>   To be honest, your (RedHat + TI) way is worst possible one :-(

Worst for your purposes, perhaps.  We just have a different goal - a
turnkey custom collection that "just works" for our customers.  That
means we normally include things that wouldn't be included in a system
package.

What you want is an "upstream" collection, broken down by packages,
with the latest greatest of each package.  Over time, the upstream
releases with msp430 support will happen and allow that.  Often we do
releases for customers that can't go upstream right away (usually
because the chips are still NDA, which is obviously not the case for
MSP430 ;) so our workflow is geared towards self-sufficiency.

And BTW I know all about packaging rules, I do after all work for Red
Hat, we have a distro or two ourselves :-)

--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users


Re: [Mspgcc-users] New MSP430 GCC version release available!

2015-10-18 Thread Lev Serebryakov
Hello DJ,

Sunday, October 18, 2015, 9:08:34 PM, you wrote:


>>  Yep, it works, modulo DESTDIR problems, which could be easily patched.
> We've always used a separate --prefix for each release (typically
> /opt/redhat/msp430-YYMMDD/) so we wouldn't notice.
 When it is build for system package (like RPM, DEB or Gentoo Portage) it
should has proper (final) prefix (like /usr/local/ti-gcc-${version}) but
"make install" must place it in "stage" directory for packaging. It is
typically done with DESTDIR (so, destination becomes $(DESTDIR)$(PREFIX),
not just $(PREFIX), and it is supported by all autotools/libtools
projects.

  But, as I say, it is very minor problem, as it could be easily patched by
 me (package maintainer), it is only 3KiB of patches, which is negligible :)

>>  I'm not sure, that toolchain need all these separate tcl and tk
>>  stuff (system already has them!), but it is better than nothing
>>  (though, very Windows-like!).
> No surprise, we support windows :-)
  Yep, I know :)

> And not all Unix-y systems have those, either.  Even Linux is the user
> hasn't chosen to install them yet (which is commonly the case).
 Yes. But typical *IX way is to use package managers for each separate
component. Ideally, all this stuff, which is not MSP430-dependand (build for
host and could be used by many oither packages and programs in same system):

  libgmp
  libmpfr
  zlib
  tcl
  tk
  itlc

 should be mentioned in requirements and installed by means of system
 package manager (rmp, apt-get, Gentoo Portages, NetBSD pkg-src, FreeBSD
 ports, etc). For example, msp430 package contains old versions of gmp and mpfr.
 Are you sure, that packaged versions doesnt have bugs and, may be, even
 security ones?

 IMHO, ideal source-based releasing of toolcahin looks like this:

  (1) List of requirements, like "libgmp > 5.1.0, mprf > 3.1.0" and so on.
  NO SOURCES of all these libraries should be provided, as they are
  SEPARATE projects.

  (2) Links to some official binutils / gcc / gdb RELEASE tarballs (gcc 4.9.1,
  for example).

  (3) Minimal patches for (2), which is msp430-dependant.

  (4) System headers, linker scripts, stuff like this.

  (5) Some script to build toolchain from all parts above
 (unpack-patch-configure-build in proper order).

  It is ideal situation, which allows to package your work for differnet
 distributives in most natural way.

  Second-to-best way is like ARM does: script, which, really, allows to
 build toolchain with system libraries (but binutls/gcc/gdb are packaged as
 whole).

  To be honest, your (RedHat + TI) way is worst possible one :-(

-- 
Best regards,
 Levmailto:l...@serebryakov.spb.ru


--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users


[Mspgcc-users] MSP430 gdb debugging -- is it possible to get it on *BSD?

2015-10-18 Thread Lev Serebryakov
Hello Mspgcc-users,

  What is state of debugging support for MSP430 now?

  Looks like, Linux "full" gcc package contains gdb_agent_console and
 libmsp430.so to support debugging, am I right?

  Now, when I built toolchain for FreeBSD (will be added top ports in next
 few days), I wonder, is it possible to add debugging support? Are
 libmsp430.so and gdb_agent_console strictly closed-sourced or there is some
 possibility to obtain their sources?

  I could sign-off NDA as private person, and distribute these two files in
 binary-only form, if it is needed!

-- 
Best regards,
 Lev  mailto:l...@serebryakov.spb.ru


--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users


Re: [Mspgcc-users] New MSP430 GCC version release available!

2015-10-18 Thread DJ Delorie

>  Yep, it works, modulo DESTDIR problems, which could be easily patched.

We've always used a separate --prefix for each release (typically
/opt/redhat/msp430-YYMMDD/) so we wouldn't notice.

>  I'm not sure, that toolchain need all these separate tcl and tk
>  stuff (system already has them!), but it is better than nothing
>  (though, very Windows-like!).

No surprise, we support windows :-)

And not all Unix-y systems have those, either.  Even Linux is the user
hasn't chosen to install them yet (which is commonly the case).

--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users