- For changes since the 8.0 series see the installed C++ReleaseNotes.htm
but note that information given there doesn't necessarily apply to ICC
on FreeBSD, e.g. -cxxlib-gcc isn't the default on FreeBSD yet and this
port also doesn't install the Eclipse and CDT IDEs.
- ICC now unfortunately requires emulators/linux_base-8.
- Works fine for compiling C source.
- A 6.0-current GENERIC kernel compiles and boots.
- The devel/stlport-icc port currently can't link the exception handling
testsuite with this ICC version (due to relying on a missbehaviour of
the old ICC versions) and has to be changed in a way that doesn't break
lang/icc7.
- Support for using the GCC-compatibility of ICC on FreeBSD and using
the GNU libstdc++ as the STL with ICC is in the works.
o Like with the system GCC, default to libpthread for the threads library
on FreeBSD >= 502102.
Approved by: netchild
In joint forces with: netchild
where appropriate [1]
- make portlint happy [1]
- sync icc7 and icc [1]
- add linux_base as a patch depends for icc v8
Submitted by: Marius Strobl <marius@alchemy.franken.de> [1]
Requested by: maintainer [1]
- correct the use of ECHO_CMD and ECHO (swap them) [1]
icc:
- fix the DISTFILE handling, it's automatically available after
bsd.port.post.mk, not after bsd.port.pre.mk, so set it explicitly
to be able to use it in the check for the IGNORE message [1]
icc7:
- don't extract the Intel debugger, it's not usable without a
threads debugging lib
- USE_SIZE
Noticed after: reading the commit log/diff of the
ifc port [1]
Submitted indirectly by: maho, hrs [1]
- add intel-patch target to easy porting effort of future versions [1]
- remove intel debugger rpm, as long as we don't have a libthread_db
we can't use it [2]
Note: The stlport-icc exception handling test will still fail with this
version.
Suggested by (sort of): Marius Strobl <marius@alchemy.franken.de> [1]
Noticed by: Marius Strobl <marius@alchemy.franken.de> [2]
As Intel uses it's own directory for ifc and icc, we don't conflict with
ifc anymore.
Because of ABI changes, you have to recompile C++ programs (don't forget
stlport-icc).
Note that this port is a _work in progress_:
- Icc allows to use an already installed libstdc++ from gcc, this doesn't
work yet on FreeBSD. Libstdc++ on 4.x is too old, so it's unlikely we
can add support for it. The headers of libstdc++ shipping with FreeBSD
5.2-CURRENT use GCCisms not (yet) supported by icc, the hardcoded search
path for them also doesn't fit for FreeBSD 5.2-CURRENT.
- We've incorporated parts (cxa) of the FreeBSD >= 502101 libc on < 502101
systems. It's tested on 4.x, but not on FreeBSD < 502101.
- Not all (new) options (including GCC compatibility) are thoroughly
tested.
When encountering problems please report to me first instead of directly
contacting Intel.
Ackknowledgements:
- Bradley T Hughes <bhughes@trolltech.com> for PR 59552, it resulted in
a modification of our libc (C++ DSO Object Destruction API) we
incorporate in the port on < 502101 systems.
- Marius Strobl <marius@alchemy.franken.de> for his help with the port
(e.g. ld.c, cxa).
NOTE: you need to rebuild stlport-icc and maybe some other C++
programs/libs.
- rework ld.c to fix the build of stlport-icc on 4.x (first part
of the build fix, the second part follows shortly in a stlport
commit) [1]
Submitted by: Marius Strobl <marius@alchemy.franken.de> [1]
script was renamed to solve a conflict with archivers/rpm) to fix possible
build problems.
I've tested this with lang/icc. Any new errors because of this commit in
one of the modified ports may be because the ports previously may have used
rpm2cpio from archivers/rpm instead of the used {EXTRACT,BUILD}_DEPENDS
archivers/rpm2cpio.
- Transform some warnings into errors as suggested by some included
docs (some kind of MSVC compatibility which isn't reverted in icc
for linux).
ld.c:
- add possibility to use a different threads lib via PTHREAD_LIBS
variable (e.g. PTHREAD_LIBS=-lthr) [1]
this may be subject to change when gcc learns how to handle our
different threads libs
- refactor some code [1][2]
- remove mailwrapper license, there's no code from mailwrapper
anymore [2]
- correct the order of libc and libc_r [1][2]
Submitted by: mi [1]
Submitted by: Marius Strobl <marius@alchemy.franken.de> [2]
Reviewed by: Marius Strobl <marius@alchemy.franken.de> [1]
icc -shared -o libfoo.so foo.o -lbaz
the ld wrapper gets confused and thinks that a static link is intended
and the link fails. This patch appears to fix things.
Submitted by: dfr
(this may break ports which depend upon OpenSSL from ports which was
compiled as a base system replacement because it includes a system
header directory again)
- ignore "-pipe" in CFLAGS, this should unbreak some ports with hardcoded
"-pipe"
Noticed by: Krzysztof Parzyszek <kristof@swissmail.org> [1]
Tested by: Krzysztof Parzyszek <kristof@swissmail.org> [1]
path, thus adding a system path with -I results in not respecting the
sunstitute headers. This results in problems because we have some important
changes there.
Parts of this commit where
Submitted by: marius@alchemy.franken.de
- fix [dfi]vec.h with stlport-iostreams
- do not install a Windows header (mathf.h)
- do not install libompstub (depends on pthread_atfork(), see PR 17437)
Submitted by: marius@alchemy.franken.de
- point to the icc errata after make install
