Using cygwin for building with TI-Tools

Thanks to the moderator for moving my post to the appropriate forum.

Now that I'm in the right spot, I see many people use Cygwin, but none seem to have the same problem as me.  For those using Cygwin, did you do anything special beyond resolving paths?  I had to get tool execution paths right, include paths right, and library paths right.  Once I did that, my code compiled and linked.  But the binary crashes on the platform.

I'm using the latest GNU make available on Cygwin, but I can't imagine that matters.

Thanks,

Charles

Charles,

I personally haven't built code much with Cygwin, however I will try to offer my comments/suggestions.Are you saying that the project when built with the DOS batch file works fine, but the same project built with cygwin does not? If so, I would suggest double-checking that all source files, versions of tools (including compiler tools and BIOS) and build options match up between the two builds. A change in any of these will result in a difference in the executable output.

If you're interested further to look at the differences between the executables from the two builds, you could try a utility called objdiff. It is part of a package of post-processing scripts, which is described in detail and available for download here: http://processors.wiki.ti.com/index.php/Code_Generation_Tools_XML_Processing_Scripts. It will compare just the relevant portions of the code that are downloaded to target and not the debug information, for example.

Hi,

Thanks for the pointer to objdiff.  We don't have this, but are looking forward to trying it.

To clarify the situation, let me summarize:

1) DOS batch file sets up a bunch of environment variables then call gmake.  The makefile for this is poorly written and hard to add new source files to.

2) I completely rewrote the makefile, using all the handy tricks in the GNU make manual.  I have gone through the verbose build output verifying that the compiler is invoked with the same options.  Builds do complete successfully - every source compiles; the result can then be linked.

3) Neither the binary output nor the hex6x output match.

Anyway, we will try objdiff and report back here.

Thanks,

Charles

I suspect you would have introduced bug(s) while rewriting the Makefile. Can you cross check if you have taken care of all the dependencies. And while porting a gMake based project to Cygwin i suggest you to do it progressively.

Hi,

We found the problem but don't quite understand what's going on.  We omitted the "-c" option on the linker command line.  My fault; I am more familiar with gcc and the use of "-c" there.

Still wondering what "-c" does when just compiling to obj files (no linking).  We don't use C_OPTION or C6X_C_OPTION; does "-c" do anything at all when compiling to an object file?

Charles

Charles,

In the TI code generation tools, both the compiler and linker support a "-c" option. When passed to the compiler, it is equivalent to "--compile_only" and means that the source files are only compiled and linking is disabled. When passed to the linker (ie if it appears after the -z option on command line), it is equivalent to "--rom_model" and sets the model for autoinitialization of variables to initialize at run time.

If this option is in the linker command file it should be the one passed to the linker, and will affect how the code runs.

More details on both the compiler and linker options can be found in the C6000 Compiler users Guide and Assembly language Tools Users Guide.
http://processors.wiki.ti.com/index.php/TI_Compiler_Information#Compiler_Manuals
Look for the --compile_only option in the Compiler Guide and --rom_model option in the Assembly Language Tools Guide.

Charles,

"Still wondering what "-c" does when just compiling to obj files (no linking).  We don't use C_OPTION or C6X_C_OPTION; does "-c" do anything at all when compiling to an object file?"

If its just about compiling to obj files "-c" doesnt have any effect.