It's probably outside of the set of possible solutions to your particular
problem, but I'll mention this one in case it interests others following
the topic. For potentially the broadest compatibility, one could consider
using the LSB (Linux Standards Base) to build binaries that are guaranteed
to
> I was also doubting about libstdc++ versions, is there maybe a way of asking
> Cmake to statistically include it in the built library?
I assume you mean statically. If so then you could try invoking cmake
like this on the command line.
```
mkdir new_build_dir
cd new_build_dir
Thanks for all the feedback.
I cannot go into the details, but the deployment target is a production
machine for which I have no installation privileges, and where
"stability is king", so asking for updates is out of the question. I am
offered an Eclispe environment and have to work on it,
On 1/27/2017 10:04 AM, Michele Portolan wrote:
I have a project that build correctly using gcc 4.9.3, generating a
dynamic library that I can later link to obtain my executables. So,
nothing special.
My problem is that on one of my target systems, I only have a gcc 4.1.2
and I am forced to use
27.01.2017, 21:05, "Elizabeth A. Fischer" :
> C++ code is not compatible between different compilers.
This is not true for compilers implementing Itanium C++ ABI, including GCC.
The only possible source of incompatibility comes from different standard
library
27.01.2017, 20:04, "Michele Portolan" :
> I have a project that build correctly using gcc 4.9.3, generating a
> dynamic library that I can later link to obtain my executables. So,
> nothing special.
>
> My problem is that on one of my target systems, I only have
> C++ code is not compatible between different compilers.
This is only kinda-sorta true. Clang and G++ interoperate quite nicely
on Linux, for instance, since they both implement the Itanium-style ABI.
I believe Intel's C++ compiler on Windows implements the same ABI as
MSVC++.
There are no
If the target platform has an adapted gcc that does not match upstream gcc, or
may not be possible to just compile a newer version. Or it is a discontinued
arch.
Am 27. Januar 2017 19:05:09 MEZ schrieb "Elizabeth A. Fischer"
:
>C++ code is not compatible
C++ code is not compatible between different compilers. You cannot link
C++ code built with GCC 4.9.3 with GCC 4.2.1. Maybe if you hack around and
find the GNU C++ libraries from your GCC 4.9.3 installation... just maybe,
with enough hacking, it will work. But in general, this is a rabbit hole
It depends very much on your target system. The C++-ABI between 4.9 and 4.1 may
be compatible but that is not guaranteed. C++14 is also a bit unspecific:
language features or library features? Does your library expose any C++11/14
features in its interface?
It may just not be possible after
Your answer is totally unrelated to the question.
Am 27. Januar 2017 18:23:39 MEZ schrieb "Elizabeth A. Fischer"
:
>Get spack, then use it to build GCC 4.9.3 takes a couple hours of wall
>time, five minutes of your time.
>
>Github.com/llnl/spack
>On Jan 27, 2017
Get spack, then use it to build GCC 4.9.3 takes a couple hours of wall
time, five minutes of your time.
Github.com/llnl/spack
On Jan 27, 2017 12:04 PM, "Michele Portolan" <
michele.porto...@grenoble-inp.fr> wrote:
> I have a project that build correctly using gcc 4.9.3, generating a
> dynamic
27.01.2017, 20:04, "Michele Portolan" :
> I have a project that build correctly using gcc 4.9.3, generating a
> dynamic library that I can later link to obtain my executables. So,
> nothing special.
>
> My problem is that on one of my target systems, I only have
I have a project that build correctly using gcc 4.9.3, generating a
dynamic library that I can later link to obtain my executables. So,
nothing special.
My problem is that on one of my target systems, I only have a gcc 4.1.2
and I am forced to use it for at least linking the last executable.
14 matches
Mail list logo