We have Oracle 11 running on HP-UX 11.31 and gcc 4.4.3. It seems that there is no way to link to occi, because it was built with aCC. Is there any workaround for this?
I had the silly idea that I could somehow build a library that basically proxied the connection - build the library with aCC in some way that could be linked to by gcc. Is this possible?
No, there isn't a way around that.
Different C compilers have interchangeable code using a standard ABI. You can mix and match their object code more or less with impunity.
However, different C++ compilers have a variety of different conventions that mean that their object code is not compatible. These relate to class layout (especially in multiple inheritance hierarchies and the dreaded 'diamond-of-death'), but also in name mangling conventions and exception handling. The name mangling schemes are deliberately made different so that you cannot accidentally link objects from one compiler with another.
Generally, if libraries are built using a C++ compiler, you have to link your code using the same - or at least a compatible - C++ compiler. And that almost invariably means a compiler from the same family. For example, you might be able to use G++ 4.5.0 even if the code was built with G++ 4.4.2. However, you won't be able to mix aCC with G++.
Related
I struggled to find a clear answer on the first Google page.
I have troubles understanding the term "Language standard". I mean, the new standard should be implemented on a software level, right? It's not just a list of things discovered that users can now do, right?
I use delegating constructors, get a warning:
[Warning] delegating constructors only available with -std=c++11 or -std=gnu++11
Though things seem to work the way I want them to. Is such warning critical? If so, how do I get rid of it?
Dev-Cpp is just IDE (frontend) for coder and behind it sits MinGW with GCC 4.9.2 as compiler*. So every time you click "Run" or "Build" it is GCC to do the dirty job. GCC by default uses C++03 standard and to use newer one you have to tell it explicitly via compiler flag -std=c++11. You can change it in Tools->Compiler Options->Settings->Code generation->Language standard (-std).
I am not sure why delegating constructors could work without C++11 (probably some GCC feature), but for sure you will not be able to use C++11 libraries without -std=c++11. It will also get rid of the warning.
(* Assuming you used default Dev-C++ installer.)
I built boost libraries with msvc. And I want to link to my program using mingw. As the title asked, how can I achieve that?
When I try to link the boost libraries. The compiler suggests that it can't find symbols of the boost libraries.
Quoting the mingw wiki here:
Object files and static libraries created with different compilers [...] often cannot be linked together. This issue is not specific to MinGW: many other compilers are mutually incompatible. Build everything from source with the same version of the same compiler if you can.
It is stated in the same page that if you want, you may use dynamic (shared) libraries from different compilers if you provide a C interface for the library you want to use. Then your program would use this interface (C wrapper library) to communicate with Boost, by including the header for this interface library with extern "C". Example of doing this can be found here.
In your case, however, this would not be preferable as you would have to expose everything you want to use from Boost one by one in the C interface that you would write yourself. You might find it much easier just compiling your libraries with the same compiler you are compiling your program with.
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 a set of software library modules which are developed in c++. So, I use g++ to compile my software.
This has to be used by various existing applications which are written in C and compiled with gcc.
When the other teams used g++ to compile their code, they started getting lot of compiler errors due to strict type checking rules of c++. This broke their applications. Worse still, they are using some 3rd party library code, which cannot be compiled using g++.
if they use gcc, then there are linker errors (unresolved symbols).
so, my question is...
"Is there a way for my library code to be linked with their applications, without changing the respective compilers? That is, i still have to use g++, since i use classes/objects heavily in my code, and they have no choice of using g++, which will break their application?".
Thank you for kind help.
regards,
Ravindra
One of the problems you may be experiencing could be the result of different versions of g++ having different ABI formats. at very least, don't expect versions of G++ prior to 4.1 to work with code compiled with 4.1 or later.
Intermingling C and C++ requires that the C++ code all export a C compatible interface. This is done by declaring free functions (cannot be used on classes) with the extern "C" specifier. (some notes on the c++ faq lite_
extern "C" {
#include "c_language_headers.h"
int c_accessible_function(int);
struct c_accessible_datatype { };
}
This question must apply to so few people...
I am busy mrigrating my ARM C project from Winarm GCC 4.1.2 to Yagarto GCC 4.3.3.
I did not expect any differences and both compile my project happily using the same makefile and .ld files.
However while the Winarm version runs the Yagarto version doesn't. The processor is an Atmel AT91SAM7S.
Any ideas on where to look would be most welcome. i am thinking that my assumption that a makefile is a makefile is incorrect or that the .ld file for Winarm is not applicable to Yagarto.
Since they are both GCC toolchains and presumably use the same linker they must surely be compatable.
TIA
Ends.
I agree that the gcc's and the other binaries (ld) should be the same or close enough for you not to notice the differences. but the startup code whether it is your or theirs, and the C library can make a big difference. Enough to make the difference between success and failure when trying to use the same source and linker script. Now if this is 100% your code, no libraries or any other files being used from WinARM or Yagarto then this doesnt make much sense. 3.x.x to 4.x.x yes I had to re-spin my linker scripts, but 4.1.x to 4.3.x I dont remember having problems there.
It could also be a subtle difference in compiler behavior: code generation does change from gcc release to gcc release, and if your code contains pieces which are implementation-dependent for their semantics, it might well bite you in this way. Memory layouts of data might change, for example, and code that accidentally relied on it would break.
Seen that happen a lot of times.
Try it with different optimization options in the compile and see if that makes a difference.
Both WinARM and YAGARTO are based on gcc and should treat ld files equally. Also both are using gnu make utility - make files will be processed the same way. You can compare the two toolchains here and here.
If you are running your project with an OCD, then there is a difference between the implementation of the OpenOCD debugger. Also the commands sent to the debugger to configure it could be different.
If you are producing an hex file, then this could be different as the two toolchains are not using the same version of newlib library.
In order to be on the safe side, make sure that in both cases the correct binutils are first in the path.
If I were you I'd check the compilation/linker flags - specifically the defaults. It is very common for different toolchains to have different default ABIs or FP conventions. It might even be compiling using an instruction set extension that isn't supported by your CPU.