• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 1149 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Command Line Build on Linux with CCSv5.0.3

FastFourier
Expert 1915 points
Other Parts Discussed in Thread: CCSTUDIO

Hey folks.  I'm trying to get automated builds going on our build server which runs CentOS.  At my desk I develop on Windoze with CCS5.0.3.  When I check in to SVN, a build kicks off on our linux server.  In the past we've struggled to maintain synchronization with makefiles and such.  So we're going to try checking in my workspace and building from the command line.

I found the proper CCSv5.0.3 Linux command line, and I call it, but I get SIGSEGV's.  :(  

 

 

[dsp_developer@build_server demod]# /usr/local/CCS/CCSv503/ccsv5/eclipse/eclipse -noSplash -data ../baseband_workspace -application com.ti.ccstudio.apps.projectBuild -ccs.workspace -ccs.configuration Release -ccs.clean

 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

CCS headless build starting... [Wed Jun 22 12:58:31 EDT 2011]

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


================================================================================

Pre processing...



================================================================================

Building...



(<unknown>:22128): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(<unknown>:22128): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

(<unknown>:22128): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed

(<unknown>:22128): GLib-GObject-CRITICAL **: g_object_get: assertion `G_IS_OBJECT (object)' failed

(<unknown>:22128): GLib-GObject-WARNING **: value "TRUE" of type `gboolean' is invalid or out of range for property `visible' of type `gboolean'

(<unknown>:22128): Gtk-WARNING **: Screen for GtkWindow not set; you must always set

a screen for a GtkWindow before using the window

(<unknown>:22128): Gdk-CRITICAL **: gdk_pango_context_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed

(<unknown>:22128): Pango-CRITICAL **: pango_context_set_font_description: assertion `context != NULL' failed

(<unknown>:22128): Pango-CRITICAL **: pango_context_set_base_dir: assertion `context != NULL' failed

(<unknown>:22128): Pango-CRITICAL **: pango_context_set_language: assertion `context != NULL' failed

(<unknown>:22128): Pango-CRITICAL **: pango_layout_new: assertion `context != NULL' failed

(<unknown>:22128): Pango-CRITICAL **: pango_layout_set_text: assertion `layout != NULL' failed

(<unknown>:22128): Pango-CRITICAL **: pango_layout_set_attributes: assertion `layout != NULL' failed

(<unknown>:22128): Pango-CRITICAL **: pango_layout_set_alignment: assertion `layout != NULL' failed

(<unknown>:22128): Pango-CRITICAL **: pango_layout_set_ellipsize: assertion `PANGO_IS_LAYOUT (layout)' failed

(<unknown>:22128): Pango-CRITICAL **: pango_layout_set_single_paragraph_mode: assertion `PANGO_IS_LAYOUT (layout)' failed

(<unknown>:22128): Pango-CRITICAL **: pango_layout_set_width: assertion `layout != NULL' failed

(<unknown>:22128): Pango-CRITICAL **: pango_layout_get_extents: assertion `layout != NULL' failed

(<unknown>:22128): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed

(<unknown>:22128): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion `GDK_IS_SCREEN (screen)' failed

(<unknown>:22128): Gtk-CRITICAL **: gtk_icon_size_lookup_for_settings: assertion `GTK_IS_SETTINGS (settings)' failed

(<unknown>:22128): Gtk-WARNING **: Invalid icon size 6

(<unknown>:22128): Gtk-CRITICAL **: gtk_icon_theme_load_icon: assertion `GTK_IS_ICON_THEME (icon_theme)' failed

#

# An unexpected error has been detected by HotSpot Virtual Machine:

#

#  SIGSEGV (0xb) at pc=0x001f824f, pid=22128, tid=4159850704

#

# Java VM: Java HotSpot(TM) Client VM (1.5.0_14-b03 mixed mode)

# Problematic frame:

# C  [libgtk-x11-2.0.so.0+0xf724f]  gtk_icon_set_render_icon+0x55f

#

# An error report file with more information is saved as hs_err_pid22128.log

#

# If you would like to submit a bug report, please visit:

#   http://java.sun.com/webapps/bugreport/crash.jsp

#

Aborted

 

 

That doesn't look quite right to me.  Anyone have any bright ideas on how to make the magic happen?

 

  • 0
    Expert 1215 points

    Ya know, that looks a lot like a problem I'm having as well.  Simply trying to get a Windows CCS project building within CentOS, and we still haven't found a workaround.

  • 0
    TI__Guru**** 171104 points

    Hi,

    I had a similar issue when I tried to build my workspace from command line in Ubuntu 10.04 (32 bits) with CCSv5.0.3.

    However, does your workspace build from the IDE? The reason is that I had just updated the tools from 5.0.2 and my workspace was created with this version. I could not build the workspace correctly due to some mismatches on the tools, requiring me to update the compiler versions on the Project options (or point to the install location of the previous ones).

    As soon as the workspace could be built correctly from the IDE, it could also be built from the command line.

    Can you give this a try?

    Regards,

    Rafael

  • 0 in reply to desouza
    Expert 1915 points

    Well, you make a good point.  This workspace and the projects it references were generated in a Windows CCSv5.0.3 IDE.  Then it was checked into Subversion.  Our build server is just a machine in a rack in our server room, running CentOS.  So when I do an SVN commit, it kicks off a build there.  It doesn't have X.  So I can't really pull up the IDE remotely and try to build it.

    Yesterday, I grabbed a CentOS box and put it under my desk and installed CCSv5.0.3 and checked out the SVN project tree.  I tried to open the workspace, but it had myriad errors... and wouldn't ever load it.  I grepped the .metadata folder on a hunch and found lots of references to my c:\svn\[project]\blah\blah\blah tree.  I'm betting it's bombing on all sorts of Windows paths in the workspace.

    But that begs a new question.  While I made each and every path in the projects themselves relative and portable, how can I make the workspace portable as well?

    One of our goals in doing this was to build exactly what I build at my desk.  Lately we had found that certain libs weren't being built from cmake, and we had struggled to keep everything synchronized when I added a new c-file and didn't tell the build team.  So our solution was to just check in the CCS projects and workspace and command-line build my project + all of the projects for libs and such that link it.  We thought this would build exactly what I build, and we'd eliminate the synchronization issue and all of the petting and maintenance of cmake.

    I had a thought about command-line generating the workspace, since it has almost nothing to do with the actual building.  Something like the following...

    1.) Create Workspace from a script.

    2.) Add each project to the workspace.  (Main project + 2 static lib projects.)  Also from the same script.

    3.) Call build on that auto-generated workspace... from the script.

    The problem, however, is that I couldn't find any way to generate a workspace from the command line, and add projects to it.  Is there a CLI for that?

    Also, that gets down to the issue of synchronization with my desk again.  If I add another lib project, then I have to go pet the build server again.  :(  But it would still help.  Any thoughts desouza?

    Thanks for the input Derek.  Glad to know someone else is trying this as well. 

  • 0 in reply to FastFourier
    TI__Guru**** 171104 points

    HI,

    FastFourier said:

    But that begs a new question.  While I made each and every path in the projects themselves relative and portable, how can I make the workspace portable as well?

    Not only a portable workspace, but also OS-agnostic. Unfortunately a solution to both does not seem trivial. Although you are able to define include paths using forward slashes in both systems, some eclipse internal variables may contain backslashes. If you search a typical project you will see the makefile and .mk companion files have backslashes - these are created automatically by Eclipse itself.

    Another detail you must be careful is with upper/lowercase characters in filenames - *nix systems differentiate between these.

    FastFourier said:

    One of our goals in doing this was to build exactly what I build at my desk.  Lately we had found that certain libs weren't being built from cmake, and we had struggled to keep everything synchronized when I added a new c-file and didn't tell the build team.  So our solution was to just check in the CCS projects and workspace and command-line build my project + all of the projects for libs and such that link it.  We thought this would build exactly what I build, and we'd eliminate the synchronization issue and all of the petting and maintenance of cmake.

    Maybe you could use the makefile generated by CCS to build your code with a simple make utility. You will have to parse it and all the *.mk related files and replace any windoze-like shell syntax with the corresponding *nix ones (backslashes and *.* wildcards, for example). I haven't tried this but it could be added as a pre-build step in the checked in project.

    FastFourier said:

    I had a thought about command-line generating the workspace, since it has almost nothing to do with the actual building.  Something like the following...

    1.) Create Workspace from a script.

    2.) Add each project to the workspace.  (Main project + 2 static lib projects.)  Also from the same script.

    3.) Call build on that auto-generated workspace... from the script.

    The problem, however, is that I couldn't find any way to generate a workspace from the command line, and add projects to it.  Is there a CLI for that?

    Also, that gets down to the issue of synchronization with my desk again.  If I add another lib project, then I have to go pet the build server again.  :(  But it would still help.  Any thoughts desouza?

    I could find only one way to create a workspace, which is to create a new dummy project to a non-existing workspace. This and all the other operations listed above can be done via command line. The page below has a description and examples on how to do all these operations:

    http://processors.wiki.ti.com/index.php/Projects_-_Command_Line_Build/Create

    I will keep trying to think about the OS-agnostic workspace/projects and will get back if I have any news.

    Hope this helps,

    Rafael

     

  • 0 in reply to desouza
    Expert 1915 points

    After reading your post, we decided to just stand up a Windows build server.  So we setup a VM on a machine somewhere on our company cloud, and installed CCSv5.0.3.  Now, when I SVN commit, that machine does an automated update and build of all of my relatively-pathed projects.

    While this works, I'd say it's sub-optimal.  I recognize that this is a limitation of Eclipse.  :(  <---- That's my saddest face.

    It would be great if we could light a fire under the Eclipse community to support more portable workspace/project packages.  It would be incredibly valuable to just be able to hand someone a blob and then them be able to use it as is with a simple import step... rather than lots of configuration.

    Dare to dream folks... dare to dream.  *sigh*