Re: [Mspgcc-users] New MSP430 GCC version release available!
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!
> 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!
> 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!
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?
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!
> 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