I downloaded Eigen 3.2.8. (zip file) but I don't know how to compile it. I have read its documentation but they have not described it briefly. I am new into this field so I don not know where to extract files and how run it.
Eigen is a header only library. You don't have to compile it.
You just extract Eigen into any directory and specify that directory as "Include directory" for your project (how to do so, depends on IDE or build system you use).
Related
I am using Code::Blocks with wxwidgets and I have include and lib folders under Document\wxwidgets. I am very new to c++ libraries. In Code::Blocks project initialization, I entered the location for wxwidgets. Then in setting/global enviornment variables I entered in base the Document\wxwidgets again. Still, I am not able to run the app. It shows the error in the include/wx/platform.h file where it says
C:\Users\Programming coder\Documents\wxwidgets\include\wx\platform.h|148|fatal error: wx/setup.h: No such file or directory|
I am not able to solve this and would appreciate some help. Also I checked and the wx folder does not seem to be there in the location. I don't know if that is normal.
Also, I downloaded the headers(include) from the wxwidgets github repo download page, wxWidgets-3.1.1-headers.7z. Any help appreciated.
Also, I am aware some questions exist already, but their problems are in different because most are using linux. Also I am using Code::Blocks IDE.
You need to build wxWidgets itself before building the applications using it. Its build process will create the setup.h file which is currently missing.
Note that, in principle, you could also use precompiled binaries, but in this case you must use exactly the same compiler as was used for compiling them, i.e. TDM gcc.
I am trying to build Quantlib using Boost Libraries.
I followed the instructions here: and also on the Quantlib website.
I downloaded and unzipped boost_1_57_0 into C:\program files
I then used the Visual Studio 2013 x64 Native prompt to go to the boost directory and ran
bootstrap.bat
and then
b2 --toolset=msvc --build-type=complete architecture=x86 address-model=64 stage
Then I opened Quantlib_vc12.sln in Visual Studio 2013.
Picked "Release" and "x64", opened "Quantlib" in Property Manager and set the VC++ Directories.
In the include directories I added C:\Programm Files\boost_1_57_0
In the Library Directories I added C:\Program Files\boost_1_57_0\stage\lib
Then I went to the Solution Explorer and right clicked and chose build.
I got one LNK1104 error.
LNK1104: cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
Please see attached screenshot:
I have no idea how to fix this and I would really appreciate some help. I had successfully installed this at work using an admin account but was not able to access Quantlib using my user account. I have since deleted and attempted installations atleast 15 times but it's not working. I am worried that all these attempts at installing may have messed something else up, like some registry (I have no idea how that works but I only know to be afraid). Please help! Thanks.
UPDATE: Still get the same error after adding BOOST_AUTO_LINK_NOMANGLE define to project.
UPDATE2: I am getting these messages on the screen while running b2 to build boost. Is this an error I need to fix?
This is exactly what I warned you about in another related question/answer. What's happening here is that the boost headers you are including in this quantlib are (through macros) detecting that you're using MSVC, detecting the version, then automatically linking the required DLL files to build quantlib using #pragma comment(lib....). So even though under Project Settings -> C/C++ -> Linker there are no external DLL's or Lib's specified, they're still being linked by these pragma statements.
So when these macros are detecting your compiler and so on, they're dynamically building a string name of what they think the required libraries would be named on your system. Remember when you built boost, you specified the -layout option. This the naming layout of your boost libraries. Well by default, that layout is something like this:
LIB_LIBRARY_NAME_COMPILER_VERSION_SingleOrMultiThreaded_BOOST_VERSION.LIB
Which in practice looks like this:
libboost_unit_test_framework-vc120-mt-1_57.lib
This is boost "mangling" the name of your library to be as descriptive as possible about how the libraries were build so that, just by glancing at the file name, you know. What we do with -layout=system is tell the boost build system NOT to mangle the names, but to name them according to what option we gave to "layout". Since we chose layout=system, boost is going to name our libraries like this:
LIB_LIBRARY_NAME.LIB
Which in practice will produce:
libboost_unit_test_framework.lib
So when we start using boost after doing this (with MSVC only does this happen), these dynamically generated linker statements don't give a rip about or know about what -layout option you built boost with. They will attempt to link in required libraries using the fully mangled naming format, which is why you get the error:
cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
.. because you don't have a file named that! That's the mangled name! You have a file named libboost_unit_test_framework.lib. See the difference! So, you need to tell these stupid macros to stop mangling the library names when auto-linking required libraries. You do that by adding the following preprocessor definition to your Quantlib project:
BOOST_AUTO_LINK_NOMANGLE
You add that in Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions.
If you'd rather avoid this headache and don't care about the long and (imo ugly) mangling that boost does to library names, you can build boost omitting the -layout option and it will default to this mangled naming convention, where you shouldn't get stuck on this error at all anymore. I personally put out the effort to keep nice short/clean library names but it's all about preference.
Edit
Since you have the same error after fixing the NO_MANGLE problem, then the only possible reason that you're getting this particular link error is that you do not have whatever file the linker is complaining about missing stored in any of the directories supplied to the linker.
Verify the folders/paths you provide to the linker and verify that the file the linker is looking for is in one of the directories that you're providing to the linker. You have to provide directories to the linker because you're telling the linker "you can look in all of these places for the libraries my project needs". If you specify none, it's got nowhere to look. :(
Example:
I'm trying to link the shared library of boost thread into my application.
System: Windows8
IDE: Visual Studio 2010
I build the boost library using:
b2 --with-thread --build-type=complete link=shared
I can see the
boost_thread-vc100-mt-gd-1_55.dll
boost_thread-vc100-mt-gd-1_55.lib
and other file inside the stage/lib directory
I've added the path to Additional Library Directories and Input in linker option as:
Additional Library Directories: C:/boost_1_55_0_dyn/stage/lib
Input: C:\boost_1_55_0_dyn\stage\lib\boost_thread-vc100-mt-gd-1_55.lib
I don't know why on the earth Visual Studio is looking for libboost_thread-vc100-mt-gd-1_55.lib. I haven't mentioned the libboost_thread-vc100-mt-gd-1_55.lib anywhere in the properties or any place. I even search all my files and folders inside the project, libboost_thread-vc100-mt-gd-1_55.lib is not mentioned anywhere.
Well I forgot to put BOOST_ALL_DYN_LINK in preprocessor definition. If the BOOST_ALL_DYN_LINK is not defined, boost looks for static library, that is why its looking for libboost_thread-vc100-mt-gd-1_55.lib
This is additional information to the answer Pritesh already posted, but I'm new here so I can't comment.
It boils down to compatibility between your VS project settings and the way the boost libraries were built. It gets a little tricky because boost and VS do some autolinking for you. Check out the file …\Include\boost\config\Auto_link.hpp. It explains the algorithms and macros that will cause libraries that you didn't explicitly include to show up in your project.
For example, BOOST_ALL_DYN_LINK is used to help determine if the boost library name should have "lib" pre-pended to the name during autolink.
Additionally ,
If you are using cmake and qibuild you can try this :
It automatically links with the corresponding libraries and make their headers available.
qi_use_lib(yourProgramName your libraries)
like this:
qi_use_lib(getimages ALCOMMON ALPROXIES ALVISION OPENCV2_CORE OPENCV2_HIGHGUI OPENCV2_IMGPROC)
How to build a .bundle from source code?
This might sound like a simple problem but it has been hurdling me for a week...
Here is my problem:
I have a bunch of .c and .h files that are organized in a folder and its sub folders. The source code was written and compiled with gcc make and tested by many other make tools. The source code has some utilities and command line tools and it has more code that serve as library for those utilities and tools. It is the files that serve as libraries that I want to reuse. (By library I don't mean static library or something, I just mean that some .c and .h files in certain subfolders provide functions that can be called by some other .c files. I want to be able to call those functions, too)
Yet my problem is more complex than that: I need to build those .c and .h into a bundle to reuse it. I am not writing my application in C; I am developing in Unity and Unity can only take in .bundle files on Mac OS.
Here is my goal:
Organize the source code folder in a proper way so that I can build them into a bundle in Xcode 4.
Here is where I got stuck:
When building the project I got the following error:
Duplicate symbol _main in
/Users/zeningqu/Library/Developer/Xcode/DerivedData/ccn-cfygrtkrshubpofnfxalwimtyniq/Build/Intermediates/ccn.build/Debug/ccn.build/Objects-normal/i386/ccndsmoketest.o
and
/Users/zeningqu/Library/Developer/Xcode/DerivedData/ccn-cfygrtkrshubpofnfxalwimtyniq/Build/Intermediates/ccn.build/Debug/ccn.build/Objects-normal/i386/ccnd_main.o
for architecture i386
I can relate to this error because I can find lots of main entries in the source code. Most of them are test utilities.
Here is what I tried:
I tried removing all those utility .c files but with no luck. The error is still there. I delete and delete until some files cannot find the definition of the function they are calling. So I had to stop there.
Though I wasn't able to build a bundle I was able to build a C/C++ static library (with an .a extension). After I got the .a file I tried to put it into another Xcode project and tried to build it into a bundle. I could build a bundle in that way, but then I had problem accessing the content of the bundle. How do I call functions defined in a .a static library if that library is hidden in a bundle? I read about Apple's documentation which says:
Note: Some Xcode targets (such as shell tools and static libraries) do
not result in the creation of a bundle or package. This is normal and
there is no need to create bundles specifically for these target
types. The resulting binaries generated for those targets are intended
to be used as is.
(quoted from: https://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFBundles/AboutBundles/AboutBundles.html#//apple_ref/doc/uid/10000123i-CH100-SW1)
Here is what I thought about:
I thought about replacing all main with something like main_sth. But the source code was not written by me so I didn't want to modify it. (It just doesn't feel like a proper way of doing things to me...)
I learnt that Xcode has gcc compiler built in. So I guess if gcc can make it, so can Xcode? It's just a wild guess - I am not familiar with Xcode and gcc.
Here is a summary of my questions:
Is there a way to properly organize a pile of code previously compiled and made by gcc make so that they can be built into an Xcode bundle?
Is it meaningful to put a .a library in an Xcode project and build it into a bundle? If it is meaningful, how do I call functions defined in .a after it is built into a bundle?
Is it proper to just replace all main() entries with something else?
Alright I think I have figured out at least one solution to the problem.
The duplicate main error was caused by a bunch of main entries in my source code. When the code was compiled by gcc make, I guess the author defined a sort of compilation order so that duplicate mains won't be an issue. (If you know how to do this, please let me know. I barely know make tools.) But when I just add the entire source code folder into my Xcode project, of course Xcode would complain during linking...
As I was unwilling to modify the source code (because the source code library is not developed by me), I decided to use another strategy to walk around this problem.
If your duplicate main error was reported from your own code, you can stop reading here. But if you are like me, with a bunch of gcc compiled source code and badly need a bundle yet don't know what to do, I may be able to help.
Okay here is what I did:
I set up an empty workspace.
I built a C/C++ static library project.
Import my entire source code folder into the static library project.
Set some header search path for the static library project.
Build the static library project. (Now I have a .a library which I could link against)
I set up another project, with a bundle target.
At the bundle project -> Build Phases -> Link Binary with Libraries, add the .a library that I just built.
At the bundle project -> edit scheme -> Build, add the static library project to the scheme and move it up the list so that it is built prior to my bundle project.
Then add .h files of my library project to my bundle project as references.
After that, add a .c file in my bundle project that basically functions as a wrapper. I picked a function that I want to call in Unity, wrote a wrapper function in the new .c file, and was able to build the bundle.
After several trial and error, I was able to import the bundle into Unity and was able to call the test function from Unity.
I was really excited about this! Though it's not completed yet I think this gives me hope and I am confident I can use the source code now! And the best thing about this solution is that I don't have to modify the library code developed by others. Whenever they update their code, I just update my .a library and that's it!
Though I have listed 11 steps I still feel that there are lots of details that I missed. So here are my references:
I followed this tutorial to build my source code into a static library: http://www.ccnx.org/?post_type=incsub_wiki&p=1315
I followed this blog to link static library against my bundle code and twist build phases and search headers: http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/
I followed this doc to import my bundle to Unity3D Pro as a plugin: http://unity3d.com/support/documentation/Manual/Plugins.html
I strongly recommend the second reference because that's what solved my problem!
Though the problem is almost solved there are still a few things that I haven't figured out:
I don't know if a wrapper function is at all necessary. I will try this out tomorrow and come back to update.
-- I am coming back to update: the wrapper function is NOT necessary. Just make sure you have all the headers in your bundle project and you will be able to use all the data structures and call functions defined in your headers.
I haven't used NSBundle class though I read a few docs about it. Previously I was thinking about using that class to access my .a library encapsulated in my bundle, but as I found the solution I wrote above, I didn't try the class out.
Lastly, if you have better solution, please don't hesitate to let me know!
I tried to follow the steps in the accepted answer, but had no luck. In the end, I realised step 10 needed to be modified slightly:
Create a dummy.c under (.bundle) project and the dummy.c can just be totally empty.
Remove the setting for the library you want to link inside Link Binary With Libraries
Instead use -Wl,-force_load,$(CONFIGURATION_BUILD_DIR)/libYourLib.a or -all_load to Other Linker Flags
PS: And also can use sub-project instead of workspace. and use Target Dependencies instead of Edit Scheme to achieve the same effect.
I've created, debugged, and revised a project that I've been working on, but now I want to be able to specify what version of the binary I'm on. I'm using Eclispe-CDT with MinGW to make this project on my local system, so there is no versioning software involved. Does anyone know how to specify this for both Windows and Linux platforms?
On Windows, the idea is to produce a COFF file with the relevant information.
That is done by adding a step to the build, using windres (found also here).
See this thread as an example.
you could add windres via the project properties/Builders as an additional builder and add the generated object file in the C/C++ Build/GCC C++ Linker/Miscellaneous/Other Objects.
Then you
- a) could do a clean build if the resource is changed or
- b) could change the build options (if you have patience) to change to do a clean build every time you save the project.
On Unix, this doesn't seem to be supported in a similar fashion.