Streaming video use-case example: VideoData for X64 operating system

16 posts / 0 new
Last post
Offline
Last seen: 10 years 2 months ago
Joined: 02/27/2014
Posts: 15
Streaming video use-case example: VideoData for X64 operating system

with assistance from G-d

Shalom,

I am trying to build the example mentioned above in Visual Studio 2013 on my computer (64 bit operating system).

I get the following error: module machine type 'x64' conflicts with target machine type 'X86'.

I understand clearly that the code (of VideoData) is meant for a 32 bit platform, while my operating system is of 64.

I tried changing the "active solution platform" (in Configuration Manager) of the project from win32 to x64,

though it only caused a catastrophe with many errors,

which means that the regeneration of the code needs to be done more properly.

I then noticed that in the ($SOLUTION) directory exists:

...\VideoData\ExampleCode\win32\x64

I guessed that in this directory RTI prepared what needs to make the example run on a 64 bit system,

though there is no documentation to be found explaining how to get to grips with it.

What to do?

Thank-you!

Oriel-Tzvi

rose's picture
Offline
Last seen: 3 years 3 months ago
Joined: 08/22/2011
Posts: 148

Shalom Oriel-Tzvi, 

Sorry for the delay – we don't currently support Visual Studio 2013, which may be causing the problems you are seeing (previous Visual Studio versions are 32-bit).  Can you build with Visual Studio 2012?  

I just tested with Visual Studio 2012 on a 64-bit machine, and that does build and run correctly.

Thank you,

Rose

 

Offline
Last seen: 10 years 2 months ago
Joined: 02/27/2014
Posts: 15

I actually seem to believe it could run on VS 2013 too.

First, I understand that VS2013 is also 32 bit.

Second, the code itself was written for VS2010;

When one opens the code in a later version of Visual Studio,

he has the option of upgrading (or retargeting) the solution (which he should).

So in my case, I upgraded the code straight away - whilst my VS was in 32 bit platform.

Therefore, I restarted the whole procedure; deleted the whole thing, unzipped once more the VideoData directory, and reopened the solution,

this time changing the platform to 64 bit, and only afterwards - upgraded the code.

Surely enough, the error didn't arise...

but it did wake up some other errors...

So I got to understand that it's possible,

only I need to know in which order to open the code.

 

In which way did you open the code in VS2012?

It may be the way to make it running on VS2013 too!

This is how the Output of the Build starts off at this point (if it helps):

 

1>------ Build started: Project: SharedDataTypes, Configuration: Debug x64 ------
1> Generating .cxx files from .idl ...
1> The system cannot find the path specified.

....

Thank-you!

Also I found this important link. It may be very useful, 

 

Visual Studio 2013 Compatibility - http://msdn.microsoft.com/en-us/library/hh266747.aspx

--> How to: Upgrade Visual C++ Projects to Visual Studio 2013

--> How to: Troubleshoot Unsuccessful Visual Studio Project Upgrades

 

rose's picture
Offline
Last seen: 3 years 3 months ago
Joined: 08/22/2011
Posts: 148

Okay!  I think I know what is happening:

The Visual Studio projects contain a custom build tool in the SharedDataTypes project.  This custom build is our rtiddsgen code generator, and the custom build is installed on the VideoData.idl file.  It makes an assumption about the relative location of the .sln file and the .idl files.  This is the custom build line in the SharedDataTypes project:

"$(NDDSHOME)\scripts\rtiddsgen" ..\src\Idl\VideoData.idl -replace -namespace -language C++ -d ..\src\Generated

I think what has happened is that Visual Studio has moved the project directory to the x64 directory, so the path "..\src\Idl\VideoData.idl" is not correct.  Probably the easiest thing is to change that custom build path to ..\..\src\Idl\VideoData.idl and ..\..\src\Generated.

To change this, right-click on the VideoData.idl file, and select Properties.

In the dialog, click on Custom Build Tool | General.

You will see the command line there.  Try changing the path in the command line to see if this works.  

Thank you!

Rose

Offline
Last seen: 10 years 2 months ago
Joined: 02/27/2014
Posts: 15

I tried changing the command line as you said;

At first to:

"$(NDDSHOME)\scripts\rtiddsgen" ..\..\src\Idl\VideoData.idl -replace -namespace -language C++ -d ..\..\src\Generated.

... that not helping, I then entered the full path:

"$(NDDSHOME)\scripts\rtiddsgen" C:\Users\user1\Desktop\RTI_DDS\RiseOnceMore\VideoData\ExampleCode\src\Idl\VideoData.idl -replace -namespace -language C++ -d C:\Users\user1\Desktop\RTI_DDS\RiseOnceMore\VideoData\ExampleCode\src\Generated.

didn't change much.

Only then did I check in the Macros (of the command line) - $(ProjectDir), and there I saw clearly that the path wasn't referring to the x64 directory -

it was referring to ...\VideoData\ExampleCode\win32\

Not giving-up!

 

I noticed that in the Macros (mentioned above) that the $(CodeAnalysisInputAssembly) refers to ..\win32\x64\Debug\SharedDataTypes.lib which doesn't exist - niether there nor anywhere else in the VideoData directory.

same goes to $(CodeAnalysisLogFile), referring to  ..\win32\x64\Debug\SharedDataTypes.lib.CodeAnalysisLog.xml

Similarly: $(CodeAnalysisSucceededFile), $(CodeAnalysisTLogFile), $(DesignTimeIntermediateOutputPath), $(EntityDeployIntermediateResourcePath), $(LocalDebuggerCommand), $(MergedOutputCodeAnalysisFile), $(NativeCodeAnalysisTLogFile), $(PublishDir), $(RunCodeAnalysisInputs), $(TargetFileName).

While many of the listed above are probably referring to directories yet to be created in-the-run (of VideoData application), 

the latter all point to the same enigma: SharedDataTypes.lib - Why is it "no where to be seen"?

In $(MSBuildAllProjects) the "String" of the paths was too long, and therefore cut (not finished), after reaching something like 256 characters (this could be a restriction in the Macros viewer, but worth checking out)

 

rose's picture
Offline
Last seen: 3 years 3 months ago
Joined: 08/22/2011
Posts: 148

The SharedDataTypes.lib file is create after the steps:

  1. Call rtiddsgen to generate .cxx code 
  2. Compile all of the code in the SharedDataTypes project

This would normally create that .lib file in win32\Debug directory, but with your changed build environment it should be created in the win32\x64\Debug directory.

So I would like to check: Can you confirm for me that code generation succeeded?  If it did, there should be files in the SharedDataTypes project such as VideoData.cxx, VideoDataPlugin.cxx, and VideoDataSupport.cxx.  Does the SharedDataTypes project itself think it built successfully? 

Thank you!

Rose

Offline
Last seen: 10 years 2 months ago
Joined: 02/27/2014
Posts: 15

I undestand.

Like I brought above, these are the first lines of the build output:

1>------ Build started: Project: SharedDataTypes, Configuration: Debug x64 ------
1> Generating .cxx files from .idl ...
1> The system cannot find the path specified.

--> seems like practically nothing succeeded.

When looking in the solution explorer, I see that code has been generated for SharedDataTypes (project): VideoData.cxx, VideoDataPlugin.cxx and VideoDataSupport.cxx

(similarly for VideoPublisher and VideoSubscriber) in the Source Files folder,

though there are no files in the Resource Files folder.

Only to make sure we're talking about the same generated files,

the generated that I mentioned here are not in the x64 directory,

only they are in the src directory.

So the problem starts when it comes to compile the code.

rose's picture
Offline
Last seen: 3 years 3 months ago
Joined: 08/22/2011
Posts: 148

The .cxx files are the generated files, and it looks like those were generated correctly.  Can you remove them and re-add them to the project and see if that helps the build?

I am going to see if I can install Visual Studio 2013 on a 64-bit machine to test what you are seeing. (Edit: Haven't been able to do this, yet.)

Thank you!

Rose

Offline
Last seen: 10 years 2 months ago
Joined: 02/27/2014
Posts: 15

I tried removing the source and header files and then readding them. It didn't work either.

I suggest that instead of downloading VS2013 just please tell what steps you did in order to open the code in VS2012.

Starting off with having the zipped VideoData file which is downloaded from the RTI site.

I'm quite convinced that that's all there is to it.

The reason I think as I said is because I understand that the main issue we're dealing with is the upgrading of the code,

neither with the code nor with the VS2013.

Seeing you managed to open the code in your VS2012, that's "good news" for me,

for the main obstacle is already behind you.

I must have simply upacked the code in a different way which lead me to a "wreckage of the package".

rose's picture
Offline
Last seen: 3 years 3 months ago
Joined: 08/22/2011
Posts: 148

There were no extra steps when I built with Visual Studio 2012: it upgraded the project and then built correctly.  I just tested with Visual Studio 2013 (32-bit), and it also worked correctly.

I am now thinking maybe there is a problem with the path to the rtiddsgen code generation tool.  Can you do the following?

  1. Right click on VideoData.idl in the SharedDataTypes project
  2. Select properties
  3. Select Custom Build Tool | General
  4. Change the command line to add the word "echo" at the beginning.  it should now look like this: echo "$(NDDSHOME)\scripts\rtiddsgen" ..\src\Idl\VideoData.idl -replace -namespace -language C++ -d ..\src\Generated
  5. Build SharedDataTypes, and print the output here.  It should look something like:

>  Generating .cxx files from .idl ... 

>  "c:\rti\ndds.5.1.0\scripts\rtiddsgen" ..\src\Idl\VideoData.idl -replace -namespace -language C++ -d ..\src\Generated

>  SharedDataTypes.vcxproj -> C:\Users\rose\VideoData-4\ExampleCode\win32\Debug\SharedDataTypes.lib

Also: If this is still not working and there is no clear reason, you can call rtiddsgen manually to generate code. If you manually generate the code, the project should hopefully get past the point where it is failing.  To run rtiddsgen manually, open up a command prompt, navigate to the win32 directory, and run this command :

c:\your\rti\path\ndds.5.1.0\scripts\rtiddsgen ..\src\Idl\VideoData.idl -replace -namespace -language C++ -d ..\src\Generated

Edit: Even one more thing to try: can you move all the solution and project files from the x64 directory into the win32 directory, reopen the solution, and see if that works?  This really looks like there is some path that is set incorrectly, and it is difficult to tell which one.

Edit 2: Just to double-check: do you have the NDDSHOME environment variable set?

Thank you!

Rose 

Offline
Last seen: 10 years 2 months ago
Joined: 02/27/2014
Posts: 15

Excuse me for taking time to answer - I haven't been feeling to well over the past few days.

Thank-G-d I'm getting better.

I tried adding "echo".

That got it moving.

Still not working, having a different error this time.

Googling the error:-

fatal error C1083: Cannot open include file: 'ndds\ndds.h*': No such file or directory

(* not accurate but it doesn't matter)

I reached this page - http://social.msdn.microsoft.com/Forums/en-US/62f81507-adc2-4dd1-9582-1ae8bf924824/fatal-error-c1083-cannot-open-include-file-windowsh-no-such-file-or-directory?forum=Vsexpressvc

Some clever guy said:

Your Visual Studio installation is corrupted.  Try Repair first.

Told myself - must check this out before anything... !!!

So thank-you for all your help up to now!

People helping out each other is what needs to be seen in our world more and more.

Stretching out a helping hand.

The world will yet get to it's good purpose, which G-d is leading it to, from the creation of mankind.

Hopefully soon

rose's picture
Offline
Last seen: 3 years 3 months ago
Joined: 08/22/2011
Posts: 148

Shalom Oriel-Tzvi, 

 I am glad you are better! I talked to Raz from Matrix, who mentioned that he planned to call you. Were the two of you able to talk?
 
Thank you!
Rose
Offline
Last seen: 10 years 2 months ago
Joined: 02/27/2014
Posts: 15

I downloaded VS2010...

still not working...

I might try once more to face an error at a time...

but something here's wrong,

I should be able to download the code, and run it straight away without having to solve an endless list of problems, isn't that so?!

why does it get so complicated to do something so simple?!

Fernando Garcia's picture
Offline
Last seen: 3 months 3 weeks ago
Joined: 05/18/2011
Posts: 200

Hello Oriel-Tzvi,

Is the error you run into when using VS2010 the same "Cannot open include file: 'ndds\ndds.h*': No such file or directory" you reported in your last post? If this is the case, I think the problem is just that the NDDSHOME environment variable is not set.

You can either set it using the Windows dialog (permament solution):

  1. From the Desktop, right click My Computer and click Properties.
  2. Click Advanced System Settings link in the left colum.
  3. In the System Properties window click the Environment Variables button.
  4. Add a new environment variable for your user called NDDSHOME poiting to C:\path\to\your\ndds\installation\ndds.5.0.0 or whatever the path to your RTI Connext DDS installation is.

Or using command line (volatile solution):

% set NDDSHOME=C:\path\to\your\ndds\installation\ndds.5.0.0
; Launch VS2010 from command line

Please, let me know if setting the NDDSHOME environment variable solves your "fatal error C1083: Cannot open include file: 'ndds\ndds.h*': No such file or directory" error.

Fernando.

Offline
Last seen: 10 years 2 months ago
Joined: 02/27/2014
Posts: 15

(My NDDSHOME environment variable was set)

I redownloaded and repaired Windows SDK 7.1 -still got errors

I redownloaded NDDS software - and retargeted the environment variable - still got errors

I then downloaded the NDDS software for x86 machine (Host and Target), retargeted the environment variable, reunzipped VideoData, built the solution, and it succeeded!

Thank G-d!

Thank-you all!

rose's picture
Offline
Last seen: 3 years 3 months ago
Joined: 08/22/2011
Posts: 148

I am so glad it worked!

Rose