Why has support for Intel been dropped on Fedora 15 ?

Why has support for Intel been dropped on Fedora 15 ?

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 ?

12 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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

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.

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

Thanks, Vladimir!

[ bustaf wrote ]
>>...
>>I think major problems could be side C++ with
>>some member of class have change.
>>...

I didn't understand it and if it would be true then it would be a really big problem with the compiler. As Vladimir explained the reason is End Of Life for the software.

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.

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

>>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.

[/quote]

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).

>>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 ?

Many software companies deal with similar problems. I mean usage of some legacy, obsolete, deprecated, etc software. I could give you a generic advise:

Workaround a problem as soon as it is detected

Quote:

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.

Even if the Fedora 15 operating system is Not supported any longer you could use it for many more years ( right? ) and it is possible to use a latest version of GCC compiler ( some restrictions apply ) for compilation of C/C++ sources.

As soon as you have a problem with compilation you could report it on the IDZ or any other forums. Somebody could help you to resolve it.

Leave a Comment

Please sign in to add a comment. Not a member? Join today