Is there any way to add multiple libraries or only one by one in C/C++ Build --> Settings --> MinGW C++ Linker --> Libraries (-l) ?
What I mean is there a way just to copy from somewhere (some txt file for example) all of the names of libraries and then to paste them into the Libraries (-l) field, the same way it could be done in Visual Studio 2010?
Also, where does eclipse stores information about this? I have to rename a lot of libraries (from opencv245 to opencv246) so I guess if it is stored in some XML file I could just run search and replace tool on it's content.
I'm using Eclipse (Kepler) with CDT on CentOS and it appears that my project libraries (-l) and library paths (-L) are in the .cproject XML file located in the project directory. There is a lot in there but you should be able to find it under the appropriate tool XML entry. (I'm using Linux GCC.) Here's mine:
<tool id="cdt.managedbuild.tool.gnu.cpp.linker.exe.debug.429094553" name="GCC C++ Linker" superClass="cdt.managedbuild.tool.gnu.cpp.linker.exe.debug">
<option id="gnu.cpp.link.option.libs.2011755342" name="Libraries (-l)" superClass="gnu.cpp.link.option.libs" valueType="libs">
<listOptionValue builtIn="false" value="common"/>
<listOptionValue builtIn="false" value="customapi"/>
</option>
<option id="gnu.cpp.link.option.paths.1035898902" name="Library search path (-L)" superClass="gnu.cpp.link.option.paths" valueType="libPaths">
<listOptionValue builtIn="false" value=""${workspace_loc:/common/Debug}""/>
<listOptionValue builtIn="false" value=""${workspace_loc:/customapi/Debug}""/>
</option>
<inputType id="cdt.managedbuild.tool.gnu.cpp.linker.input.198247885" superClass="cdt.managedbuild.tool.gnu.cpp.linker.input">
<additionalInput kind="additionalinputdependency" paths="$(USER_OBJS)"/>
<additionalInput kind="additionalinput" paths="$(LIBS)"/>
</inputType>
</tool>
Related
I realise this is a newb question but I've been racking my brains for hours.
So I want to use the STK (Synthesis Toolkit) to generate sine waves etc. I've downloaded the source files from https://ccrma.stanford.edu/software/stk/download.html
I unzipped the tar.gz using 7zip.
I opened up the demo.cpp project file (under /projects/demo/demo.cpp) and whenever I try to compile it, I receive lots of errors, all starting with "undefined reference to"
I have set the compiler search directory to include the root folder of the stk kit (unzipped as "stk-4.5.0"). My understanding is that I also have to find file for the linker, that is of the type .lib? Is that correct? I haven't been able to find a .lib file to link to.
I feel like this is a simple fix - what am I missing?
You've downloaded a source , not the compiled library which might be used by linker (.lib file) There are three solutions:
1. Compile whole src folder of your download ( see instructions on their website). Frankly, I've tried to do that recently but failed, especially under Windows although I don't have any experience in this so you can try yourself.
2. Use precompiled library available in some Linux repositories. I had success with Slacko Puppy linux. Package simply adds libstk.a (linux static library) to /usr/lib and stk headers to /usr/include/stk (notice you have to add exactly that path to compiler, since /usr/lib is not enough). This gave me best results.
3. If you use only several classes, you can copy their .cpp files directly to your project source folder. Remember to add parent classes, too (see STK site -> Classes). Again I recommend that you give the compiler path to include folder you've unzipped, but copying only selected headers should also work.
I've found this article helpful (see also A1): http://www.learncpp.com/cpp-tutorial/a3-using-libraries-with-codeblocks/
Hope I've helped
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.
I've written a Tcl script that uses the TclMagick extension together with GraphicsMagick.
For GraphicsMagick, I've both the Windows DLLs and the Linux SO files. I want to be able to make two Starkit/Starpack applications bundled with those libraries: one for Windows (with the DLLs) and one for Linux (with the SO files).
Is this reasonable? Can it be done?
EDIT
I cannot seem to use DLLs with dependencies under Windows. In my case, I want to use the TclMagick extension, but it needs the GraphicsMagick's DLLs and the starkit cannot find those. What should I do in this situation?
Yes. In the lib/tclmagick subdirectory of $starkit::topdir, you'll place the dynamic library and an appropriate pkgIndex.tcl file that loads the library. Use a Makefile or some other build script to use the correct dynamic library file, and generate the pkgIndex, depending the target platform.
The directory hierarchy:
appname.vfs/
main.tcl
lib/
app-appname/
appname.tcl
pkgIndex.tcl
tclmagick/
pkgIndex.tcl
tclMagick.so
package require tclmagick will work as you expect, for some capitalization of "tclmagick"
You can do it, but you might need some extra windows trickery to get things to work properly.
Windows has quite a few options to load dependent libraries, this page explains the basics:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
There are is one part that can help you:
If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
So, to get the dependencies right, you could get the dependent libraries loaded into memory first (sadly you cannot use load for this, but could use something from twapi, e.g. twapi::load_libary (see http://wiki.tcl.tk/9886) to get the library loaded from some temporary location).
Sadly most OS's do not provide an easy or portable way to load a dynamic library directly from memory, so you need to copy the dependent libs to a temporary location first (you can do it with appropriate hacks or by using something like an installable filesystem on windows/FUSE on Linux).
In most cases the easiest route is to just link all dependencies statically into the extension instead.
I am pretty experienced writing my own code, but not in C++. I am used to adding .NET assembly references, and I want to get into using C++.
I downloaded a VC++ 6 project presenting a graph algorithm, opened it in Visual Studio 2010 Ultimate and downloaded the required libraries (LEDA .NET assemblies) however, they came with both DLLs and LIB so I thought I would have no problems with the .NET and C++ connection. Also, the LEDA project comes with C++ style .header files, and static libraries, yet frustration persists.
I put my LEDA header files in a directory visible to the project, since I can "Go to definition" of all the custom LEDA data types and see where they are defined in the LEDA include files.
But, I can not compile/link these data types in. The VS finds their very existence repulsive, and refuses to acknowledge they could possibly be found in leda.lib.
Steps I have already taken:
Added additional /LIBPATH path under Properties ->Linker->General
Added explicit lib references under Properties->Linker->Input
Added all the paths containing LEDA header files and libraries to every path location I can find, like include path, reference path, library path.
Copied the DLLs and LIBs to the release folder as well as the base folder of the project.
Added a #pragma comment( lib, "leda" )
Still no joy.
It's quite bad since none of the custom typedefs are recognised the errors balloon to 646 errors.
If anyone is kind enough to offer assistance, thank you.
I can't guarantee this will work but try the following steps (therefore using it's default predefined paths instead of setting your own ones) :
1) Copy *.dll into Windows/System32 or / and (there is some confusion about x64 and x32 default checking in my head :)) Windows/SysWOW64.
2) Copy *.h files into x:\PathToVC2010\include\
3) Copy *.lib files into x:\PathToVC2010\lib\
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.