redhawksdr / core-framework Goto Github PK

REDHAWK is a software-defined radio (SDR) framework designed to support the development, deployment, and management of real-time software radio applications

Home Page: https://redhawksdr.org

License: GNU Lesser General Public License v3.0

Shell 1.27% C++ 37.30% Makefile 2.10% M4 1.37% Python 44.86% C 0.23% Java 12.79% MATLAB 0.01% sed 0.02% XSLT 0.01% Ruby 0.05% M 0.01%

framework redhawk sdr

core-framework's People

Contributors

Stargazers

Watchers

core-framework's Issues

automake based build fails on OSX with brew installed tools

bash-3.2$ ./build_src.sh 
~/Workspace/OSSIE/core-framework/redhawk/src ~/Workspace/OSSIE/core-framework/redhawk
./reconf: line 23: libtoolize: command not found
configure.ac:271: warning: macro 'AM_PATH_CPPUNIT' not found in library
configure.ac:50: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:50: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
acinclude/ossie.m4:25: OSSIE_OSSIEHOME is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
acinclude/ossie.m4:64: OSSIE_OSSIEHOME_AS_PREFIX is expanded from...
configure.ac:50: the top level
configure.ac:51: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:51: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
acinclude/ossie.m4:83: OSSIE_SDRROOT_IGNORE_PREFIX is expanded from...
configure.ac:51: the top level
configure.ac:56: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:56: You should run autoupdate.
aclocal.m4:121: AC_PROG_LIBTOOL is expanded from...
configure.ac:56: the top level
acinclude/unitdir.m4:2: warning: The macro `AC_HELP_STRING' is obsolete.
acinclude/unitdir.m4:2: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
./lib/autoconf/general.m4:1553: AC_ARG_WITH is expanded from...
acinclude/unitdir.m4:2: the top level
acinclude/testdir.m4:2: warning: The macro `AC_HELP_STRING' is obsolete.
acinclude/testdir.m4:2: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
./lib/autoconf/general.m4:1553: AC_ARG_WITH is expanded from...
acinclude/testdir.m4:2: the top level
configure.ac:149: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:149: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
acinclude/ossie.m4:167: OSSIE_PYTHON_INSTALL_SCHEME is expanded from...
configure.ac:149: the top level
configure.ac:215: warning: The macro `AC_LANG_CPLUSPLUS' is obsolete.
configure.ac:215: You should run autoupdate.
./lib/autoconf/c.m4:262: AC_LANG_CPLUSPLUS is expanded from...
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
acinclude/ax_cxx_gcc_abi_demangle.m4:28: AX_CXX_GCC_ABI_DEMANGLE is expanded from...
configure.ac:215: the top level
configure.ac:215: warning: The macro `AC_TRY_COMPILE' is obsolete.
configure.ac:215: You should run autoupdate.
./lib/autoconf/general.m4:2847: AC_TRY_COMPILE is expanded from...
lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
acinclude/ax_cxx_gcc_abi_demangle.m4:28: AX_CXX_GCC_ABI_DEMANGLE is expanded from...
configure.ac:215: the top level
configure.ac:271: error: possibly undefined macro: AM_PATH_CPPUNIT
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:56: installing './compile'
configure.ac:56: installing './config.guess'
configure.ac:56: installing './config.sub'
configure.ac:25: installing './install-sh'
configure.ac:56: error: required file './ltmain.sh' not found
configure.ac:25: installing './missing'
base/framework/Makefile.am: installing './depcomp'
omnijni/src/python/omnijni/Makefile.am:23: installing './py-compile'
parallel-tests: installing './test-driver'
./reconf: line 32: libtoolize: command not found
configure.ac:56: error: required file './ltmain.sh' not found
configure: error: cannot find required auxiliary files: ltmain.sh
make: *** No targets specified and no makefile found.  Stop.
~/Workspace/OSSIE/core-framework/redhawk
bash-3.2$

gpp_setup ignores the host processor response

See here

This check against the dictionary ignores the host system's response to platform.processor() if it doesn't match the small map. If the intent of the logic was to standardize i386 and i686 to x86 while leaving other expected responses intact (x86_64, armv7l), it succeeds until you get something outside that map. Then it arbitrarily and silently changes the processor response to x86 which is only helpful if your processor is actually compatible.

Instead, something like this would pass through anything that doesn't need to be standardized:

def _gather_system_information(self):
        # get some platform information
        self.props['os_name']    = platform.system()
        self.props['os_version'] = platform.release()
        self.props['hostName'] = self.hostname
        tmp_uname_p    = platform.processor()
        tmp_proc_map   = {'i386':'x86',
                          'i686':'x86'}
        self.props['processor_name']  = tmp_proc_map.get(tmp_uname_p, tmp_uname_p)

This way the host's response is passed through rather than ignored.

build errors with current python version

make[2]: Entering directory '/home/klein_cl/Workspace/core-framework/redhawk/src/testing'
python setup.py --quiet build
  File "setup.py", line 41
    print "Incosistent tab usage:"
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Incosistent tab usage:")?
make[2]: *** [Makefile:961: all-local] Error 1
make[2]: Target 'all-am' not remade because of errors.

build errors with g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

Making all in framework
  CXX      nodeBooter-nodebooter.o
  CXX      libossiedomain_la-CorbaGC.lo
  CXX      libossiedomain_la-File_impl.lo
  CXX      libossiedomain_la-FileManager_impl.lo
  CXX      libossiedomain_la-FileSystem_impl.lo
  CXX      libossiedomain_la-helperFunctions.lo
  CXX      libossiedomain_la-POACreator.lo
  CXX      libossiedomain_la-prop_utils.lo
In file included from ../include/ossie/Properties.h:34,
                 from nodebooter.cpp:49:
nodebooter.cpp: In function ‘void loadPRFExecParams(const string&, ExecParams&)’:
nodebooter.cpp:146:59: error: no match for ‘operator<<’ (operand types are ‘std::basic_ostream<char>’ and ‘std::ifstream’ {aka ‘std::basic_ifstream<char>’})
  146 |         LOG_ERROR(nodebooter, "Failed to parse PRF file " << prfStream<< ". " << parser_error_line << "The XML parser returned the following error: " << ex.what());
      |                                                           ^~ ~~~~~~~~~
      |                                                              |
      |                                                              std::ifstream {aka std::basic_ifstream<char>}
../../base/include/ossie/debug.h:76:14: note: in definition of macro ‘_RH_LOG’
   76 |     _msg <<  msg;                \
      |              ^~~
nodebooter.cpp:146:9: note: in expansion of macro ‘LOG_ERROR’
  146 |         LOG_ERROR(nodebooter, "Failed to parse PRF file " << prfStream<< ". " << parser_error_line << "The XML parser returned the following error: " << ex.what());
      |         ^~~~~~~~~
nodebooter.cpp:146:59: note: candidate: ‘operator<<(int, int)’ <built-in>
  146 |         LOG_ERROR(nodebooter, "Failed to parse PRF file " << prfStream<< ". " << parser_error_line << "The XML parser returned the following error: " << ex.what());
../../base/include/ossie/debug.h:76:14: note: in definition of macro ‘_RH_LOG’
   76 |     _msg <<  msg;                \
      |              ^~~
nodebooter.cpp:146:9: note: in expansion of macro ‘LOG_ERROR’
  146 |         LOG_ERROR(nodebooter, "Failed to parse PRF file " << prfStream<< ". " << parser_error_line << "The XML parser returned the following error: " << ex.what());
      |         ^~~~~~~~~
nodebooter.cpp:146:59: note:   no known conversion for argument 2 from ‘std::ifstream’ {aka ‘std::basic_ifstream<char>’} to ‘int’
  146 |         LOG_ERROR(nodebooter, "Failed to parse PRF file " << prfStream<< ". " << parser_error_line << "The XML parser returned the following error: " << ex.what());
../../base/include/ossie/debug.h:76:14: note: in definition of macro ‘_RH_LOG’
   76 |     _msg <<  msg;                \
      |              ^~~
nodebooter.cpp:146:9: note: in expansion of macro ‘LOG_ERROR’
  146 |         LOG_ERROR(nodebooter, "Failed to parse PRF file " << prfStream<< ". " << parser_error_line << "The XML parser returned the following error: " << ex.what());
      |         ^~~~~~~~~
In file included from /usr/include/c++/9/iostream:39,
                 from nodebooter.cpp:21:

# ....
Making all in sdr/dev/devices/GPP/cpp
  CXX      GPP-GPP.o
GPP.cpp: In member function ‘void GPP_i::update_grp_child_pids()’:
GPP.cpp:607:44: error: no match for ‘operator<<’ (operand types are ‘std::basic_ostream<char>’ and ‘std::stringstream’ {aka ‘std::__cxx11::basic_stringstream<char>’})
  607 |                 errstr << "Unable to read "<<stat_filename<<". The process is no longer there";
      |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
      |                        |                     |
      |                        |                     std::stringstream {aka std::__cxx11::basic_stringstream<char>}
      |                        std::basic_ostream<char>
GPP.cpp:607:44: note: candidate: ‘operator<<(int, int)’ <built-in>
  607 |                 errstr << "Unable to read "<<stat_filename<<". The process is no longer there";
      |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
GPP.cpp:607:44: note:   no known conversion for argument 2 from ‘std::stringstream’ {aka ‘std::__cxx11::basic_stringstream<char>’} to ‘int’
In file included from /usr/include/c++/9/iostream:39,
                 from GPP.cpp:28:
# ...

NEW IDL FILE COMPILATION IN RedhawkSDR core-framework

I started adding new idl files in the idl folder at link "https://github.com/RedhawkSDR/framework-core/tree/master/src/idl/ossie/CF" and had some issues which I resolved "https://stackoverflow.com/questions/57223011/how-to-include-new-idl-files-and-compiling-them-in-redhawk-sdr-source-code" and reported at stackoverflow.
Now when I add the same files a.idl and b.idl in the Makefile.am at link "https://github.com/RedhawkSDR/framework-core/blob/master/src/base/framework/java/Makefile.am" in the "idlj_IDLSRC" variable the following error is generated

cf/src/CosLwLog/jni/_LogConsumerStub.java:62: error: package org.omg.CORBA.CosLwLog does not exist
public CosLwLog.LogRecord[] retrieve_records (org.omg.CORBA.CosLwLog.RecordIdHolder currentId, org.omg.CORBA.IntHolder howMany)

and "RecordIdHolder" is not found when it is defined in the module CosLwLog defined in file a.idl.

this particular file "cf/src/CosLwLog/jni/_LogConsumerStub" is generated on the go..

It is trying to search in java hierarchy org.omg.CORBA.CosLwLog which doesnot exist

Please advice ...

REDHAWK packagegen's softPackage generates incorrect headers for SCD and PRF

When using the ResourcePackage with the default SCD, SPD, and PRF templates, and then calling resourcepackage.writeXML() to generate base XML files, the default templates in redhawk.packagegen.templates are not used. Instead the base class, SoftPackage generates DOCTYPE headers that all state SPD rather than SCD and PRF.

This is the line.

Proof

from redhawk.packagegen.resourcePackage import ResourcePackage
rp = ResourcePackage('test','python','./','python.component.pull')
rp.writeXML()

Check the contents of the output test/test.prf.xml, for example:

$> cat test/test.prf.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties PUBLIC "-//JTRS//DTD SCA V2.2.2 SPD//EN" "properties.dtd">
<properties/>

Python sandbox - Generate and load SAD XML - RH2

When generating sad files using the python sandbox the connections do not appear to be added to the xml generated using sb.generateSADXML, conversely when you load a sad file containing connections they are not made in the sandbox. Tested in REDHAWK 2.2 & 2.1.3

  In [3]: myreader = sb.launch('rh.FileReader')
   2018-10-10 11:50:24 INFO  FileReader_i:352 - Using sample rate of 2.5e+07 Sps
   
   In [4]: mywriter = sb.launch('rh.FileWriter')
   2018-10-10 11:50:39 INFO  FileWriter_i:122 - Cannot determine domain, defaulting to local $SDRROOT filesystem
   
   In [5]: myreader.connect(mywriter,usesPortName='dataOctet_out')
   
   In [6]: sb.show()
   Components Running:
   ------------------
   rh_FileReader_1 <local component 'rh_FileReader_1' at 0x7fe3396b9c10>
   rh_FileWriter_2 <local component 'rh_FileWriter_2' at 0x7fe3395e1d10>
   
   
   Services Running:
   ----------------
   
   
   Component Connections:
   ---------------------
   rh_FileReader_1/dataOctet_out [IDL:BULKIO/dataOctet:1.0] -> rh_FileWriter_2/dataOctet_in [IDL:BULKIO/dataOctet:1.0]
   
   
   Event Channels:
   --------------
   
   
   SDRROOT:
   -------
   /var/redhawk/sdr
   
   
   
   In [7]: sb.ge
   sb.generateSADXML   sb.getDEBUG         sb.getIDE_REF       sb.getService
   sb.getComponent     sb.getEventChannel  sb.getSDRROOT       
   
   In [7]: sb.generateSADXML('andy')
   Out[7]: '<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE softwareassembly PUBLIC "-//JTRS//DTD SCA V2.2.2 SAD//EN" "softwareassembly.dtd">\n<softwareassembly id="DCE:58dd2953-95e8-42f7-a420-f1c9323b57e0" name="andy">\n  <componentfiles>\n\n    <componentfile id="rh.FileReader_e4cebf50-be28-4cc6-a73f-4fd22a8a65f0" type="SPD">\n      <localfile name="/components/rh/FileReader/FileReader.spd.xml"/>\n    </componentfile>\n\n    <componentfile id="rh.FileWriter_0d2dd048-2c35-4616-be5c-02810427f2e4" type="SPD">\n      <localfile name="/components/rh/FileWriter/FileWriter.spd.xml"/>\n    </componentfile>\n  </componentfiles>\n  <partitioning>\n\n    <componentplacement>\n        <componentfileref refid="rh.FileReader_e4cebf50-be28-4cc6-a73f-4fd22a8a65f0"/>\n        <componentinstantiation id="DCE:83124a9b-195b-4b6b-a638-308b643779e6">\n            <usagename>rh_FileReader_1</usagename>\n            <findcomponent>\n                <namingservice name="rh_FileReader_1"/>\n            </findcomponent>\n      </componentinstantiation>\n    </componentplacement>\n\n    <componentplacement>\n        <componentfileref refid="rh.FileWriter_0d2dd048-2c35-4616-be5c-02810427f2e4"/>\n        <componentinstantiation id="DCE:7511beb1-2b07-48b2-845d-27f6e252fe40">\n            <usagename>rh_FileWriter_2</usagename>\n            <findcomponent>\n                <namingservice name="rh_FileWriter_2"/>\n            </findcomponent>\n      </componentinstantiation>\n    </componentplacement>\n  </partitioning>\n\n  <assemblycontroller>\n      <componentinstantiationref refid="DCE:83124a9b-195b-4b6b-a638-308b643779e6"/>\n  </assemblycontroller>\n  <connections>\n  </connections>\n</softwareassembly>\n'
   
   In [8]:

Incorrect link in release announcement

Really this should be for RedhawkSDR/Documentation but that project doesn't have issues enabled. Since the broken links point to this project, it seemed like a reasonable substitute 😄

The release notes at http://redhawksdr.github.io/Documentation/ refer to https://github.com/RedhawkSDR/core-framework/tree/develop-2.1.2/docs/*, but I think it was meant to be https://github.com/RedhawkSDR/core-framework/blob/2.1.2/docs/shared-memory/*

redhawk-codegen: can no longer work without a wavedev file

The change in 24539bc makes the wavedev file required in order to use redhawk-codegen. If a project is lacking a wavedev file, or if the user decides to run redhawk-codegen with the -i flag (to ignore the file), redhawk-codegen will fail:

[~/workspace/TestMe ]$ redhawk-codegen -i --frontend --impl cpp TestMe.spd.xml 
Traceback (most recent call last):
  File "/usr/local/redhawk/core/bin/redhawk-codegen", line 336, in <module>
    if ('persona' in implSettings.template and not overrides.template) or ((resource_type and ('persona' in resource_type)) or (overrides.template and ('persona' in overrides.template))):
NameError: name 'implSettings' is not defined

In the above test case, TestMe is a newly-created FEI device via the IDE.

The referenced line above is here. The implSettings object is only set if the wavedev file is imported as the settings member and then incidentally set here, to the last value in that map.

C++ Device_impl::updateUsageState() should be virtual

Generated C++ devices have an updateUsageState() method that is meant to be called after an allocation or deallocation. The default Device_impl::updateUsageState() is not declared as virtual (Device_impl.h#149), so allocateCapacity() and deallocateCapacity() only call the empty base version, not the derived class implementation. As a result, custom non-FEI devices have to either override allocateCapacity() and deallocateCapacity() or otherwise change the device state.

This does not affect C++ FEI devices, which have a different, non-empty (and virtual) updateUsageState().

Sandbox loadSADFile does not handle component with simple property with no explicit <kind> tag specified

The DTD file for a PRF file specifies that the <simple> tag has an optional <kind> child:

<!ELEMENT simple 
        ( description?
        , value?
        , units?
        , range?
        , enumerations?
        , kind*
        , action?
        )>

<!ELEMENT kind EMPTY>
<!ATTLIST kind
        kindtype        (allocation | property | configure | test | execparam | factoryparam | event | message) 
"configure">

However, the loadSADFile function assumes that the <kind> tag is always present

core-framework/redhawk/src/base/framework/python/ossie/utils/sb/domainless.py

Line 799 in 7f72db1

for prop_check in _prf.get_simple():

                _prf = parsers.prf.parse(prfFilename)
                execprops = []
                configurable[instanceName] = []
                for prop_check in _prf.get_simple():
                    if prop_check.get_kind()[0].get_kindtype() == 'execparam':                                                                                                                                               
                        execprops.append(str(prop_check.get_id()))
                    if prop_check.get_kind()[0].get_kindtype() == 'configure':
                        if prop_check.get_mode() == 'readwrite' or prop_check.get_mode() == 'writeonly':
                            configurable[instanceName].append(str(prop_check.get_id()))
                    if prop_check.get_kind()[0].get_kindtype() == 'property':
                        if prop_check.get_mode() == 'readwrite' or prop_check.get_mode() == 'writeonly':
                            configurable[instanceName].append(str(prop_check.get_id()))

Calling loadSADFile with a waveform with a component that has a simple property without a <kind> tag will result in an error message:

DEBUG:ossie.utils.sb.domainless:COMPONENT PLACEMENT component spd file id 'PSD_a9532f88-cd71-4e79-938e-fb84c67b0722'
DEBUG:ossie.utils.sb.domainless:COMPONENT PLACEMENT component instantiation id 'PSD_1'
DEBUG:ossie.utils.sb.domainless:COMPONENT PLACEMENT component startorder '1'
DEBUG:ossie.utils.sb.domainless:COMPONENT PLACEMENT component name 'PSD_1'
DEBUG:ossie.utils.sb.domainless:launching component 'PSD_1'
DEBUG:ossie.utils.sandbox.launcher:Killing process group 74527 with signal 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/redhawk/core/lib/python/ossie/utils/sb/domainless.py", line 1097, in loadSADFile
    raise RuntimeError(msg)
RuntimeError:  ERROR - Failed to load sad file: /var/redhawk/sdr/dom/waveforms/MockDetectorWaveform/MockDetectorWaveform.sad.xml REASON: list index out of range

The list index out of range exception is coming from the line:

 if prop_check.get_kind()[0].get_kindtype() == 'execparam':

I believe the code should check for a missing tag and use the default configure value in this case.

Adding required third party libraries should be easier

Writing a Python based component that may import additional Python libraries currently requires creating a SharedLibrary for each required library which is documented here. Adding these Python SharedLibraries is achieved by first creating a C++ SharedLibrary then making many manual modifications to the XML, configure.ac and Makefile.am. This is a very convoluted and confusing process and is prone to errors. There should be an option to create a Python library that avoids all the manual editing. Furthermore, this should also be documented in the documentation and not in an old blog post and cover other packaging methods like wheels.

Many compiler warnings with Apple clang++ -std=c++14 on OSX

see https://github.com/RedhawkSDR/core-framework/blob/d31acd66f8eb53caa88e1319569a2caf92afd54c/redhawk/src/.builddriver.log

NOTE: All the deprecated warnings about `throw()` declarations are suppressed!

see clang-tidy check results

bulkio_helpers.pythonComplexListToBulkioComplex does not apply the default itemType

core-framework/redhawk/src/base/framework/python/ossie/utils/bulkio/bulkio_helpers.py

Line 121 in 07031bb

return list(gen)

Use case: A user is manipulating data using numpy complex floats, and uses this function to convert it to a format compatible with BULKIO.

Method of failure: Because the function does not actually apply the default itemType, the resulting list is numpy.float32, which is not compatible with BULKIO.

ossie::corba::erase() has extra template parameter

The ossie::corba::erase() function in redhawk/src/base/include/ossie/CorbaSequence.h has an extra template parameter that breaks type deduction. In order to invoke the function, the caller must explicilty specify both template parameters (the second is not used and may be specified as void):

ossie::corba::erase<CF::AllocationManager::AllocationRequestSequence,void>(requests, idx);

A better declaration, requiring no changes to the body, would be:

template <typename Sequence>
inline void erase (Sequence& sequence, size_t idx)

Although it is unlikely to be in use in the wild, the old signature can be maintained as a wrapper forwarding to the 1-parameter version.

OSSIE and build dependencies

Hello! I am attempting to build from source and have questions I hope you can address.

I am using Ubuntu 24.04, not Redhat or any of its derivatives. I find build instructions at https://redhawksdr.org/2.2.6/manual/appendices/source-installation/ and information addressing dependencies at https://redhawksdr.org/2.2.6/manua\
l/appendices/dependencies/ but these make no mention of fundamental dependencies. In particular, I have been unable to locate a suitable version of OSSIE.

I located a version of OSSIE on github at https://github.com/ClausKlein/OSSIE but it has a version of 0.6.2 and your build seems to require at least version 2. Where do I find a suitable version of OSSIE? It would help immensely if your
documentation could give references to dependencies such as this.

Here's an excerpt from a build of just the VITA49 library:

$ ./build.sh
aclocal: error: couldn't open directory '/share/aclocal/ossie': No such file or directory
autoreconf: error: aclocal failed with exit status: 1
./build.sh: line 25: ./configure: No such file or directory
make: *** No targets specified and no makefile found.  Stop.

The build instructions do say

You must set the OSSIEHOME and SDRROOT environment variables (recommended defaults shown below) before running the installation script. You must have write permission for the locations of OSSIEHOME and SDRROOT or the installation will not work.

Unfortunately, I find no other indication of where to obtain whatever must be stored there. The OSSIE that I have found has no share directory and does not meet the version requirements.

checking for ossie >= 2.0... no
configure: error: Package requirements (ossie >= 2.0) were not met:

Package dependency requirement 'ossie >= 2.0' could not be satisfied.
Package 'ossie' has version '0.6.2', required version is '>= 2.0'

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables REDHAWK_CFLAGS
and REDHAWK_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make: *** No targets specified and no makefile found.  Stop.

I hope you can help. Thank you very much!

redhawksdr / core-framework Goto Github PK

core-framework's People

Contributors

Stargazers

Watchers

Forkers

core-framework's Issues

Proof

NOTE: All the deprecated warnings about throw() declarations are suppressed!

Recommend Projects

Recommend Topics

Recommend Org

Jobs

NOTE: All the deprecated warnings about `throw()` declarations are suppressed!