I have created an Eclipse CDT project that uses autotools from the libsndfile source code library. It builds fine in Eclipse. How do I modify this project to use it as a REDHAWK component the way that the dsp library and others are used?
Thanks!
There are multiple approaches to adding a shared library to work with REDHAWK. The simplest approach is to install the library on your GPP and follow the steps outlined in the section "Including External Libraries" found in the REDHAWK documentation.
The approach taken in the dsplib you asked about is slightly different. This creates a REDHAWK softpackage library dependency which is installed in the SDRROOT and deployed at runtime along with your component. Here are the steps to get a pre-exsisting c++ project working in REDHAWK. This answer does not cover getting the library to build or the process of importing it into eclipse as there are numerous posts on these topics:
Import the library into your IDE.
Build your shared library so that you have a shared object (.so file)
Add a .spd.xml file to your library such as the one found here.
Edit this .spd.xml file:
4a. Update the localfile tag to point to the location of your specific .so file.
4b. Ensure that the value of the implementation id tag is a unique revision number for your library
Add a .project file if it doesn't exist such as the one found found here. Open your .project file and ensure that the following natures are included:
<nature>gov.redhawk.ide.natures.sca.project</nature>
<nature>gov.redhawk.ide.natures.sca.component</nature>
You should now be able to drag your sofpackage library to the SDR root.
Here are the steps to update your individual components you are building to make use of your new library:
Edit the components Makefile.am in the cpp implementation folder. Edit the _CXXFLAGS to add the path to your header files, _LDADD to add your library, and _LDFLAGS to include the path to your library. See this example for how the agc component modifies these variables to include the dsp library.
Edit the .spd.xml file to include the softpackage dependency. Under the implementation section add a run time dependency on your library such as the one found here. Specifically - your dependency section should be as follows:
<dependency type="runtime_requirements">
<softpkgref>
<localfile name="XXXX"/>
<implref refid="YYYY"/>
</softpkgref>
</dependency>
XXXX is the path to your installed library .spd.xml file in the SDRROOT relative to the dom directory (it should start with /components) YYYY is your specific implementation value defined in 4b above.
I can't add comments, so I apologize for providing an "answer."
For me, Youssef's description worked perfectly for building components with shared libraries. However, in order to load the shared libraries at runtime, I needed to add the following to the makefile.am _LDFLAGS:
-Xlinker -rpath -Xlinker ../../dsp/Release
Where "/dsp/Release" is the relative path to whichever shared library you created.
Related
Apparently anything GUI-related in terms of components involves XML. I cannot go around actually configuring and building wxWidgets from source because of that. I'm new to wxWidgets.
My current setup is on Win10 with MSVC v141 (Visual Studio 2017) with the latest CMake version (currently 3.21).
Inside the config.cmake of the wxWidgets projects (using latest master branch) I see
wx_get_dependencies(EXTRALIBS_XML xml)
I am also calling CMake with -DwxUSE_XML=ON (among other parameters) but this still leads to:
the XML dependency is nowhere to be found
respectively it's not built
Linking then fails with the following error:
LINK : fatal error LNK1104: cannot open file 'wxxml.lib' [C:\Users\...\CMakeBuilds\ef5b5ada-ee42-7735-988a-ae37c735ccff\build\deps\build\wxwidgets\libs\qa\wxqa.vcxproj]
What library is actually wxWidgets using and how do I trigger it's retrieval and accordingly configuration and building? Since I am adding wxWidgets to my CMake project as an ExternalProject component, I would appreciated something in that line of thought. However any kind of information regarding this issue is more than welcome especially since it will shine light on how to configure other features (if I want them in the future) such as WebView.
The wxxml.lib issue is fixed now. While fixing it I also discovered a bug (of sort) in the build system of wxWidgets.
The reason why it failed to build this library in particular was actually quite simple but due to the lack of knowledge in the dependencies of wxWidgets. I thought that wxWidgets, given it depends on XML so much, has its own XML parser. Well, not really. The wxXML component actually uses and underlying 3rd party dependency called EXPAT, which - as you can see in my question - I have deactivated since it was giving me issues during the build (due to the still present problem of not being able to automatically retrieve dependencies).
What I did was to clone the libexpat repository, add it as an ExternalProject, set the variables for the libraries and include directory and pass them onto my wxWidgets project. But there is a catch...
The expat.cmake file looks as follows:
#############################################################################
# Name: build/cmake/lib/expat.cmake
# Purpose: Use external or internal expat lib
# Author: Tobias Taschner
# Created: 2016-09-21
# Copyright: (c) 2016 wxWidgets development team
# Licence: wxWindows licence
#############################################################################
if(wxUSE_EXPAT STREQUAL "builtin")
# TODO: implement building expat via its CMake file, using
# add_subdirectory or ExternalProject_Add
wx_add_builtin_library(wxexpat
src/expat/expat/lib/xmlparse.c
src/expat/expat/lib/xmlrole.c
src/expat/expat/lib/xmltok.c
)
set(EXPAT_LIBRARIES wxexpat)
set(EXPAT_INCLUDE_DIRS ${wxSOURCE_DIR}/src/expat/expat/lib)
elseif(wxUSE_EXPAT)
find_package(EXPAT REQUIRED)
endif()
I would use the *.cmake files of the 3rd party dependencies stored inside <ROOT_OF_WXWIDGETS_PROJECT>/build/cmake/lib to determine which variables I need to set if builtin is selected as the value for the respective library. Since I want to use my own I need sys (e.g. -DwxUSE_EXPAT=sys as a CMAKE_ARGS inside my wxWidgets ExternalProject) and also to pass the headers and libraries accordingly.
Given the file above one would assume that EXPAT_LIBRARIES is required. However after failing to build (yet again) and seeing that the reason was the activated expat build and that it was set as builtin I checked the log in detail and found the following error:
Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.2.6")
Notice the EXPAT_LIBRARY. After passing it (-DEXPAT_LIBRARY=...) my build was complete. For me this is a bug or simply inconsistency between the dependency cmake file and the rest of the wxWidgets project.
It is important to note that I do not retrieve the external dependency through wxWidgets itself (see config.cmake and more precisely the macro wx_get_dependencies(...)). This solves the problem with a basic configuration and build of wxWidgets but if you don't want to tackle every dependency of wxWidgets on your own (why should you?), I recommend looking for a solution where the dependencies (at least the ones you don't want to deal with) are automatically retrieved, configured and build as builtin.
I am a cmake newbie (on Debian/Sid/Linux/x86-64)
I forked libonion on https://github.com/bstarynk/onion to enable customization of malloc with Boehm's garbage collector; see this mail thread.
I added two files there onion/src/low_util.c and onion_src/low_util.h (which is #include-d successfully in several other patched files.
It is compiled but not linked.
set(SOURCES onion.c codecs.c dict.c low_util.c request.c response.c handler.c
log.c sessions.c sessions_mem.c shortcuts.c block.c mime.c url.c ${POLLER_C}
listen_point.c request_parser.c http.c ${HTTPS_C} websocket.c ${RANDOM_C} ${SQLITE3_C})
later:
SET(INCLUDES_ONION block.h codecs.h dict.h handler.h http.h https.h listen_point.h low_util.h log.h mime.h onion.h poller.h request.h response.h server.h sessions.h shortcuts.h types.h types_internal.h url.h websocket.h ${SQLITE3_H})
MESSAGE(STATUS "Found include files ${INCLUDES_ONION}")
but when I build, my file low_util.c got compiled but not linked.
Linking C executable otemplate
CMakeFiles/opack.dir/__/__/src/onion/dict.c.o: In function `onion_dict_new':
dict.c:(.text+0x1bc): undefined reference to `onionlow_calloc'
CMakeFiles/opack.dir/__/__/src/onion/dict.c.o: In function `onion_dict_node_data_free':
dict.c:(.text+0x2ec): undefined reference to `onionlow_free'
CMakeFiles/opack.dir/__/__/src/onion/dict.c.o: In function `onion_dict_node_add':
Notice that libonion is a library (in C, providing HTTP service) and that I just want to add a low_util.c file (wrapping malloc & pthread_create etc... to make Boehm's GC happy: it is calling GC_malloc and GC_pthread_create ....) with its low_util.h header. Surprisingly, they get compiled, but do not seems to be linked. And I am not familiar with cmake and I am not familiar with how D.Moreno (the main author of libonion) has organized his cmake files.
Any clues?
Apply the following patch to make it link. The two executables which are being linked with the symbols generated from the .c file you added are missing and are added in the patch.
http://pastebin.com/mDMRiUQu
Based on what you posted, its hard to tell what could be wrong. The cake source code above says that a variable ${SOURCES} is equivalent to onion.c codecs.c dict.c low_util.c ... ${SQLITE3_C}, and a variable ${INCLUDE_ONION} is equivalent to block.h codecs.h dict.h ... ${SQLITE3_H}. You did not provide any targets or the files included in those targets.
A brief list of things that may help:
where do you define the top level library or executable? If your making a library, you will need the command add_library(). If you are making an executable, you will need the add_executable() command.
Use the command target_link_libraries() to resolve dependencies. Rather than placing all of the source files in a single library, group similar together in a single target (a target is defined by the add_* commands), and use this command to link the targets after compilation.
Use the find_package() to get any libraries which are defined on your system but not in you project. Then, link to that library using the target_link_libraries() command.
In this case, if the onion_dict_* functions are defined within the same library, your not including those files in library. When you use add_library or add_executable, ensure you add those files to the list. If the functions are within your project but not in the same library, use the target_link_libraries() command to link to the library which contains the correct files. If those commands are defined in an external library, then first find the library using find_package(), and then link to the library using target_link_libraries().
I am writing an extension for the Scratch text editor application on Elementary OS Luna. But the documentation is practically non-existent for extension creation and I have no idea how to proceed after writing my main code for the extension.
I've already written the extension. I cannot use or test it yet as it needs to be "installed". I spent hours looking for docs but they do not exist. I did however, find a comment on the scratch launchpad page that says
Generally you have to generate a pluginname.so file and put it in
lib/scratch/plugins/pluginname with a pluginname.plugin file
Great. This seems like the last part of creating an extension for Scratch. What is a .so file, and how do I generate one? I've already created the other necessary files like the .plugin file and the .vala file.
Yes, I have searched for .so files but all I found were random things about it like using it with C, or C++ headers but obviously that won't work for me, since I'm using Vala?
How do I generate a .so file? What do I generate it from?
I think the The Vala tutorial could be helpful on creating the actual Shared library or Shared Object.
You can use the autotools, cmake or you can compile and link a shared library directly from the command line, quoted from the Vala tutorial:
Compilation and linking using Command Line
Vala is not yet capable of directly creating dynamic or static
libraries. To create a library, proceed with the -c (compile only)
switch and link the object files with your favourite linker, i.e.
libtool or ar.
$ valac -c ...(source files)
$ ar cx ...(object files)
or by compiling the intermediate C code with gcc
$ valac -C ...(source files)
$ gcc -o my-best-library.so --shared -fPIC ...(compiled C code files)...
From the Scratch Wiki
Due to browser security restrictions, Scratch 2.0 cannot interact with
hardware devices directly. Instead, hardware extensions come with a
helper app, a separate application that the user must install and run
on their computer. Scratch communicates with the helper app via HTTP
requests, and the helper app talks to the hardware. In the future,
some extensions may package their helper apps as browser plugins.
Here are the steps for creating and testing a Scratch extension:
Create an extension description file
Create your helper app and start it
Open the Scratch 2 Offline Editor
Import the extension description (shift-click on "File" and select "Import Experimental Extension" from the menu)
The new extension blocks will appear in the More Blocks palette
Test your extension and iterate!
Helper apps can be written in any language that supports server sockets, such as Python, Node.js, Java, C, etc.
Like you I've chased around the wiki but I cannot find an example with source. So all I can do is to address your question generally.
If you look at Build .so file from .c file using gcc command line you'll see how a simple .so can be created. However what code goes into a Scratch extension I don't know. Sorry.
Edit: More googling and I've found a sample from Nathan Dinsmore on GitHub that doesn't use C rather it uses JavaScript, and though it doesn't create a .so extension, it does have what appears to be a full description of creating an extension. He also provides a couple of tutorials.
Edit++ : And here is another sample written in Java.
I searched this problem here and find some similar question but there solutions not work for me. Here is my problem:
My application is compiling with shared library of openldap-2.3. Openldap has /usr/lib/libldap-2.3.so.0 which is linked to /usr/lib/libldap-2.3.so.0.2.31. I passed -lldap option to gcc, which linked the libldap-2.3.so.0 file to my application.
But i want to link with specific name like libldap.so. Please correct me, in future if i change the openldap version to 2.4 in development system, it will then link to the libldap-2.4.so.XXX version.
So How can I link my application to specific name, so that it will always look for same name like libldap.so.
NOTE: I created a softlink of /usr/lib/libldap-2.3.so.0 as /usr/lib/libldap.so and then pass the library name /usr/lib/libldap.so to compiler without -l then application compiled successfully without any linking error but still showing same libldap-2.3.so.0 in dependency.
The shared library mechanism (the link is oldish, but still relevant) in Unix works by linking the executable at build time against e.g. liba.so, which is a symbolic link to liba.so.1, which in turn is a link to liba.so.1.2. The executable then records liba.so.1 to load when starting up. If you update liba.so, it could be to liba.so.1.5 (no ABI change, first digit doesn't change), the links look like liba.so --> liba.so.1 --> liba.so.1.5, and your executable now uses 1.5 transparently. If the version goes to liba.so.2.0 (API change!), the system makes liba.so --> liba.so.2 --> liba.so.2.0. Your old executable still uses 1.5, any newly built program will now reference 2. All this works as long as 1.x stays around, obviously. Presumably your distribution offers library packages that can be installed in paralell, or some compat-liba-1 package for the benefit of old executables.
I don't know if it's possible to do this, but I would like the /NODEFAULTLIB to be applied to a static library project.
I have many application projects (A.exe, B.dll, C.dll) that use a common static library D.lib.
This library has a lot of code and also has other .lib dependencies as well. One of them is the openssl library, which seems to have been built for win32 against the Release version of the CRT (i don't have the original project/sources).
So far, to avoid the mixing of the Release/Debug versions of CRT, I have to put the /NODEFAULTLIB:msvcrt.lib linker directive in all leaf projects (A.exe, B.dll). This works but I think it's not the ideal way of dealing with that issue.
I tried to put this property in D.lib project, but it has no effect.
Is there a way to force msvc++ to ignore the msvcrt.lib dependency from the 3rd party library?
A .lib does not have any linker settings because you don't link it, you link to it. A .lib is just an archive of .obj files, sort of like an uncompressed .zip file - that's why you have to put the setting on all projects that link to it.
If you're using VS2005+ you could use property sheets so that you only have to put the setting in one place and then use that property sheet in all projects.
However, OpenSSL is just that - Open Source, so you should be able to get the source for the version you are using and build it again (and add it to your version control system of course). I thought OpenSSL could be built as a DLL or LIB, which would solve your problem as the DLL would not interfere with the linking of your code.
Failing that, you always have the option of slitting your functionality out into a separate DLL so that you only have issues with one project.
To prevent your distributed static link library from depending on a specific MSVC runtime library you need to set this compiler option (in Visual Studio 2010 it looks like):
Configuration Properties -> C/C++ -> Advanced -> Omit Default Library Name = Yes (/ZI)
Now your users can link to your release built static lib from their debug build and not try to link to the incorrect runtime library causing problems, as well as linkers warnings.
Note that may cause link errors if your library actually depends on a specific runtime library or its behavior, and compatible components are not provided in some other way.
My understanding is that if library LIB in linked statically into a DLL, the DLL contains already all relevant code from LIB. Therefore, this coupling cannot be removed. This is just based on my understanding of statical linking, not on experiments.