Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing SOAPY_REMOTE_API on some classes #36

Closed
gvanem opened this issue Feb 15, 2018 · 3 comments
Closed

Missing SOAPY_REMOTE_API on some classes #36

gvanem opened this issue Feb 15, 2018 · 3 comments

Comments

@gvanem
Copy link

gvanem commented Feb 15, 2018

I'm not sure how/what libraries or DLLs this remoteSupport is supposed to generate. I'm on Windows and try to create only .DLLs for SoapySDR. If compiling with -DSOAPY_REMOTE_DLL, I get these missing symbols while linking SoapySDRserver.exe:

SoapyServer.obj : error LNK2019: unresolved external symbol "public: __thiscall SoapySSDPEndpoint::SoapySSDPEndpoint(void)" (??0SoapySSDPEndpoint@@QAE@XZ) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: __thiscall SoapySSDPEndpoint::~SoapySSDPEndpoint(void)" (??1SoapySSDPEndpoint@@QAE@XZ) referenced in function "public: void * __thiscall SoapySSDPEndpoint::`scalar deleting destructor'(unsigned int)" (??_GSoapySSDPEndpoint@@QAEPAXI@Z)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: void __thiscall SoapySSDPEndpoint::registerService(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,int)" (?registerService@SoapySSDPEndpoint@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0H@Z) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: __thiscall SoapyMDNSEndpoint::SoapyMDNSEndpoint(void)" (??0SoapyMDNSEndpoint@@QAE@XZ) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: __thiscall SoapyMDNSEndpoint::~SoapyMDNSEndpoint(void)" (??1SoapyMDNSEndpoint@@QAE@XZ) referenced in function "public: void * __thiscall SoapyMDNSEndpoint::`scalar deleting destructor'(unsigned int)" (??_GSoapyMDNSEndpoint@@QAEPAXI@Z)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: void __thiscall SoapyMDNSEndpoint::printInfo(void)" (?printInfo@SoapyMDNSEndpoint@@QAEXXZ) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: bool __thiscall SoapyMDNSEndpoint::status(void)" (?status@SoapyMDNSEndpoint@@QAE_NXZ) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: void __thiscall SoapyMDNSEndpoint::registerService(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,int)" (?registerService@SoapyMDNSEndpoint@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0H@Z) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)

I think this patch fixes it, but I'm really over my head here:

--- a/common/SoapyMDNSEndpoint.hpp 2018-02-15 13:55:45
+++ b/common/SoapyMDNSEndpoint.hpp 2018-02-15 20:53:32
@@ -2,6 +2,7 @@
 // SPDX-License-Identifier: BSL-1.0

 #pragma once
+#include "SoapyRemoteConfig.hpp"
 #include <string>
 #include <map>

@@ -16,7 +17,7 @@
  * Used for both server side for publishing,
  * and the client side for browsing/lookup.
  */
-class SoapyMDNSEndpoint
+class SOAPY_REMOTE_API SoapyMDNSEndpoint
 {
 public:

--- a/common/SoapySSDPEndpoint.hpp 2018-02-15 13:55:45
+++ b/common/SoapySSDPEndpoint.hpp 2018-02-15 20:53:24
@@ -2,6 +2,7 @@
 // SPDX-License-Identifier: BSL-1.0

 #pragma once
+#include "SoapyRemoteConfig.hpp"
 #include "SoapyRPCSocket.hpp"
 #include <string>
 #include <csignal> //sig_atomic_t
@@ -9,7 +10,7 @@
 #include <vector>
 #include <map>

-class SoapyHTTPHeader;
+class SOAPY_REMOTE_API SoapyHTTPHeader;
 struct SoapySSDPEndpointData;

 /*!
@@ -17,7 +18,7 @@
  * keep track of discovered servers of interest,
  * and to respond to discovery packets for us.
  */
-class SoapySSDPEndpoint
+class SOAPY_REMOTE_API SoapySSDPEndpoint
 {
 public:

PS. I see not way the Cmake-system can set -DSOAPY_REMOTE_DLL + -DSOAPY_REMOTE_DLL_EXPORTS. An oversight?

@guruofquality
Copy link
Contributor

guruofquality commented Feb 15, 2018

That common directory does not produce any DLLs, its a static library thats linked into the server and client. Most of the SOAPY_REMOTE_DLL and SOAPY_REMOTE_API stuff is a hold over from development and it shouldnt be needed (its not consistently applied) and should be removed.

The install creates two files:

  • SoapySDRServer.exe (an exe that runs the server) and
  • and libremoteSupport.dll which is a runtime loadable module that gets installed into the SoapySDR modules directory

So theres no development headers or libs, there was never an intention to reuse the code in common/ outside of the project. So I recommend using the default defines (dont set SOAPY_REMOTE_DLL) and everything should be fine.

@gvanem
Copy link
Author

gvanem commented Feb 16, 2018

Okay, clear. I've successfully build module/remoteSupport.dll and SoapySDRserver.exe statically.

But I'm lost as to the little information from the various drivers.
A SoapySDRUtil.exe --help=remote would help. But e.g. a SoapySDRUtil.exe --find=remote IMHO reports more than I asked for.

@gvanem gvanem closed this as completed Feb 16, 2018
@guruofquality
Copy link
Contributor

The client stuff is entirely transparent and looks like any other SoapySDR module would. However there are some optional device arguments and ways to narrow down devices documented here: https://github.com/pothosware/SoapyRemote/wiki#remote-device-args

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants