- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I read in the release notes for ICC - Linux that support on Linux Fedora 15 has been dropped and the compiler is supported on Fedora Kernel 17 onwards. Is there a reason why support was dropped on Fedora 15 ? Were there runtime library compatibility issues or were there other reasons for this decision ?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
ICC is not an standalone compiler it depend to an alignment compatible
with the specificity of version GNU compiler installed in your distribution.
If you don't have choice for upgrade your system
you can compile last source compiler GNU with
all the required for his dependency.
With old version gnu compiler
I think major problems could be side C++ with
some member of class have change.
I read that Fedora 15 have 4.6.0... I don't know if linker on your binutils
have correct (ELF/GOLD) ???
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't have inside knowledge on this question, but I take the meaning to be that FC 15 is not tested during development of new compilers, presumably because it is obsolescent. For example, support of some new C++ features is based on gcc 4.7, so you might lack parts of -std=c++11 until you upgraded g++.
For the most part, you would expect applications which worked on older icc versions to continue working with newer ones, but it's impractical to continue full testing (omitting new syntax) for linux distros which have been superseded.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello, quick answer is that
fedora 15 reached its EOL 1 year ago https://lists.fedoraproject.org/pipermail/announce/2012-July/003091.html
fedora 16 reached its EOL 6 months ago https://lists.fedoraproject.org/pipermail/announce/2013-February/003144.html
There is no sence to support OS that is not supported by OS creator.
--Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks to all for the inputs. It seems to be a situation where minimizing the cost of testing across fewer OS versions has been the main criterion for dropping support rather than incompatible runtimes across compiler versions ( say from 4.6 to 4.7). icc and gcc4.6 in conjunction may still work, though it may not have been tested. Typically for the binaries to be compatible, the runtime versions used by them along with the ABIs should be compatible.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sergey Kostrov
It could be better that you see the headers linked with (string) ,
and you compare difference old and new before to add your comment
that is of too, I think ....
That it's would be a really big problem is that programmer black belt don't know
this one...is know as the wolf is white....
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>I don't have inside knowledge on this question, but I take the meaning to be that FC 15 is not tested during development of new compilers, presumably because it is obsolescent. For example, support of some new C++ features is based on gcc 4.7, so you might lack parts of -std=c++11 until you upgraded g++.
Does the Intel compiler use the same libstdc++ library used by the default gcc compiler installed on the system ? For the glibc, runtime libraries how does the situation change ? I know for sure that Intel implements it's own floating point arithmetic libraries like svml etc etc and doesn't use all of glibc as is. It also has it's own version of fast_memset and fast_memcpy which are separate from the default gcc runtime.
The replies given by others do explain why the OS version is not supported, but I am looking at the problems that may crop up because of linker incompatibilities, ABI incompatibilities or incompatibilites due to icc making calls directly into the kernel. Does icc actually do that either for it's own implementation of libstd-c++, memcpy or svml ? How about CILK ?
For the most part, you would expect applications which worked on older icc versions to continue working with newer ones, but it's impractical to continue full testing (omitting new syntax) for linux distros which have been superseded.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
The answers given here are all pretty much correct. From the compiler perspective, gcc versions (and associated glibc/libstdc++) and binutils versions are the most key, and starting with Intel® Composer XE 2013 SP1, we'll be documenting the range of gcc and binutils versions that we support. We'll also continue to have the list of operating systems supported as well, and the install will still warn if installing on an unsupported operating system version. But in most cases (not all), if an unsupported operating system has a version of gcc and binutils in the range we'll be giving things should work.
Our general guideline is that we try to support 1-2 versions of popular Linux distributions that are most recent at the time of the Composer XE product launch. In the specific case of Fedora, they update pretty frequently, so these supported versions jump up several versions each release (from 15 to 17 in our latest release).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sunil Gokak wrote:
Does the Intel compiler use the same libstdc++ library used by the default gcc compiler installed on the system ? For the glibc, runtime libraries how does the situation change ? I know for sure that Intel implements it's own floating point arithmetic libraries like svml etc etc and doesn't use all of glibc as is. It also has it's own version of fast_memset and fast_memcpy which are separate from the default gcc runtime.
The replies given by others do explain why the OS version is not supported, but I am looking at the problems that may crop up because of linker incompatibilities, ABI incompatibilities or incompatibilites due to icc making calls directly into the kernel. Does icc actually do that either for it's own implementation of libstd-c++, memcpy or svml ? How about CILK ?
icpc finds libraries according to g++ --print-search-dirs so it uses the same as the active g++ (except where there are pre-empting functions provided with icc). There is no Intel-specific libstdc++ or other STL in the versions under discussion. The compiler support functions you mention aren't likely points of incompatibility. If you would upgrade g++ to the equivalent of the FC supported by the newer icpc of interest, you would likely gain the supported c++11 features.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page