Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Getting started - two issues building!
10-09-2014, 01:50 PM (This post was last modified: 10-09-2014 01:51 PM by MnM.)
Post: #1
Getting started - two issues building!
Hi,

I'm trying to build ohNet for the first time and I'm seeing two different issues, one if I run "make all", and another if I run (cleanly) "make ohNet.net.dll".

If I run "make all" then compilation runs for a while but ends when trying to compile Http.cpp, with the message "'min' : is not a member of 'std'".

If instead I run "make ohNet.net.dll" then compilation immediately fails with the message "Unexpected error creating debug information file c:\openhome\ohNet\Build\Obj\Windows\release\ohNet.net.PDB' -- 'c:\openhome\ohNet\Build\Obj\Windows\release\ohNet.net.pdb: The system cannot find the path specified."

This is on my Windows 7 SP1 64 bit desktop. Make detects a 32 bit compiler, though I see identical behaviour if I run with (having first generated makefiles for) openhome_architecture=x64. I am running Visual Studio Express 2013 Update 3 for Windows Desktop. The first few steps I took were:

Clone the git repo to C:\openhome\ohNet
Open the Visual Studio command prompt and go to above directory
Run "make generate-makefiles uset4=yes" - no problems
Run "make GenAll uset4=yes" - no problems
Run "make" - here's the start and the end of the console output:

Code:
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Detected 32-bit compiler.
Building for system Windows, architecture x86, configuration Release
        if not exist Build\Obj\Windows\Release mkdir Build\Obj\Windows\Release
        if not exist Build\Include mkdir Build\Include
        if not exist Build\Include\OpenHome mkdir Build\Include\OpenHome

...

        cl /nologo /FoBuild\Obj\Windows\Release\FileStream.obj -c /MT /Ox /W4 /EHsc /FRBuild\Obj\Windows\Release\ -DDEFINE_LITTLE_ENDIAN -DDEFINE_TRACE -D_CRT_SECURE_NO_WARNINGS /WX -IBuild\Include OpenHome/FileStream.cpp
FileStream.cpp
        cl /nologo /FoBuild\Obj\Windows\Release\Globals.obj -c /MT /Ox /W4 /EHsc /FRBuild\Obj\Windows\Release\ -DDEFINE_LITTLE_ENDIAN -DDEFINE_TRACE -D_CRT_SECURE_NO_WARNINGS /WX -IBuild\Include OpenHome/Net/Globals.cpp
Globals.cpp
        cl /nologo /FoBuild\Obj\Windows\Release\Http.obj -c /MT /Ox /W4 /EHsc /FRBuild\Obj\Windows\Release\ -DDEFINE_LITTLE_ENDIAN -DDEFINE_TRACE -D_CRT_SECURE_NO_WARNINGS /WX -IBuild\Include OpenHome
/Http.cpp
Http.cpp
OpenHome/Http.cpp(1056) : error C2039: 'min' : is not a member of 'std'
OpenHome/Http.cpp(1056) : error C3861: 'min': identifier not found
OpenHome/Http.cpp(1057) : error C2039: 'min' : is not a member of 'std'
OpenHome/Http.cpp(1057) : error C3861: 'min': identifier not found
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\cl.EXE"' : return code '0x2'
Stop.

I've looked at C:\openhome\ohNet\OpenHome\Http.cpp and those lines were added in January so they're surely not the issue. I am wondering whether my problem is at all related to the text at the foot of this page:

Quote:ohNet is written using C++ with std::string replaced by special buffer classes. These buffer classes allow for more efficient use of memory at the cost of a steeper learning curve. Memory use benefits can be especially pronounced for the Device stack. API docs for this version of the stack are available but the buffer classes are intended for internal use of the library and are as such currently undocumented.

That might give a clue about the first issue but I've really no idea about the second, apart from noticing that PDB is in upper case in one part of the error message and in lower case in another.

Can you suggest what I might be missing, for both issues?

Thanks very much,

Matthew
Find all posts by this user
10-09-2014, 04:13 PM
Post: #2
RE: Getting started - two issues building!
Welcome to the forum Matthew!

The build error in Http.cpp is caused by a missing include (of <algorithm>). We presumably get away with this by chance on other builds, relying on includes of other standard library headers, including algorithm indirectly. I've fixed this locally.

Fixing this gets the build farther but not yet working. The next error is in the OS porting layer which uses a function that has been deprecated by VS2013. I've fixed this locally too.

I'd hope that the error building ohNet.net.dll is caused by some missing dependencies for that build target. If that is the case, a single successful build of everything (via make) should fix things... If that isn't the case, you could try editing the debug_csharp declaration around line 33 of OhNet.mak and editing (or just removing) the /debug:pdbonly section.

My local changes should be pushed to github this evening (pending successful runs of our nightly tests). Please let us know if any build problems remain after this.
Find all posts by this user
10-09-2014, 07:21 PM
Post: #3
RE: Getting started - two issues building!
Thanks!

I'm going to try to build a DS alarm clock. I've been teaching myself C# so it's quite exciting to get going, and slightly daunting Smile

The repo has updated and I'm building everything again now. It has got much further but complained when trying to bundle:

Code:
File "bundle_binaries.py", line 95
    print "Too many arguments."
                              ^
SyntaxError: invalid syntax
NMAKE : fatal error U1077: 'C:\Python33\python.EXE' : return code '0x1'
Stop.

I'll see if it's down to my setup and report back.

Meanwhile, I've found the problem with the ohNet.net.dll target. The compiler options include "/out:Build\Obj\Windows\Release\ohNet.net.dll", but the Release folder is deleted by make clean, and the compiler complains immediately, exiting before the build script gets to "if not exist $(objdirbare) mkdir $(objdirbare)" in OhNet.mak.

I seem to have fixed it here and am submitting a pull request now. If you accept it, it will break my open source duck! Hoping it's alright.
Find all posts by this user
10-09-2014, 09:11 PM (This post was last modified: 10-09-2014 09:13 PM by simonc.)
Post: #4
RE: Getting started - two issues building!
(10-09-2014 07:21 PM)MnM Wrote:  Thanks!

I'm going to try to build a DS alarm clock. I've been teaching myself C# so it's quite exciting to get going, and slightly daunting Smile

We'd be very pleased to see that app Smile. Let us know if you have any questions once you get going.

(10-09-2014 07:21 PM)MnM Wrote:  The repo has updated and I'm building everything again now. It has got much further but complained when trying to bundle:

Code:
File "bundle_binaries.py", line 95
    print "Too many arguments."
                              ^
SyntaxError: invalid syntax
NMAKE : fatal error U1077: 'C:\Python33\python.EXE' : return code '0x1'
Stop.

I'll see if it's down to my setup and report back.

I guess Python33 appearing in that error means you're using python v3.3? I think python v3.x is incompatible with v2.x which we use. Can you see whether you have better luck using python v2.7?

Alternatively, you could just ignore that error. It comes from the very last step in the build process and these bundles are normally only used for an internal system for publishing builds between repos. You won't need the bundles to write an app that uses ohNet.

(10-09-2014 07:21 PM)MnM Wrote:  Meanwhile, I've found the problem with the ohNet.net.dll target. The compiler options include "/out:Build\Obj\Windows\Release\ohNet.net.dll", but the Release folder is deleted by make clean, and the compiler complains immediately, exiting before the build script gets to "if not exist $(objdirbare) mkdir $(objdirbare)" in OhNet.mak.

I seem to have fixed it here and am submitting a pull request now. If you accept it, it will break my open source duck! Hoping it's alright.

The change looks good, thanks. I'll apply it tomorrow. (Our master repo is private and pushes to github daily. So don't worry if the change isn't visible to you immediately.)
Find all posts by this user
11-09-2014, 05:33 PM (This post was last modified: 11-09-2014 05:33 PM by MnM.)
Post: #5
RE: Getting started - two issues building!
(10-09-2014 09:11 PM)simonc Wrote:  I guess Python33 appearing in that error means you're using python v3.3? I think python v3.x is incompatible with v2.x which we use. Can you see whether you have better luck using python v2.7?

Alternatively, you could just ignore that error. It comes from the very last step in the build process and these bundles are normally only used for an internal system for publishing builds between repos. You won't need the bundles to write an app that uses ohNet.

I do have python v3.3 installed, and no other versions. I'll just ignore that error, it's working fine otherwise.

Quote:The change looks good, thanks. I'll apply it tomorrow. (Our master repo is private and pushes to github daily. So don't worry if the change isn't visible to you immediately.)

Cool

I seem to be up and running now, almost. I've successfully run the version of TestProxyCs.exe built by make, and I've also compiled TestProxy.cs from Visual Studio and got that to run as well, which is great as I can walk myself through the tests as well as the docs. But a few more questions:

1. Is there any value in running make install? I've done it, and it works (in an administrator command prompt as Program Files is protected) but not sure what it brings.

2. ohnet\Build\Obj\Windows\Release contains several .net dlls. I added ohNet.net.dll as a reference to a visual studio project which contains only TestProxy.cs, which resolved all dependencies apart from OpenHome.Net.ControlPoint.Proxies. I resolved this one by adding in all Cp*.net.dll files from the ohnet release folder. Just mentioning as I'm not sure if that's as intended.

3. I also needed to add ohNet.dll into the same folder as the .exe built by visual studio. I copied it manually, as if I try to add this from visual studio's reference manager, I get an error message "Please make sure that the file is accessible [it is], and that it is a valid assembly or COM component." This is probably me not knowing how to deal with referencing COM components and I'll investigate it, just wondering if you think it's anything else.

Thanks again,

Matthew
Find all posts by this user
11-09-2014, 07:31 PM (This post was last modified: 12-09-2014 07:39 AM by simonc.)
Post: #6
RE: Getting started - two issues building!
(11-09-2014 05:33 PM)MnM Wrote:  I seem to be up and running now, almost. I've successfully run the version of TestProxyCs.exe built by make, and I've also compiled TestProxy.cs from Visual Studio and got that to run as well, which is great as I can walk myself through the tests as well as the docs. But a few more questions:

1. Is there any value in running make install? I've done it, and it works (in an administrator command prompt as Program Files is protected) but not sure what it brings.

There is no benefit at all in running this. It'd be much better to choose a version of ohNet and bundle it with your application eventually.

(11-09-2014 05:33 PM)MnM Wrote:  2. ohnet\Build\Obj\Windows\Release contains several .net dlls. I added ohNet.net.dll as a reference to a visual studio project which contains only TestProxy.cs, which resolved all dependencies apart from OpenHome.Net.ControlPoint.Proxies. I resolved this one by adding in all Cp*.net.dll files from the ohnet release folder. Just mentioning as I'm not sure if that's as intended.

ohNet.net.dll gives you access to the generic UPnP stack. Proxies for individual services are released separately. You'll have to add references to proxies (and copy them into the relevant directory) once for each service you want to use.

Proxies for a couple of services are generated by ohNet. A full set of UPnP:AV and OpenHome services are available from ohNetGenerated. If you want to access any Linn-branded services, you'll have to generate their proxies yourself using OhNetGen.exe (built by ohNet).

(11-09-2014 05:33 PM)MnM Wrote:  3. I also needed to add ohNet.dll into the same folder as the .exe built by visual studio. I copied it manually, as if I try to add this from visual studio's reference manager, I get an error message "Please make sure that the file is accessible [it is], and that it is a valid assembly or COM component." This is probably me not knowing how to deal with referencing COM components and I'll investigate it, just wondering if you think it's anything else.

ohNet is written in C++ with bindings for various languages wrapping it. ohNet.dll contains the generic (C++) UPnP stack plus C APIs needed by the C# code in ohNet.net.dll. ohNet.dll would normally be placed in the same folder as ohNet.net.dll. (It may be possible to find it in different folders - I'm not sure what rules the Windows loader follows.) You don't have to declare any references to it in your project; it'll only ever be called by ohNet.net.dll and this dependency is resolved at run rather than link-time.

It might still be handy to persuade Visual Studio to copy the file into place for you. I'm afraid I don't know how to do that but I'd hope Google might be more helpful than me here Smile.
Find all posts by this user
12-09-2014, 11:37 AM
Post: #7
RE: Getting started - two issues building!
(11-09-2014 07:31 PM)simonc Wrote:  ohNet is written in C++ with bindings for various languages wrapping it. ohNet.dll contains the generic (C++) UPnP stack plus C APIs needed by the C# code in ohNet.net.dll. ohNet.dll would normally be placed in the same folder as ohNet.net.dll. (It may be possible to find it in different folders - I'm not sure what rules the Windows loader follows.) You don't have to declare any references to it in your project; it'll only ever be called by ohNet.net.dll and this dependency is resolved at run rather than link-time.

It might still be handy to persuade Visual Studio to copy the file into place for you. I'm afraid I don't know how to do that but I'd hope Google might be more helpful than me here Smile.

Now that you've confirmed that there's no need to reference ohNet.dll (which is the way it looked, but I wasn't sure if I was accidentally benefiting from some implicit reference that I would later need to make explicit) then this turns out to be trivial in Visual Studio - just add ohNet.dll to the project as an existing item, and set it to copy to the output directory.

(11-09-2014 07:31 PM)simonc Wrote:  
(11-09-2014 05:33 PM)MnM Wrote:  2. ohnet\Build\Obj\Windows\Release contains several .net dlls. I added ohNet.net.dll as a reference to a visual studio project which contains only TestProxy.cs, which resolved all dependencies apart from OpenHome.Net.ControlPoint.Proxies. I resolved this one by adding in all Cp*.net.dll files from the ohnet release folder. Just mentioning as I'm not sure if that's as intended.

ohNet.net.dll gives you access to the generic UPnP stack. Proxies for individual services are released separately. You'll have to add references to proxies (and copy them into the relevant directory) once for each service you want to use.

Proxies for a couple of services are generated by ohNet. A full set of UPnP:AV and OpenHome services are available from ohNetGenerated. If you want to access any Linn-branded services, you'll have to generate their proxies yourself using OhNetGen.exe (built by ohNet).

I realised that the only proxy required by TestProxy.cs is CpUpnpOrgConnectionManager1, which is generated by ohNet, so I have that test compiling neatly now using the ohNet repo alone. I imagine I'll look at ohNetGenerated in due course. By the way, did you mean to say "If you want to access any non-Linn-branded services" above?

I think I'm under steam now, thanks a lot.
Find all posts by this user
12-09-2014, 12:08 PM
Post: #8
RE: Getting started - two issues building!
(12-09-2014 11:37 AM)MnM Wrote:  I realised that the only proxy required by TestProxy.cs is CpUpnpOrgConnectionManager1, which is generated by ohNet, so I have that test compiling neatly now using the ohNet repo alone. I imagine I'll look at ohNetGenerated in due course. By the way, did you mean to say "If you want to access any non-Linn-branded services" above?

I meant any services present on a Linn DS that are published under the linn.co.uk domain, so, not av.openhome.org or upnp.org. These services include
  • Configuration
  • Debug
  • Delay
  • Diagnostics
  • Jukebox
  • Volkano
We assume that implementors of the ohMedia standard will be interested in the services published under the OpenHome domain while services under the Linn domain may not be widely applicable. ohNetGenerated is intended to cater for implementors of ohMedia so does not include the services under the Linn domain.
Find all posts by this user


Forum Jump: