I'm not very sure about this and I can't seem to find a complete answer. Some of boost's libraries need to be compiled (thread for example, as well as date time for some uses) - obviously one needs to compile them separately on each platform.
What I am interested in is if the hpp files can be shared between platforms. I'm ultimately seeking a directory structure like this:
boost\
include\
...
libs\
nix\
...
win\
...
So, can I:
use the same thread.hpp include in my linux version and my windows version? (thread.hpp needs a compiled lib)
use the same shared_ptr.hpp include between platforms? (shared_ptr.hpp does not need a compiled lib)
Thanks.
Yes, of course in both cases. The .hpp don't change between platforms (maybe with some preprocessing boost has some differences, but nothing you have to care about).
Related
Ubuntu 16.04 comes with GCC 5.4 which does support c++11 and it is the default compiler. By default c++11 is not enabled in that particular version of GCC.
My intent is to use some of the binary libraries (not header only) from their repository (e.g. boost). In my projects I will enable c++ 11.
How were c++ libraries from the repository compiled? Is it possible to use them with c++ 11 enabled? I know that c++ libraries can be called from different languages (Java, Pythons, C# etc) by hiding all c++ stuff behind plain C interface. With boost it is not a case. If a certain function returns me a string or a vector or anything from STL then it is a problem. AFAIK STL objects binary representation depends on compiler flags (eg. std=c++11).
Thank you.
Which exact libraries are you talking about?
If you are talking about the standard library, libstdc++ is a part of gcc. It is always okay to link it no matter which standard you compile at. gcc also made a decision to include ABI tags, so that they can be ABI compatible with code compiled at C++11 and pre C++11. See for instance TC's really nice answer to a question I asked here:
Is this simple C++ program using <locale> correct?
If by
How were c++ libraries from the repository compiled?
you mean, how are all of the C++ libraries in the ubuntu repositories compiled, the answer is, it may be different for each one.
For instance if you want to use libfreetype6-dev or libsdl2-dev, these are C libraries, they will be okay to link to no matter what standard you target.
If you want to use libsilly-dev from CEGUI, that is a C++ library, and it is usually best to use the exact same compiler for your project and the C++ lib that you are linking to. If it appears in ubuntu repository, you can assume it was built with the default g++ version that ubuntu is shipping. If you need to use a different compiler, it's probably best to build the C++ lib yourself -- in general C++ is not ABI stable across different compilers, or even different versions of the same compiler.
If you want to use compiled boost libraries, it's probably best to use the libs they give you and use the compiler they give you. If you only use header-only boost, then the compiler doesn't matter since you don't actually have to link with something they built. So you then have more flexibility with respect to compilers.
Often, if you need to use C++ libraries, it's best to integrate their build system into yours so that it can be easily rebuilt from source and you only have to configure the compiler once. (At least in my experience.) This can save a lot of time when you decide to upgrade compilers later. If you use cmake then it's often feasible, but sometimes this can be hard, especially if you have a lot of C++ dependencies. If you don't use cmake, well, many libraries use cmake and it won't be that easy to integrate them this way. cmake is still kind of a pain anyways, so this might not be such a loss.
I have built a ADA static library and I share it by providing '.a' and ALI files.
Everything works fine while I use the same GNAT compiler version than the one used to build the static library.
But with another compiler version, the ALI files are considered as not valid (the compiler version is stored in all ALI files), and the compiler needs source files to rebuild ALI files.
Is there a solution to avoid this problem ?
updated on 12/11/2015 : We did some tests (with ALI library files in ready only), but we still have the following errors :
error: "package1.adb" and "prog.adb" compiled with different GNAT versions
error: "prog.adb" must be recompiled ("system.ads" has been modified)
So, I think we have to use the same compiler version for the library and the program.
If you are using gnatmake, make the ALI files read-only, so that the compiler does not try to recompile them (you are of course responsible for ensure that the object files are compatible, but this is in general the case).
If you are using project files, add a
for Externally_Built use "True";
attribute to achieve the same effect.
Answer from AdaCore :
This isn't supported: the Ada ABI (Application Binary Interface) is not guaranteed to stay the same across versions (and indeed does change regularly), so you cannot mix objects compiled with different versions of GNAT, you really need to ensure consistency in all your libraries.
So, it's not possible.
the total size of the boost dlls and .lib files is coming to around 3.6 gb.I may not use all the dlls and lib files. Assume that I'm only including the Boost/Date and time. Are all the other files needed for the boost compilation ? Are the dlls and the lib files specific to windows and linux ???
You don't need .dlls to compile something at all. Technically, you don't even need .libs to compile; only to link, but I'll assume you meant both. You need .dlls to run however, so I'm not sure what that buys you.
And yes, .dlls and .libs are specific to the platform. And in the case of .libs, the compiler.
the total size of the boost dlls and .lib files is coming to around 3.6 gb.
What configurations did you build for? You only need a debug and a release version. If you built a DLL version, then you don't need to also build a static library version (you'll still get .libs though).
My static-library-only variation takes up ~800MB, and I could probably chop that in half, since I see what appears to be duplication in there.
I am trying to link the libraries from boost to C::B. I have built the files but all I see in all the folders are .hpp files. Are there not supposed to be .lib files?
Going through build options, I gave search directories. I am now trying to do the linker settings. What do I put here. It will only take .lib and other files like that. Any ideas?
Which Boost libraries? The vast majority of Boost libraries are header-only. You only need to include the header file to use them. The only Boost libraries that have actual library files are:
Date_Time
Filesystem
Graph
iostreams
Math
Program Options
Random
Regex
Serialization
Signals
System
Thread
Wave
Also, you're working with GCC. Library files end in ".a", not ".lib" as with Visual Studio.
I'm using Visual Studio .NET 2003, and I'm trying to port code I've written and compiled/run successfully in Linux GCC to Windows.
I'm a newbie when using VS. I've created a new project, and added all the .c and .h files I have into the project by Project -> Add Existing Items, then chose all the .c and .h files.
I'm not familiar with how exactly compilers and linkers etc work, but is there a difference between how VS and gcc compile/link #include files? My habit of programming in Linux has been to have one main.c file, and #include all other .h or .c files that I need. Then I would only compile the main.c file. But in VS, it seems as if the #include files are not "seen" by the program, because I'm getting errors that tell me certain structures or variables were not declared, even though they are in my user-defined header files.
I'm also getting errors like DIR is an undeclared identifier. I've included , so why can't it recognize DIR?
Thank you.
Regards,
Rayne
Consider compiling your program with windows port of gcc (from Mingw32 or Cygwin) first. This will provide you with more familiar environment. If you'll still have to compile everything with VC++, you'll have more incremental process of porting.
Also, it is not evident from your post, but it seems you are trying to use dirent.h. Note that dirent.h (and corresponding libs) is not included with VC++.
One of the best ways to learn would be to start with the smallest application that you can compile on both. Expand this working and portable application step by step into the more fully featured application you desire.
Remember to add all .c/.cpp files to the 'Source Files' directory in the project as they won't be compiled otherwise.
Restrict any non-portable code (that you will need) to a single place. For example if you need to create threads, have a common create thread function used throughout (but implemented differently). Using portable libraries such as Boost can help here.