kpriv/freebsd-ports
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
freebsd-ports/lang/icc/Makefile

229 lines
9.1 KiB
Makefile
Raw Normal View History

This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
# New ports collection makefile for: icc
# Date created: 24.Jan.2002
# Whom: netchild@FreeBSD.org
#
# $FreeBSD$
#
PORTNAME= icc
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
PORTVERSION= 8.0.055.p057
- add category: devel - use reinplace command where appropriate - gzip man page - clarify download instructions (1) - fix typo in a comment (2) - preparation for successfull C++ compiles (2, minor changes by me) Even if I bumped the port revision for the C++ parts, there's no need to update yet, wait until I commit the icc-stlport. Requested by: mi (1) Submitted by: Marius Strobl <marius@alchemy.franken.de> (2)
2002-08-20 12:01:58 +02:00
CATEGORIES= lang linux devel
- update to icc 6.0.149 - use an empty MASTER_SITES to not get mail from fenner's distfile survey Suggested by: fenner - correct the message in IGNORE after obrien's change to linux-base - fill in the product name in docs/csupport
2002-06-08 12:16:20 +02:00
MASTER_SITES=
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
DISTNAME= l_cc_p_${PORTVERSION:C/\.p.+$//}
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
MAINTAINER= netchild@FreeBSD.org
- Update to 7.1.006. Submitted by: marius@alchemy.franken.de - Minor cosmetics (FIND) and corrections (COMMENT).
2003-03-28 11:45:57 +01:00
COMMENT= Intels C/C++ compiler, set up to produce native FreeBSD binaries
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
PATCHLEVEL= ${PORTVERSION:C/(.+p)(.+)$/pe\2/}
.if ${PORTVERSION} != ${PATCHLEVEL}
DISTFILES= ${DISTNAME}${EXTRACT_SUFX} \
${DISTNAME}_${PATCHLEVEL}${EXTRACT_SUFX}
.endif
s/rpm2cpio/rpm2cpio.pl/ after the recent update of archivers/rpm2cpio (the 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.
2003-12-12 14:43:05 +01:00
EXTRACT_DEPENDS= rpm2cpio.pl:${PORTSDIR}/archivers/rpm2cpio
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
RESTRICTED= Intel forbids any redistribution
Style fixes. Submitted by: obrien Approved by: steve
2002-04-16 17:03:49 +02:00
NO_PACKAGE= ${RESTRICTED}
NO_CDROM= ${RESTRICTED}
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
ONLY_FOR_ARCHS= i386
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
CONFLICTS= linux_devtools*
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
Explict dependancy on version 7 of linux_base is not needed anymore. The linux_base port is now at RH version 7.
2002-05-28 05:22:32 +02:00
USE_LINUX= yes
- add category: devel - use reinplace command where appropriate - gzip man page - clarify download instructions (1) - fix typo in a comment (2) - preparation for successfull C++ compiles (2, minor changes by me) Even if I bumped the port revision for the C++ parts, there's no need to update yet, wait until I commit the icc-stlport. Requested by: mi (1) Submitted by: Marius Strobl <marius@alchemy.franken.de> (2)
2002-08-20 12:01:58 +02:00
USE_REINPLACE= yes
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
NO_FILTER_SHLIBS= yes
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
COMPILERDIR= intel_cc_80
Update icc to 7.0.078. Note: Object files built with version 6.0 of Intel(R) Compilers may not link properly with objects built with version 7.0 of Intel(R) Compilers. Rebuilding of the object files is suggested. Changes between the submitted version and the committed version: - update to 078 instead of 075 - treat excessive parameters in function calls as an error instead of a warning (removed compatibility with a not named MS product, as suggested by Intel) - allow to override the INTEL_FLEXLM_LICENSE variable From the submitter: - Unbreak usage of signal.h on -current and RELENG_5_0. (committers note: see below) - Fix ownership of installed files when built as non-root. - Fix the patched versions of the icc- and the icpc-script to work with options containing spaces (e.g. '-DFOOBAR="foo bar"'). - Install 'clicense' and 'csupport' in the docs-dir even if NOPORTDOCS is defined, the later is not optional but required by 'icid'. - Move the ld-wrapper to a sub-dir and thus out of what is normally set in PATH to prevent footshooting (this isn't perfect but simple until someone reworks this port to provide FreeBSD-compatibility in another way... or Intel releases a native version). - Patch the headers to better fit for FreeBSD (hopefully...). Notes: - Icc7 is more picky about unknow options than the previous versions, i.e. the gcc-options normally supplied in CFLAGS unless altered in /etc/make.conf. Therefore compilation of ports with icc likely fail if the standard CFLAGS are not unset (e.g. `make CC=icc CFLAGS=""`) or replaced by options valid for icc. - When compiling multi-threaded C-code make sure to link with icc and option '-mt' (for ports e.g. via PTHREAD_CFLAGS) otherwise libc_r won't be linked in correctly. Submitted by: marius@alchemy.franken.de Additional information: - rev 1.20 of src/sys/i386/include/signal.h introduced __aligned which isn't handled in sys/cdefs.h for non GCC compilers (at least not in publically available sources) - the FreeBSD stdarg.h is missing a macro for va_copy() in the non GCC case, we handle it in the port, but be prepared to get problems when the base system gets fixed - we don't use the icc-buildin of alignof() - Intel provides a float.h which has different floatingpoint values (e.g. MAX_FLOAT) than we have in the base system, in the port we use the FreeBSD header (Warner knows about the issue... at least he got a mail from me and Marius) - we replace __wchar_t with __ct_rune_t because icc has a build-in type for it, this affects "typedef __ct_rune_t __wchar_t;" in sys/_types.h. It isn't known if this may be evil... - icc doesn't need the option "-mt" anymore to generate thread safe code, but our FreeBSD version still needs it to be able to choose libc_r instead of libc If a src-committer wants to address any of the above mentioned issues he should first contact me, I may have already some fixes in my local tree.
2003-01-11 18:21:41 +01:00
PLIST_SUB= COMPILERDIR=${COMPILERDIR}
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
PATCH_WRKSRC= ${WRKSRC}/opt/${COMPILERDIR}
Update icc to 7.0.078. Note: Object files built with version 6.0 of Intel(R) Compilers may not link properly with objects built with version 7.0 of Intel(R) Compilers. Rebuilding of the object files is suggested. Changes between the submitted version and the committed version: - update to 078 instead of 075 - treat excessive parameters in function calls as an error instead of a warning (removed compatibility with a not named MS product, as suggested by Intel) - allow to override the INTEL_FLEXLM_LICENSE variable From the submitter: - Unbreak usage of signal.h on -current and RELENG_5_0. (committers note: see below) - Fix ownership of installed files when built as non-root. - Fix the patched versions of the icc- and the icpc-script to work with options containing spaces (e.g. '-DFOOBAR="foo bar"'). - Install 'clicense' and 'csupport' in the docs-dir even if NOPORTDOCS is defined, the later is not optional but required by 'icid'. - Move the ld-wrapper to a sub-dir and thus out of what is normally set in PATH to prevent footshooting (this isn't perfect but simple until someone reworks this port to provide FreeBSD-compatibility in another way... or Intel releases a native version). - Patch the headers to better fit for FreeBSD (hopefully...). Notes: - Icc7 is more picky about unknow options than the previous versions, i.e. the gcc-options normally supplied in CFLAGS unless altered in /etc/make.conf. Therefore compilation of ports with icc likely fail if the standard CFLAGS are not unset (e.g. `make CC=icc CFLAGS=""`) or replaced by options valid for icc. - When compiling multi-threaded C-code make sure to link with icc and option '-mt' (for ports e.g. via PTHREAD_CFLAGS) otherwise libc_r won't be linked in correctly. Submitted by: marius@alchemy.franken.de Additional information: - rev 1.20 of src/sys/i386/include/signal.h introduced __aligned which isn't handled in sys/cdefs.h for non GCC compilers (at least not in publically available sources) - the FreeBSD stdarg.h is missing a macro for va_copy() in the non GCC case, we handle it in the port, but be prepared to get problems when the base system gets fixed - we don't use the icc-buildin of alignof() - Intel provides a float.h which has different floatingpoint values (e.g. MAX_FLOAT) than we have in the base system, in the port we use the FreeBSD header (Warner knows about the issue... at least he got a mail from me and Marius) - we replace __wchar_t with __ct_rune_t because icc has a build-in type for it, this affects "typedef __ct_rune_t __wchar_t;" in sys/_types.h. It isn't known if this may be evil... - icc doesn't need the option "-mt" anymore to generate thread safe code, but our FreeBSD version still needs it to be able to choose libc_r instead of libc If a src-committer wants to address any of the above mentioned issues he should first contact me, I may have already some fixes in my local tree.
2003-01-11 18:21:41 +01:00
MAN1= icc.1
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
MLINKS= icc.1 icpc.1
MANPREFIX= ${PREFIX}/${COMPILERDIR}/
- add category: devel - use reinplace command where appropriate - gzip man page - clarify download instructions (1) - fix typo in a comment (2) - preparation for successfull C++ compiles (2, minor changes by me) Even if I bumped the port revision for the C++ parts, there's no need to update yet, wait until I commit the icc-stlport. Requested by: mi (1) Submitted by: Marius Strobl <marius@alchemy.franken.de> (2)
2002-08-20 12:01:58 +02:00
- update to icc 6.0.149 - use an empty MASTER_SITES to not get mail from fenner's distfile survey Suggested by: fenner - correct the message in IGNORE after obrien's change to linux-base - fill in the product name in docs/csupport
2002-06-08 12:16:20 +02:00
ICC_SITE= http://www.intel.com/software/products/compilers/
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
.include <bsd.port.pre.mk>
- Fix icc and icpc scripts (variable overriding) [1] - Don't extract ia64 RPMs [2] - Fix bug on some 4.7 systems [3] Noticed by: mi [1] Suggested by: mi [2] Tested by: Clint Olsen <clint@0lsen.net>
2003-10-22 15:21:30 +02:00
EXTRACT_AFTER_ARGS= | tar -xf - \
--exclude intel-isubh\*.rpm \
--exclude \*ia64.rpm \
--exclude flexlm64
- reword pkg-descr - fix iccvars.csh (PR) - mimic some parts of gcc's preprocessor (defines) PR: 36555 Approved by: steve
2002-03-31 21:00:05 +02:00
ICCCFGVAL!= ${UNAME} -r | ${SED} -e 's/\..*//'
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
BRANDELF?= /usr/bin/brandelf
- Update to 7.1.006. Submitted by: marius@alchemy.franken.de - Minor cosmetics (FIND) and corrections (COMMENT).
2003-03-28 11:45:57 +01:00
CPIO?= /usr/bin/cpio
- Keep up with changes on -current (__sF, elf_i386 -> elf_i386_fbsd). - Use an exclude file for cpio, there's not much sense in extracting and chmod'ing a whole bunch of files only to delete them afterwards. - Fix two bugs in the ld-wrapper that could cause it to dump core in rare cases. - Remove a forgotten C++ include. - Improve IGNORE message. Submitted by: marius@alchemy.franken.de
2002-11-08 16:59:38 +01:00
OBJCOPY?= /usr/bin/objcopy
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
.for file in ${DISTFILES}
.if !exists(${DISTDIR}/${DIST_SUBDIR}/${file})
Reword IGNORE text. Suggested by: Intel Corporation
2003-10-11 12:59:45 +02:00
IGNORE= "Go to Intel Premier Support, https://premier.intel.com, to obtain ${DISTFILES}. Product updates such as this compiler are posted regularly on Premier Support. You must have a license to obtain access to Premier Support. If you do not already have a license go to ${ICC_SITE} to review licensing options \(evaluation, commercial, and free non-commercial\) and obtain a license. Put ${DISTFILES} into ${DISTDIR} and run make again"
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
.endif
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
.endfor
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
.if exists(${LINUXBASE}/boot/kernel.h)
BROKEN= Cannot coexist with linux_devtools
- mark BROKEN when linux_devtools or ifc is installed - make it more clear that you shouldn't install linux_devtools in the post install message
2002-11-08 21:17:54 +01:00
.endif
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
post-extract:
Update icc to 7.0.078. Note: Object files built with version 6.0 of Intel(R) Compilers may not link properly with objects built with version 7.0 of Intel(R) Compilers. Rebuilding of the object files is suggested. Changes between the submitted version and the committed version: - update to 078 instead of 075 - treat excessive parameters in function calls as an error instead of a warning (removed compatibility with a not named MS product, as suggested by Intel) - allow to override the INTEL_FLEXLM_LICENSE variable From the submitter: - Unbreak usage of signal.h on -current and RELENG_5_0. (committers note: see below) - Fix ownership of installed files when built as non-root. - Fix the patched versions of the icc- and the icpc-script to work with options containing spaces (e.g. '-DFOOBAR="foo bar"'). - Install 'clicense' and 'csupport' in the docs-dir even if NOPORTDOCS is defined, the later is not optional but required by 'icid'. - Move the ld-wrapper to a sub-dir and thus out of what is normally set in PATH to prevent footshooting (this isn't perfect but simple until someone reworks this port to provide FreeBSD-compatibility in another way... or Intel releases a native version). - Patch the headers to better fit for FreeBSD (hopefully...). Notes: - Icc7 is more picky about unknow options than the previous versions, i.e. the gcc-options normally supplied in CFLAGS unless altered in /etc/make.conf. Therefore compilation of ports with icc likely fail if the standard CFLAGS are not unset (e.g. `make CC=icc CFLAGS=""`) or replaced by options valid for icc. - When compiling multi-threaded C-code make sure to link with icc and option '-mt' (for ports e.g. via PTHREAD_CFLAGS) otherwise libc_r won't be linked in correctly. Submitted by: marius@alchemy.franken.de Additional information: - rev 1.20 of src/sys/i386/include/signal.h introduced __aligned which isn't handled in sys/cdefs.h for non GCC compilers (at least not in publically available sources) - the FreeBSD stdarg.h is missing a macro for va_copy() in the non GCC case, we handle it in the port, but be prepared to get problems when the base system gets fixed - we don't use the icc-buildin of alignof() - Intel provides a float.h which has different floatingpoint values (e.g. MAX_FLOAT) than we have in the base system, in the port we use the FreeBSD header (Warner knows about the issue... at least he got a mail from me and Marius) - we replace __wchar_t with __ct_rune_t because icc has a build-in type for it, this affects "typedef __ct_rune_t __wchar_t;" in sys/_types.h. It isn't known if this may be evil... - icc doesn't need the option "-mt" anymore to generate thread safe code, but our FreeBSD version still needs it to be able to choose libc_r instead of libc If a src-committer wants to address any of the above mentioned issues he should first contact me, I may have already some fixes in my local tree.
2003-01-11 18:21:41 +01:00
.for i in \
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
intel-icc8-8.0-44.i386.rpm \
# intel-iidb7-7.3.1-85.i386.rpm
@cd ${WRKSRC} && rpm2cpio.pl 2>/dev/null ${i} | ${CPIO} -idu --quiet
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
.endfor
pre-patch:
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
# Apply patches from Intel.
.if ${PORTVERSION} != ${PATCHLEVEL}
@${BRANDELF} -t Linux ${WRKSRC}_${PATCHLEVEL}/papply
@${WRKSRC}_${PATCHLEVEL}/papply ${WRKSRC}_${PATCHLEVEL}/icc.rtp \
${WRKSRC}/opt/${COMPILERDIR}
.endif
# Remove files we do not neet on FreeBSD.
@for i in `${CAT} ${FILESDIR}/exclude`; do \
${RM} -rf ${WRKSRC}/opt/${COMPILERDIR}/$$i; \
done
.if defined(NOPORTDOCS)
# Remove docs.
@for i in `${CAT} ${FILESDIR}/exclude_noportdocs`; do \
${RM} -rf ${WRKSRC}/opt/${COMPILERDIR}/$$i; \
done
.endif
# Allow everyone to use it.
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
@${CHMOD} a+rx ${WRKSRC}/opt
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
# Remove unneeded/unsafe access rights.
.for i in doc include lib
@${FIND} ${WRKSRC}/opt/${COMPILERDIR}/${i} -type f -print0 | \
Use the FIND and XARGS macros introduced in bsd.port.mk 1.391.
2003-11-13 14:30:42 +01:00
${XARGS} -0 ${CHMOD} a-x,g-w
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
.endfor
Use the FIND and XARGS macros introduced in bsd.port.mk 1.391.
2003-11-13 14:30:42 +01:00
@${FIND} ${WRKSRC}/opt -type d -print0 | ${XARGS} -0 ${CHMOD} go-w
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${CHMOD} a-x ${WRKSRC}/opt/${COMPILERDIR}/bin/Errormatch.txt
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
post-patch:
1) Document some steps in the targets of the Makefile. 2) icc is now able to link native binaries, at least a simple test case (a little bit more than a "Hello World!") runs fine. Our native ld is used here, so don't expect "-ipo" to work. Major parts of 2) are Submitted by: Dan Nelson <dnelson@allantgroup.com>
2002-05-14 15:15:20 +02:00
# Correct some paths and patch some files
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
.for i in icc iccvars.csh iccvars.sh icpc
@${REINPLACE_CMD} -i "" -e 's:%%ICC_LOCALBASE%%:${LOCALBASE}:g; \
s:\<INSTALLDIR\>:${PREFIX}/${COMPILERDIR}:g; \
s:man -w:manpath -q:g' ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
@${CHMOD} 755 ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
- add category: devel - use reinplace command where appropriate - gzip man page - clarify download instructions (1) - fix typo in a comment (2) - preparation for successfull C++ compiles (2, minor changes by me) Even if I bumped the port revision for the C++ parts, there's no need to update yet, wait until I commit the icc-stlport. Requested by: mi (1) Submitted by: Marius Strobl <marius@alchemy.franken.de> (2)
2002-08-20 12:01:58 +02:00
.endfor
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
.if ${PORTVERSION} != ${PATCHLEVEL}
@${REINPLACE_CMD} -i "" -e \
's:\<installpackageid\>:${DISTNAME}_${PATCHLEVEL}:g' \
${WRKSRC}/opt/${COMPILERDIR}/doc/csupport
.else
@${REINPLACE_CMD} -i "" -e 's:\<installpackageid\>:${DISTNAME}:g' \
${WRKSRC}/opt/${COMPILERDIR}/doc/csupport
.endif
@${RM} ${WRKSRC}/opt/${COMPILERDIR}/include/*.orig
@${RM} ${WRKSRC}/opt/${COMPILERDIR}/include/c++/*.orig
- Keep up with changes on -current (__sF, elf_i386 -> elf_i386_fbsd). - Use an exclude file for cpio, there's not much sense in extracting and chmod'ing a whole bunch of files only to delete them afterwards. - Fix two bugs in the ld-wrapper that could cause it to dump core in rare cases. - Remove a forgotten C++ include. - Improve IGNORE message. Submitted by: marius@alchemy.franken.de
2002-11-08 16:59:38 +01:00
.for i in icc.orig icpc.orig
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${RM} ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
- add category: devel - use reinplace command where appropriate - gzip man page - clarify download instructions (1) - fix typo in a comment (2) - preparation for successfull C++ compiles (2, minor changes by me) Even if I bumped the port revision for the C++ parts, there's no need to update yet, wait until I commit the icc-stlport. Requested by: mi (1) Submitted by: Marius Strobl <marius@alchemy.franken.de> (2)
2002-08-20 12:01:58 +02:00
.endfor
1) Document some steps in the targets of the Makefile. 2) icc is now able to link native binaries, at least a simple test case (a little bit more than a "Hello World!") runs fine. Our native ld is used here, so don't expect "-ipo" to work. Major parts of 2) are Submitted by: Dan Nelson <dnelson@allantgroup.com>
2002-05-14 15:15:20 +02:00
# Provide a more FreeBSD'ish compile environment
1) The new icc doesn't respect icc.cfg, solve this issue. 2) An actual rpm2cpio talks a little bit more, redirect sdterr to /dev/null. Noticed by: marius@alchemy.franken.de (1)
2002-08-04 22:40:14 +02:00
.for i in icc.cfg icpc.cfg
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${ECHO} -e "-no-gcc\n-Qlocation,ld,${PREFIX}/${COMPILERDIR}/bin/ldwrapper\n\n-wr1125\n-we140\n\n-Ulinux\n-U__linux__\n-U__linux\n-U__gnu_linux__\n\n-D__FreeBSD__=${ICCCFGVAL}\n\n" >>${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
Update icc to 7.0.078. Note: Object files built with version 6.0 of Intel(R) Compilers may not link properly with objects built with version 7.0 of Intel(R) Compilers. Rebuilding of the object files is suggested. Changes between the submitted version and the committed version: - update to 078 instead of 075 - treat excessive parameters in function calls as an error instead of a warning (removed compatibility with a not named MS product, as suggested by Intel) - allow to override the INTEL_FLEXLM_LICENSE variable From the submitter: - Unbreak usage of signal.h on -current and RELENG_5_0. (committers note: see below) - Fix ownership of installed files when built as non-root. - Fix the patched versions of the icc- and the icpc-script to work with options containing spaces (e.g. '-DFOOBAR="foo bar"'). - Install 'clicense' and 'csupport' in the docs-dir even if NOPORTDOCS is defined, the later is not optional but required by 'icid'. - Move the ld-wrapper to a sub-dir and thus out of what is normally set in PATH to prevent footshooting (this isn't perfect but simple until someone reworks this port to provide FreeBSD-compatibility in another way... or Intel releases a native version). - Patch the headers to better fit for FreeBSD (hopefully...). Notes: - Icc7 is more picky about unknow options than the previous versions, i.e. the gcc-options normally supplied in CFLAGS unless altered in /etc/make.conf. Therefore compilation of ports with icc likely fail if the standard CFLAGS are not unset (e.g. `make CC=icc CFLAGS=""`) or replaced by options valid for icc. - When compiling multi-threaded C-code make sure to link with icc and option '-mt' (for ports e.g. via PTHREAD_CFLAGS) otherwise libc_r won't be linked in correctly. Submitted by: marius@alchemy.franken.de Additional information: - rev 1.20 of src/sys/i386/include/signal.h introduced __aligned which isn't handled in sys/cdefs.h for non GCC compilers (at least not in publically available sources) - the FreeBSD stdarg.h is missing a macro for va_copy() in the non GCC case, we handle it in the port, but be prepared to get problems when the base system gets fixed - we don't use the icc-buildin of alignof() - Intel provides a float.h which has different floatingpoint values (e.g. MAX_FLOAT) than we have in the base system, in the port we use the FreeBSD header (Warner knows about the issue... at least he got a mail from me and Marius) - we replace __wchar_t with __ct_rune_t because icc has a build-in type for it, this affects "typedef __ct_rune_t __wchar_t;" in sys/_types.h. It isn't known if this may be evil... - icc doesn't need the option "-mt" anymore to generate thread safe code, but our FreeBSD version still needs it to be able to choose libc_r instead of libc If a src-committer wants to address any of the above mentioned issues he should first contact me, I may have already some fixes in my local tree.
2003-01-11 18:21:41 +01:00
.if ${OSVERSION} >= 500039
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${ECHO} -e "-D__wchar_t=__ct_rune_t\n" >>${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
Update icc to 7.0.078. Note: Object files built with version 6.0 of Intel(R) Compilers may not link properly with objects built with version 7.0 of Intel(R) Compilers. Rebuilding of the object files is suggested. Changes between the submitted version and the committed version: - update to 078 instead of 075 - treat excessive parameters in function calls as an error instead of a warning (removed compatibility with a not named MS product, as suggested by Intel) - allow to override the INTEL_FLEXLM_LICENSE variable From the submitter: - Unbreak usage of signal.h on -current and RELENG_5_0. (committers note: see below) - Fix ownership of installed files when built as non-root. - Fix the patched versions of the icc- and the icpc-script to work with options containing spaces (e.g. '-DFOOBAR="foo bar"'). - Install 'clicense' and 'csupport' in the docs-dir even if NOPORTDOCS is defined, the later is not optional but required by 'icid'. - Move the ld-wrapper to a sub-dir and thus out of what is normally set in PATH to prevent footshooting (this isn't perfect but simple until someone reworks this port to provide FreeBSD-compatibility in another way... or Intel releases a native version). - Patch the headers to better fit for FreeBSD (hopefully...). Notes: - Icc7 is more picky about unknow options than the previous versions, i.e. the gcc-options normally supplied in CFLAGS unless altered in /etc/make.conf. Therefore compilation of ports with icc likely fail if the standard CFLAGS are not unset (e.g. `make CC=icc CFLAGS=""`) or replaced by options valid for icc. - When compiling multi-threaded C-code make sure to link with icc and option '-mt' (for ports e.g. via PTHREAD_CFLAGS) otherwise libc_r won't be linked in correctly. Submitted by: marius@alchemy.franken.de Additional information: - rev 1.20 of src/sys/i386/include/signal.h introduced __aligned which isn't handled in sys/cdefs.h for non GCC compilers (at least not in publically available sources) - the FreeBSD stdarg.h is missing a macro for va_copy() in the non GCC case, we handle it in the port, but be prepared to get problems when the base system gets fixed - we don't use the icc-buildin of alignof() - Intel provides a float.h which has different floatingpoint values (e.g. MAX_FLOAT) than we have in the base system, in the port we use the FreeBSD header (Warner knows about the issue... at least he got a mail from me and Marius) - we replace __wchar_t with __ct_rune_t because icc has a build-in type for it, this affects "typedef __ct_rune_t __wchar_t;" in sys/_types.h. It isn't known if this may be evil... - icc doesn't need the option "-mt" anymore to generate thread safe code, but our FreeBSD version still needs it to be able to choose libc_r instead of libc If a src-committer wants to address any of the above mentioned issues he should first contact me, I may have already some fixes in my local tree.
2003-01-11 18:21:41 +01:00
.endif
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${CHMOD} a-x,g-w ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
1) The new icc doesn't respect icc.cfg, solve this issue. 2) An actual rpm2cpio talks a little bit more, redirect sdterr to /dev/null. Noticed by: marius@alchemy.franken.de (1)
2002-08-04 22:40:14 +02:00
.endfor
- C++ support: fix to work also on -current, work around broken exception handling when generating shared objects with binutils/ld 2.12.[0,1], link in the icc C++ ABI definitions not those of gcc - remove libcprts (STL): it has unresolvable glibc dependencies in both, dynamic and static, versions, therefore is not usable and entirely unneeded when libstlport is used instead - add libimf (Intel's optimized math functions library), while there's no measurable speed improvement (at least for the functions tested) in comparison to FreeBSD's libm beyond the "normal" icc vs. gcc boost icc occasionally produces code depending on libimf when told to optimize for Pentium 4 - replace the ld-script with a wrapper written in C as (c)sh is a bit limited and long winded for that purpose - minor stuff and cleanup Submitted by: marius@alchemy.franken.de
2002-09-17 14:10:46 +02:00
# C++ hack for icpc
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${ECHO} -e "\n-I${PREFIX}/include/stlport\n-Qoption,ld,-CPLUSPLUS\n" \
>>${WRKSRC}/opt/${COMPILERDIR}/bin/icpc.cfg
@cd ${WRKSRC}/opt/${COMPILERDIR}/bin/ && ${LN} -s icc.cfg iccbin.cfg \
&& ${LN} -s icpc.cfg icpcbin.cfg
# Hack while there's no support for icc in the stdarg.h and sys/cdefs.h.
@${CP} ${FILESDIR}/stdarg.h ${WRKSRC}/opt/${COMPILERDIR}/include
@${MKDIR} ${WRKSRC}/opt/${COMPILERDIR}/include/sys
@${CP} ${FILESDIR}/cdefs.h ${WRKSRC}/opt/${COMPILERDIR}/include/sys
- C++ support: fix to work also on -current, work around broken exception handling when generating shared objects with binutils/ld 2.12.[0,1], link in the icc C++ ABI definitions not those of gcc - remove libcprts (STL): it has unresolvable glibc dependencies in both, dynamic and static, versions, therefore is not usable and entirely unneeded when libstlport is used instead - add libimf (Intel's optimized math functions library), while there's no measurable speed improvement (at least for the functions tested) in comparison to FreeBSD's libm beyond the "normal" icc vs. gcc boost icc occasionally produces code depending on libimf when told to optimize for Pentium 4 - replace the ld-script with a wrapper written in C as (c)sh is a bit limited and long winded for that purpose - minor stuff and cleanup Submitted by: marius@alchemy.franken.de
2002-09-17 14:10:46 +02:00
- Fix icc and icpc scripts (variable overriding) [1] - Don't extract ia64 RPMs [2] - Fix bug on some 4.7 systems [3] Noticed by: mi [1] Suggested by: mi [2] Tested by: Clint Olsen <clint@0lsen.net>
2003-10-22 15:21:30 +02:00
.if ( ${OSVERSION} >= 470101 && ${OSVERSION} < 500000 ) || \
( ${OSVERSION} >= 500042 )
OBJCOPY_OPS= --redefine-sym stdin=__stdinp \
--redefine-sym stdout=__stdoutp \
--redefine-sym stderr=__stderrp
.endif
- C++ support: fix to work also on -current, work around broken exception handling when generating shared objects with binutils/ld 2.12.[0,1], link in the icc C++ ABI definitions not those of gcc - remove libcprts (STL): it has unresolvable glibc dependencies in both, dynamic and static, versions, therefore is not usable and entirely unneeded when libstlport is used instead - add libimf (Intel's optimized math functions library), while there's no measurable speed improvement (at least for the functions tested) in comparison to FreeBSD's libm beyond the "normal" icc vs. gcc boost icc occasionally produces code depending on libimf when told to optimize for Pentium 4 - replace the ld-script with a wrapper written in C as (c)sh is a bit limited and long winded for that purpose - minor stuff and cleanup Submitted by: marius@alchemy.franken.de
2002-09-17 14:10:46 +02:00
do-build:
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
# Use the Linux ABI for the binaries
.for i in codecov iccbin iccfilt icpcbin icpi mcpcom profmerge proforder tselect xiar xild
@${BRANDELF} -t Linux ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
.endfor
- link libc_pic.a when compiling with "-KPIC -static" - link libc_p.a/lib_c_r.a when compiling with "-pg -static" - fix unresolved symbols to make "-pg" and "-prof_gen" work Submitted by: marius@alchemy.franken.de Approved by: kris
2002-09-22 15:05:51 +02:00
# Fix unresolved references
@cd ${WRKSRC} && ${CC} ${CFLAGS} -c ${FILESDIR}/assert_fail.c \
- Keep up with changes on -current (__sF, elf_i386 -> elf_i386_fbsd). - Use an exclude file for cpio, there's not much sense in extracting and chmod'ing a whole bunch of files only to delete them afterwards. - Fix two bugs in the ld-wrapper that could cause it to dump core in rare cases. - Remove a forgotten C++ include. - Improve IGNORE message. Submitted by: marius@alchemy.franken.de
2002-11-08 16:59:38 +01:00
${FILESDIR}/errno_location.c ${FILESDIR}/mcount.S
- use the libc cxa support on a recent -current instead of the hack 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]
2003-12-22 16:03:23 +01:00
.if ( ${OSVERSION} < 502101 )
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@cd ${WRKSRC} && ${CC} ${CFLAGS} -c ${FILESDIR}/cxa_atexit.c
- use the libc cxa support on a recent -current instead of the hack 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]
2003-12-22 16:03:23 +01:00
.endif
- fix typo in message - catch up with __sF change in -stable Tested by: marius@alchemy.franken.de
2002-11-13 15:39:52 +01:00
.if ( ${OSVERSION} < 470101 ) || \
( ${OSVERSION} >= 500000 && ${OSVERSION} < 500042 )
Update icc to 7.0.078. Note: Object files built with version 6.0 of Intel(R) Compilers may not link properly with objects built with version 7.0 of Intel(R) Compilers. Rebuilding of the object files is suggested. Changes between the submitted version and the committed version: - update to 078 instead of 075 - treat excessive parameters in function calls as an error instead of a warning (removed compatibility with a not named MS product, as suggested by Intel) - allow to override the INTEL_FLEXLM_LICENSE variable From the submitter: - Unbreak usage of signal.h on -current and RELENG_5_0. (committers note: see below) - Fix ownership of installed files when built as non-root. - Fix the patched versions of the icc- and the icpc-script to work with options containing spaces (e.g. '-DFOOBAR="foo bar"'). - Install 'clicense' and 'csupport' in the docs-dir even if NOPORTDOCS is defined, the later is not optional but required by 'icid'. - Move the ld-wrapper to a sub-dir and thus out of what is normally set in PATH to prevent footshooting (this isn't perfect but simple until someone reworks this port to provide FreeBSD-compatibility in another way... or Intel releases a native version). - Patch the headers to better fit for FreeBSD (hopefully...). Notes: - Icc7 is more picky about unknow options than the previous versions, i.e. the gcc-options normally supplied in CFLAGS unless altered in /etc/make.conf. Therefore compilation of ports with icc likely fail if the standard CFLAGS are not unset (e.g. `make CC=icc CFLAGS=""`) or replaced by options valid for icc. - When compiling multi-threaded C-code make sure to link with icc and option '-mt' (for ports e.g. via PTHREAD_CFLAGS) otherwise libc_r won't be linked in correctly. Submitted by: marius@alchemy.franken.de Additional information: - rev 1.20 of src/sys/i386/include/signal.h introduced __aligned which isn't handled in sys/cdefs.h for non GCC compilers (at least not in publically available sources) - the FreeBSD stdarg.h is missing a macro for va_copy() in the non GCC case, we handle it in the port, but be prepared to get problems when the base system gets fixed - we don't use the icc-buildin of alignof() - Intel provides a float.h which has different floatingpoint values (e.g. MAX_FLOAT) than we have in the base system, in the port we use the FreeBSD header (Warner knows about the issue... at least he got a mail from me and Marius) - we replace __wchar_t with __ct_rune_t because icc has a build-in type for it, this affects "typedef __ct_rune_t __wchar_t;" in sys/_types.h. It isn't known if this may be evil... - icc doesn't need the option "-mt" anymore to generate thread safe code, but our FreeBSD version still needs it to be able to choose libc_r instead of libc If a src-committer wants to address any of the above mentioned issues he should first contact me, I may have already some fixes in my local tree.
2003-01-11 18:21:41 +01:00
@${CC} ${CFLAGS} -c -o ${WRKSRC}/stdin.o ${FILESDIR}/stdin.c
@${CC} ${CFLAGS} -c -o ${WRKSRC}/stdout.o ${FILESDIR}/stdout.c
- Keep up with changes on -current (__sF, elf_i386 -> elf_i386_fbsd). - Use an exclude file for cpio, there's not much sense in extracting and chmod'ing a whole bunch of files only to delete them afterwards. - Fix two bugs in the ld-wrapper that could cause it to dump core in rare cases. - Remove a forgotten C++ include. - Improve IGNORE message. Submitted by: marius@alchemy.franken.de
2002-11-08 16:59:38 +01:00
@${CC} ${CFLAGS} -c -o ${WRKSRC}/stderr.o ${FILESDIR}/stderr.c
- Fix icc and icpc scripts (variable overriding) [1] - Don't extract ia64 RPMs [2] - Fix bug on some 4.7 systems [3] Noticed by: mi [1] Suggested by: mi [2] Tested by: Clint Olsen <clint@0lsen.net>
2003-10-22 15:21:30 +02:00
.endif
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
.for i in libcxa.a libcxaguard.a libimf.a libirc.a libircmt.a libunwind.a
Fix __sigsetjmp linking problem.
2003-08-22 13:20:38 +02:00
@${OBJCOPY} --redefine-sym __sigsetjmp=sigsetjmp \
- Fix icc and icpc scripts (variable overriding) [1] - Don't extract ia64 RPMs [2] - Fix bug on some 4.7 systems [3] Noticed by: mi [1] Suggested by: mi [2] Tested by: Clint Olsen <clint@0lsen.net>
2003-10-22 15:21:30 +02:00
${OBJCOPY_OPS} \
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
${WRKSRC}/opt/${COMPILERDIR}/lib/${i}
- Keep up with changes on -current (__sF, elf_i386 -> elf_i386_fbsd). - Use an exclude file for cpio, there's not much sense in extracting and chmod'ing a whole bunch of files only to delete them afterwards. - Fix two bugs in the ld-wrapper that could cause it to dump core in rare cases. - Remove a forgotten C++ include. - Improve IGNORE message. Submitted by: marius@alchemy.franken.de
2002-11-08 16:59:38 +01:00
.endfor
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${AR} q ${WRKSRC}/opt/${COMPILERDIR}/lib/libcxa.a ${WRKSRC}/*.o
@${AR} q ${WRKSRC}/opt/${COMPILERDIR}/lib/libcxaguard.a ${WRKSRC}/*.o
1) Document some steps in the targets of the Makefile. 2) icc is now able to link native binaries, at least a simple test case (a little bit more than a "Hello World!") runs fine. Our native ld is used here, so don't expect "-ipo" to work. Major parts of 2) are Submitted by: Dan Nelson <dnelson@allantgroup.com>
2002-05-14 15:15:20 +02:00
# Some magic to be able to link
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${MKDIR} ${WRKSRC}/opt/${COMPILERDIR}/bin/ldwrapper
Update icc to 7.0.078. Note: Object files built with version 6.0 of Intel(R) Compilers may not link properly with objects built with version 7.0 of Intel(R) Compilers. Rebuilding of the object files is suggested. Changes between the submitted version and the committed version: - update to 078 instead of 075 - treat excessive parameters in function calls as an error instead of a warning (removed compatibility with a not named MS product, as suggested by Intel) - allow to override the INTEL_FLEXLM_LICENSE variable From the submitter: - Unbreak usage of signal.h on -current and RELENG_5_0. (committers note: see below) - Fix ownership of installed files when built as non-root. - Fix the patched versions of the icc- and the icpc-script to work with options containing spaces (e.g. '-DFOOBAR="foo bar"'). - Install 'clicense' and 'csupport' in the docs-dir even if NOPORTDOCS is defined, the later is not optional but required by 'icid'. - Move the ld-wrapper to a sub-dir and thus out of what is normally set in PATH to prevent footshooting (this isn't perfect but simple until someone reworks this port to provide FreeBSD-compatibility in another way... or Intel releases a native version). - Patch the headers to better fit for FreeBSD (hopefully...). Notes: - Icc7 is more picky about unknow options than the previous versions, i.e. the gcc-options normally supplied in CFLAGS unless altered in /etc/make.conf. Therefore compilation of ports with icc likely fail if the standard CFLAGS are not unset (e.g. `make CC=icc CFLAGS=""`) or replaced by options valid for icc. - When compiling multi-threaded C-code make sure to link with icc and option '-mt' (for ports e.g. via PTHREAD_CFLAGS) otherwise libc_r won't be linked in correctly. Submitted by: marius@alchemy.franken.de Additional information: - rev 1.20 of src/sys/i386/include/signal.h introduced __aligned which isn't handled in sys/cdefs.h for non GCC compilers (at least not in publically available sources) - the FreeBSD stdarg.h is missing a macro for va_copy() in the non GCC case, we handle it in the port, but be prepared to get problems when the base system gets fixed - we don't use the icc-buildin of alignof() - Intel provides a float.h which has different floatingpoint values (e.g. MAX_FLOAT) than we have in the base system, in the port we use the FreeBSD header (Warner knows about the issue... at least he got a mail from me and Marius) - we replace __wchar_t with __ct_rune_t because icc has a build-in type for it, this affects "typedef __ct_rune_t __wchar_t;" in sys/_types.h. It isn't known if this may be evil... - icc doesn't need the option "-mt" anymore to generate thread safe code, but our FreeBSD version still needs it to be able to choose libc_r instead of libc If a src-committer wants to address any of the above mentioned issues he should first contact me, I may have already some fixes in my local tree.
2003-01-11 18:21:41 +01:00
@${CC} ${CFLAGS} -o \
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
${WRKSRC}/opt/${COMPILERDIR}/bin/ldwrapper/ld \
Update icc to 7.0.078. Note: Object files built with version 6.0 of Intel(R) Compilers may not link properly with objects built with version 7.0 of Intel(R) Compilers. Rebuilding of the object files is suggested. Changes between the submitted version and the committed version: - update to 078 instead of 075 - treat excessive parameters in function calls as an error instead of a warning (removed compatibility with a not named MS product, as suggested by Intel) - allow to override the INTEL_FLEXLM_LICENSE variable From the submitter: - Unbreak usage of signal.h on -current and RELENG_5_0. (committers note: see below) - Fix ownership of installed files when built as non-root. - Fix the patched versions of the icc- and the icpc-script to work with options containing spaces (e.g. '-DFOOBAR="foo bar"'). - Install 'clicense' and 'csupport' in the docs-dir even if NOPORTDOCS is defined, the later is not optional but required by 'icid'. - Move the ld-wrapper to a sub-dir and thus out of what is normally set in PATH to prevent footshooting (this isn't perfect but simple until someone reworks this port to provide FreeBSD-compatibility in another way... or Intel releases a native version). - Patch the headers to better fit for FreeBSD (hopefully...). Notes: - Icc7 is more picky about unknow options than the previous versions, i.e. the gcc-options normally supplied in CFLAGS unless altered in /etc/make.conf. Therefore compilation of ports with icc likely fail if the standard CFLAGS are not unset (e.g. `make CC=icc CFLAGS=""`) or replaced by options valid for icc. - When compiling multi-threaded C-code make sure to link with icc and option '-mt' (for ports e.g. via PTHREAD_CFLAGS) otherwise libc_r won't be linked in correctly. Submitted by: marius@alchemy.franken.de Additional information: - rev 1.20 of src/sys/i386/include/signal.h introduced __aligned which isn't handled in sys/cdefs.h for non GCC compilers (at least not in publically available sources) - the FreeBSD stdarg.h is missing a macro for va_copy() in the non GCC case, we handle it in the port, but be prepared to get problems when the base system gets fixed - we don't use the icc-buildin of alignof() - Intel provides a float.h which has different floatingpoint values (e.g. MAX_FLOAT) than we have in the base system, in the port we use the FreeBSD header (Warner knows about the issue... at least he got a mail from me and Marius) - we replace __wchar_t with __ct_rune_t because icc has a build-in type for it, this affects "typedef __ct_rune_t __wchar_t;" in sys/_types.h. It isn't known if this may be evil... - icc doesn't need the option "-mt" anymore to generate thread safe code, but our FreeBSD version still needs it to be able to choose libc_r instead of libc If a src-committer wants to address any of the above mentioned issues he should first contact me, I may have already some fixes in my local tree.
2003-01-11 18:21:41 +01:00
${FILESDIR}/ld.c
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${STRIP_CMD} ${WRKSRC}/opt/${COMPILERDIR}/bin/ldwrapper/ld
@${CHMOD} 755 ${WRKSRC}/opt/${COMPILERDIR}/bin/ldwrapper/ld
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
do-install:
- Update to 7.1.006. Submitted by: marius@alchemy.franken.de - Minor cosmetics (FIND) and corrections (COMMENT).
2003-03-28 11:45:57 +01:00
@cd ${WRKSRC}/opt && ${FIND} . -print | \
${CPIO} -pdu -R ${BINOWN}:${BINGRP} --quiet ${PREFIX}
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
post-install:
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${ECHO_CMD} "${PKGNAME} is now installed in ${PREFIX}/${COMPILERDIR}, to use it you have to"
Update icc from 5.0.1 to 6.0.139.
2002-05-13 15:58:21 +02:00
@${ECHO_CMD} "put your license into your \$${INTEL_FLEXLM_LICENSE} (default:"
Update to 8.0.055.p057. 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).
2004-01-11 16:32:07 +01:00
@${ECHO_CMD} "${PREFIX}/${COMPILERDIR}/licenses) directory and add"
@${ECHO_CMD} "${PREFIX}/${COMPILERDIR}/bin to your PATH."
Document the bad interaction with the linux-devtools port. Noticed by: "Simon 'corecode' Schubert" <corecode@corecode.ath.cx>
2002-07-14 18:31:40 +02:00
@${ECHO_CMD}
- Update to 6.0.1.304. - Re-enable patching of iccvars.(c)sh (solely called by icid and therefore overlooked), accidentally broken by last commit. - Fix generation of multi-threaded code, triggered by the (badly documented) compiler option "-mt". - Disable compiler options "-openmp*" and "-parallel", they depend on libguide which itself depends on pthread_atfork() (not provided by libc_r), therefore don't install libguide. Note: All compiler options are now believed to either work on FreeBSD or be disabled (Maintainer note: '-prof_gen' is under investigation). - Add a message about installing stlport-icc in order to get full C++ support. - Remove workaround for generation of shared objects with binutils/ld 2.12.x, appears to be fixed (unfortunately no confirmation by Intel Support, "That is good news <...> then we should just close this issue." *sigh*). Submitted by: marius@alchemy.franken.de - Add note about a problem on P4 and how to solve it. Suggested by: Martin Kahlert <martin.kahlert@infineon.com> - Remove outdated information in pkg-descr.
2002-09-20 14:16:25 +02:00
@${ECHO_CMD} "In order to be able to compile C++ source with icpc you have to install"
- use the libc cxa support on a recent -current instead of the hack 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]
2003-12-22 16:03:23 +01:00
@${ECHO_CMD} "devel/stlport-icc."
- Update to 6.0.1.304. - Re-enable patching of iccvars.(c)sh (solely called by icid and therefore overlooked), accidentally broken by last commit. - Fix generation of multi-threaded code, triggered by the (badly documented) compiler option "-mt". - Disable compiler options "-openmp*" and "-parallel", they depend on libguide which itself depends on pthread_atfork() (not provided by libc_r), therefore don't install libguide. Note: All compiler options are now believed to either work on FreeBSD or be disabled (Maintainer note: '-prof_gen' is under investigation). - Add a message about installing stlport-icc in order to get full C++ support. - Remove workaround for generation of shared objects with binutils/ld 2.12.x, appears to be fixed (unfortunately no confirmation by Intel Support, "That is good news <...> then we should just close this issue." *sigh*). Submitted by: marius@alchemy.franken.de - Add note about a problem on P4 and how to solve it. Suggested by: Martin Kahlert <martin.kahlert@infineon.com> - Remove outdated information in pkg-descr.
2002-09-20 14:16:25 +02:00
@${ECHO_CMD}
@${ECHO_CMD} "If you use icc on a Pentium 4 make sure you have 'options CPU_ENABLE_SSE'"
@${ECHO_CMD} "in your kernel config (have a look at http://www.FreeBSD.org/handbook/"
@${ECHO_CMD} "if you do not know how to do this), else icc will hang forever."
@${ECHO_CMD}
- mark BROKEN when linux_devtools or ifc is installed - make it more clear that you shouldn't install linux_devtools in the post install message
2002-11-08 21:17:54 +01:00
@${ECHO_CMD} "WARNING: If you use icc while having linux_devtools installed, icc will use"
@${ECHO_CMD} "the wrong includes and therefore will generate bogus (not working) binaries!"
- update to 7.0.082 - 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
2003-02-10 15:04:11 +01:00
@${ECHO_CMD}
@${ECHO_CMD} "If you encounter further problems with icc please consult the errata at"
@${ECHO_CMD} "http://support.intel.com/support/performancetools/c/C_Compiler_Errata.htm"
@${ECHO_CMD} "first."
- Update to 7.1.025. - Fix spelling of CONFLICTS [1]. - Add request for benchmark numbers [2]. Noticed by: Andreas Schweitzer <Andreas.Schweitzer@hs.uni-hamburg.de> [1] Discussed with: Intel [2]
2003-08-15 15:00:08 +02:00
@${ECHO_CMD}
@${ECHO_CMD} "Call for benchmarks:"
@${ECHO_CMD} "Intel is interested to see some benchmark numbers which compare gcc with icc."
@${ECHO_CMD} "If you have a CPU produced by Intel and are able to do benchmarks with"
@${ECHO_CMD} "either your own source or with one of our major ports (e.g. with"
@${ECHO_CMD} "a webserver, a mailserver, a database system, an important graphics"
@${ECHO_CMD} "suite/program or some important math tool, ...) please try to spend some time"
@${ECHO_CMD} "to do a benchmark and send me (${MAINTAINER}) the result. You should"
@${ECHO_CMD} "include your system specs (CPU: speed/model, RAM: amount/speed, used disks"
@${ECHO_CMD} "(if necessary), chipset/mainboard type, ...), the version of the used"
@${ECHO_CMD} "software (OS, gcc, icc, ...), non default tuning options (kernel, sysctl) and"
@${ECHO_CMD} "the used compiler switches. If you don't use some 'standard' benchmark"
@${ECHO_CMD} "(e.g. the official MySQL benchmark, or the performance test suite of your"
@${ECHO_CMD} "prefered scripting language), please include a description about the"
@${ECHO_CMD} "benchmark too."
@${ECHO_CMD}
Add a paragraph about Intels support in the post-install message.
2003-11-10 22:32:11 +01:00
@${ECHO_CMD} "Please use FreeBSD as the name of your OS in communications with the support,"
@${ECHO_CMD} "the larger the FreeBSD userbase is, the more work gets done on FreeBSD"
@${ECHO_CMD} "specific issues by Intel. And please thank them for the FreeBSD support,"
@${ECHO_CMD} "they are already spending some time to improve icc on FreeBSD."
@${ECHO_CMD}
- Update to 7.1.025. - Fix spelling of CONFLICTS [1]. - Add request for benchmark numbers [2]. Noticed by: Andreas Schweitzer <Andreas.Schweitzer@hs.uni-hamburg.de> [1] Discussed with: Intel [2]
2003-08-15 15:00:08 +02:00
@${ECHO_CMD} "To read the entire post install message again, just run"
@${ECHO_CMD} "'make post-install | less'."
This is Intels C/C++ compiler. It is setup to produce native FreeBSD objects. This port is not able to produce native executables on its own. You need to do it yourself with gcc. Approved by: steve
2002-03-26 18:01:09 +01:00
.include <bsd.port.post.mk>
Reference in a new issue Copy permalink