Jump to content
OMRON Forums

IDE 2.0 new project & old project fail


Recommended Posts

I have just installed IDE2.0 at home. My project which builds fine at work fails with:


C:\ABD\PowerPMAC\Robot\Robots\Robots.ppproj(343,5): Error : /usr/local/dtlibs/libppmac/libppmac.so: undefined reference to `__wrap_printf'


All capps fail, if i take them out the project builds.


I created a blank new project to test the install rather than my code. It fails to build with:


C:\Users\BRITNEY\Documents\PowerPmacSuite\FirstGo\FirstGo\C Language\Background Programs\capp1\capp1.c(55,0): Error : 'NANO_5MSEC' undeclared (first use in this function)


If I delete the contents of the main function I get the same error as my work project.


C:\Users\BRITNEY\Documents\PowerPmacSuite\FirstGo\FirstGo\FirstGo.ppproj(113,5): Error : /usr/local/dtlibs/libppmac/libppmac.so: undefined reference to `__wrap_printf'


If I remove the capp (and include cplcs and rti) it builds. What is going wrong?

Link to comment
Share on other sites

  • Replies 8
  • Created
  • Last Reply

Top Posters In This Topic

I agree. The failure listed in the bugzilla report is slightly different and I can accept when you have no device there might be something it can't do at the end (the message should be nicer though - "Local build succeeded, unable to do special final thing as no device connected"). In that case the capp is actually built.


My error I am seeing is during the local build of the capp.


Hmm. The empty example project failed to build with IDE 1.7, too; c.f. http://forums.deltatau.com/bugzilla/show_bug.cgi?id=1111.

Link to comment
Share on other sites

Thanks edlay


The problem with the 2.0 capp template was really an aside. I'm sorry I should have mentioned I am running on 'No Device' so the FW suggestion won't work and the #define comment seems incomplete. I'm sure I will have some questions on this new RT APP feature I can't find in the user guide. For another post...


My main concern was not being able to build my real projects without removing capps. This will hold up my work at some stage. What are the "__wrap_printf" messages complaining about? It must be something configured on my home PC (it works in the office) but where to start?

Link to comment
Share on other sites

You may have to send us a reduced version of your project that you are willing for us to test since we can't repeat it here. Send it to Stephen Milici and he will get it to the right people.


More info on the blank project:


The F/W that matched the 2.0.xx IDE wasn't ready to ship with it so the build issue with NANO_5MSEC.


Why the change in the CAPP template?


A CAPP inherits the priority and scheduling policy of the task that started it.


If you had the CAPP set to run after load:

1. At download from the IDE it was run as a NON RT APP

2. After a SAVE and $$$ it was run as a RT APP with the same priority as the Power PMAC's background task that started it.

Thus if it took a long time to yield to the Linux scheduler the Power PMAC's Background Watchdog triggered for this case but not on an IDE download.

To insure your CAPP is run at a consistent priority and scheduling policy for these two cases it is required that you use the sample code shown in the new blank project. All the sample Example projects have been changed to this format along with the new blank project CAPP which gives you a template of how to do that.

Link to comment
Share on other sites

Thanks again for the help. I can send you a project when I get home tonight. I get the "__wrap_printf" messages on building a blank new project, but I will send the files from the one the IDE created.


Here are some clues (hopefully! I don't begin to fathom the cross-compile/linking architecture):


My suspicion is that something about my PC is not quite "ready". It is the first installation of the IDE it has had (all other 2.0 IDEs I use were upgrades). It has never connected to a device.


I just did a search on my work PC in DT folder. The libppmac.so file containing "__wrap_printf" is in the libppmac465 folder. It is not in the built one in the libppmac folder. I will search the files on my home PC later.


My project is ppc405 at work, will check at home later.




Interesting stuff about the app priorities, not sure yet how this affects us. I guess if we have seen no issues it is OK. Are you going to recommend recoding existing capps to follow this structure? Thanks for the info.

Link to comment
Share on other sites

I have a workaround and another big clue:


The libppmac.so file installed on a fresh PC in the "C:\DeltaTau\Power PMAC IDE\compilers\usr\local\dtlibs\libppmac" folder is 866KB modified 5-Dec-2014. It has a reference to __wrap_printf in it. It is not rebuilt when you build the project.


If I copy the libppmac.so file from the "C:\DeltaTau\Power PMAC IDE\compilers\usr\local\dtlibs\libppmac405" folder (1008KB modified 13-Aug-2014) into the other one my project builds fine.


My one at work seems to rebuild the 'current' library when I build (I assume for the correct target).


There is obviously at least one library problem here, how does this area work? Does it require a device connection to rebuild the target platform rather than the project setting? Why are there subfolders for other platforms? Why does the 465 one have unresolved externals (maybe not linking to another 465 library somewhere).


I'll leave it up to you. I can build my project with this workaround. It shuold be easy to recreate. If you still want me to send any files I can.




Link to comment
Share on other sites

Recoding will guarantee that the C APP is run at the priority and scheduling policy you intended which usually is as a non-RT Linux APP.

If it is started at power-on, it will without the new code run as a RT Linux APP at the same priority as the Power PMAC background tasks which we prefer it not to be.


So yes I would recommend it.

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...