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.

still getting errors with X-less builds on CCS 5.3

Older versions of Code Composer Studio have a known issue with display dependence that will cause command line builds to fail on Linux systems that do not have an X server present. The problem was previously discussed in another forum thread which states the issue was fixed in CCS 5.3.

However, I am running CCS 5.3.0.00090 and I still receive the following error when I try to kick off builds with SSH sans X forwarding:

$ /opt/ti/ccsv5/eclipse/eclipse -noSplash -data /path/to/myworkspace -application com.ti.ccstudio.apps.projectBuild -ccs.projects myproject -ccs.configuration myconfig
[huge error trace]
Caused by: org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
at org.eclipse.swt.SWT.error(SWT.java:4387)
at org.eclipse.swt.widgets.Display.createDisplay(Display.java:913)
at org.eclipse.swt.widgets.Display.create(Display.java:899)
at org.eclipse.swt.graphics.Device.<init>(Device.java:156)
at org.eclipse.swt.widgets.Display.<init>(Display.java:497)
at org.eclipse.swt.widgets.Display.<init>(Display.java:488)
at org.eclipse.swt.widgets.Display.getDefault(Display.java:1633)
at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.createProblemsViews(IDEWorkbenchPlugin.java:394)
at org.eclipse.ui.internal.ide.IDEWorkbenchPlugin.start(IDEWorkbenchPlugin.java:351)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)

Running the same build commands in a session with X forwarding enabled works fine. Is there something I am missing here?

  • Kurt Landenberger said:
    The problem was previously discussed in another forum thread which states the issue was fixed in CCS 5.3.

    The link to that thread appears broken. Could you provide the url again? i would like to read that thread to have a better context of the issue.

    Thanks

    ki

  • Ki-Soo Lee said:

    The problem was previously discussed in another forum thread which states the issue was fixed in CCS 5.3.

    The link to that thread appears broken. Could you provide the url again? i would like to read that thread to have a better context of the issue.

    [/quote]

    The link in the original post should be fixed now. In case it's not, the full text of the link is

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/211236/750920.aspx

    Sorry about that.

  • Thanks, I see the thread now.

    I checked the status of the reported bug and it should have been fixed in 5.3.0.

    Does the workaround offered by Jeff also work for you? Just want to confirm that you and Jeff had the same issue.

    Thanks

    ki

  • Ki-Soo Lee said:

    Thanks, I see the thread now.

    I checked the status of the reported bug and it should have been fixed in 5.3.0.

    Does the workaround offered by Jeff also work for you? Just want to confirm that you and Jeff had the same issue.

    Just running xhost + is not a solution because the configuration change itself depends on having an X server started. I am building on a headless system that should not have to keep an X server running all the time. However, Martin's suggestion of starting an Xvfb instance and killing it after does work and is acceptable for my use case.

  • Hi Kurt, 

    I have installed CCS v5.3 RTM (build 90) on a Ubuntu 12.04 and Suse 10.03 box. I then used a terminal to log in and then execute a simple project create and project build commands. I had no issues executing either from command line. I tried starting xterm, which failed as expected.  Ubuntu box gave me some X11 errors if I did not specify -noSplash, but the build was still executed correctly. Ubuntu had an X server physically running, but not for the user that I logged in with. Suse box did not have X server at all.  

    Did you update to 5.3 or install a new copy? 

    Martin

  • MartinS said:

    Did you update to 5.3 or install a new copy? 

    This particular system has only ever had 5.3 installed, but the project itself was originally created on CCSv4 and upgraded to 5.2. I just tried building one of the sample projects from 5.3 (Blink the LED) and that worked without issue. It looks like the issue is with my project files. I'd prefer not to re-create the project and lose all its settings but it looks like that may be what is needed.

  • When importing projects from older versions of CCS, they go through a migration step; this is when internal project files are updated to latest format. Particularly, between 4.x and 5.x there are also some files that get re-named and new ones created. Thus if you have your projects under source control system, then this step might not complete sucessfully, it might be missing some information or require some adjustment. I would first recommend importing your project using CCS GUI, make sure it builds there and potentially checkin modified project files (i.e. .project, .cproject and .ccsproject) and trying command line build again. Once you migrate you will not be able to open them in 4.x. 

    Martin

  • MartinS said:

    When importing projects from older versions of CCS, they go through a migration step; this is when internal project files are updated to latest format. Particularly, between 4.x and 5.x there are also some files that get re-named and new ones created. Thus if you have your projects under source control system, then this step might not complete sucessfully, it might be missing some information or require some adjustment.

    Changes for 4.x - 5.x conversion were already checked in, so the major version change shouldn't be the cause.

    I would first recommend importing your project using CCS GUI, make sure it builds there and potentially checkin modified project files (i.e. .project, .cproject and .ccsproject) and trying command line build again. Once you migrate you will not be able to open them in 4.x. 

    I built and cleaned the 5.2 project files in the GUI, then ran a headless build in the same tree and I got the same issue. The import results in the makefiles being regenerated but the .*project files themselves are not changed by the minor version bump.
  • ok. What type of an error are you getting in 5.3... or what happens when you run the build. Could you attache workspace log file? Workspace directory is specified on the command line and the log is called .log and it should be inside of .metadata folder. 

    martin

  • MartinS said:

    ok. What type of an error are you getting in 5.3... or what happens when you run the build. Could you attache workspace log file? Workspace directory is specified on the command line and the log is called .log and it should be inside of .metadata folder. 

    I'd prefer not to post the build logs on the public site.

    I have decided to take the hit and port the project to plain GNU Make as that seems to offer more flexibility than using Code Composer to build. Creating a CDT Make based project for development tasks in Code Composer is fairly straightforward.