freebsd-ports/lang/icc/Makefile

243 lines
10 KiB
Makefile
Raw Normal View History

# New ports collection makefile for: icc
# Date created: 24.Jan.2002
# Whom: netchild@FreeBSD.org
#
# $FreeBSD$
#
PORTNAME= icc
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
PORTVERSION= 8.1.024
CATEGORIES= lang linux devel
MASTER_SITES=
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
DISTNAME= l_cc_pu_${PORTVERSION:C/p.+$//}
MAINTAINER= netchild@FreeBSD.org
COMMENT= Intels C/C++ compiler, set up to produce native FreeBSD binaries
PATCHLEVEL= ${PORTVERSION:C/(.+p)(.+)$/pe\2/}
DISTFILES= ${DISTNAME}${EXTRACT_SUFX}
.if ${PORTVERSION} != ${PATCHLEVEL}
DISTFILES+= ${DISTNAME}_${PATCHLEVEL}${EXTRACT_SUFX}
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
#PATCH_DEPENDS= ${LINUXBASE}/etc/redhat-release:${PORTSDIR}/emulators/linux_base
PATCH_DEPENDS= ${LINUXBASE}/lib/libc-2.3.2.so:${PORTSDIR}/emulators/linux_base-8
.endif
EXTRACT_DEPENDS= rpm2cpio.pl:${PORTSDIR}/archivers/rpm2cpio
RESTRICTED= Intel forbids any redistribution
NO_PACKAGE= ${RESTRICTED}
NO_CDROM= ${RESTRICTED}
ONLY_FOR_ARCHS= i386
CONFLICTS= linux_devtools*
#USE_LINUX= yes
RUN_DEPENDS= ${LINUXBASE}/lib/libc-2.3.2.so:${PORTSDIR}/emulators/linux_base-8
USE_REINPLACE= yes
NO_FILTER_SHLIBS= yes
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}
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
MLINKS= icc.1 icpc.1
MANPREFIX= ${PREFIX}/${COMPILERDIR}/
ICC_SITE= http://www.intel.com/software/products/compilers/
.include <bsd.port.pre.mk>
EXTRACT_AFTER_ARGS= | tar -xf - \
--exclude cdt-\*.zip \
--exclude eclipse-platform\*.zip \
--exclude intel-icc_ide\*.rpm \
--exclude intel-iidb\*.rpm \
--exclude intel-isubh\*.rpm \
--exclude sdp-core-\*.zip \
--exclude \*ia64.rpm \
--exclude flexlm64
ICCCFGVAL!= ${UNAME} -r | ${SED} -e 's/\..*//'
.if ( ${OSVERSION} < 502108 )
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
PLIST_SUB+= MACHINE__TYPES_H="@comment " STDARG_H="" SYS_CDEFS_H=""
.else
PLIST_SUB+= STDARG_H="@comment " SYS_CDEFS_H="@comment "
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
.if ${OSVERSION} < 502126
GCCCOMPATVER= 330
.endif
.if ${OSVERSION} >= 502126
GCCCOMPATVER= 340
.endif
GXXINCLUDE= /usr/include/c++/${GCCCOMPATVER:C/([0-9])([0-9]).+/\1.\2/}
PLIST_SUB+= MACHINE__TYPES_H=""
.endif
.for file in ${DISTFILES}
.if !exists(${DISTDIR}/${DIST_SUBDIR}/${file})
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"
.endif
.endfor
.if exists(${LINUXBASE}/boot/kernel.h)
BROKEN= Cannot coexist with linux_devtools
.endif
post-extract:
@cd ${WRKSRC} && rpm2cpio.pl 2>/dev/null *.rpm | ${CPIO} -idu --quiet
intel-patch: extract
# Apply patches from Intel.
.if ${PORTVERSION} != ${PATCHLEVEL}
@${BRANDELF} -t Linux ${WRKSRC}_${PATCHLEVEL}/papply
@${WRKSRC}_${PATCHLEVEL}/papply ${WRKSRC}_${PATCHLEVEL}/icc.rtp \
${WRKSRC}/opt/${COMPILERDIR}
.endif
pre-patch: intel-patch
# 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.
@${CHMOD} a+rx ${WRKSRC}/opt
# Remove unneeded/unsafe access rights.
.for i in doc include lib
@${FIND} ${WRKSRC}/opt/${COMPILERDIR}/${i} -type f -print0 | \
${XARGS} -0 ${CHMOD} a-x,og-w
.endfor
@${FIND} ${WRKSRC}/opt -type d -print0 | ${XARGS} -0 ${CHMOD} go-w
@${CHMOD} a-x ${WRKSRC}/opt/${COMPILERDIR}/bin/Errormatch.txt
post-patch:
# Correct some paths and patch some files
.for i in icc iccvars.csh iccvars.sh icpc
@${REINPLACE_CMD} -i "" -e 's:%%ICC_LOCALBASE%%:${LOCALBASE}:g; \
s:\<INSTALLDIR\>:${PREFIX}/${COMPILERDIR}:g; \
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
s:%%GXX_INCLUDE%%:${GXXINCLUDE}:g; \
s:man -w:manpath -q:g' ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
@${CHMOD} 755 ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
.endfor
.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
.for i in icc.orig icpc.orig
@${RM} ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
.endfor
# Provide a more FreeBSD'ish compile environment
.for i in icc.cfg icpc.cfg
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${ECHO_CMD} -e "-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}
.if ( ${OSVERSION} >= 500039 )
@${ECHO_CMD} -e "-D__wchar_t=__ct_rune_t\n" >>${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
.endif
.if ( ${OSVERSION} >= 502108 )
@${ECHO_CMD} -e "-restrict\n" >>${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
.else
@${ECHO_CMD} -e "-no-gcc\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
@${CHMOD} a-x,g-w ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
.endfor
# C++ hack for icpc
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
.if ( ${OSVERSION} >= 502108 )
@${ECHO_CMD} -e "-gcc-version=${GCCCOMPATVER}\n-cxxlib-gcc\n" \
>>${WRKSRC}/opt/${COMPILERDIR}/bin/icpc.cfg
.else
@${ECHO_CMD} -e "\n-I${PREFIX}/include/stlport\n-Qoption,ld,-CPLUSPLUS\n" \
>>${WRKSRC}/opt/${COMPILERDIR}/bin/icpc.cfg
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
.endif
@cd ${WRKSRC}/opt/${COMPILERDIR}/bin/ && ${LN} -s icc.cfg iccbin.cfg \
&& ${LN} -s icpc.cfg icpcbin.cfg
.if ( ${OSVERSION} < 502108 )
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
# 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
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
.else
# Work around bug for ICC support in src/sys/i386/include/_types.h.
@${MKDIR} ${WRKSRC}/opt/${COMPILERDIR}/include/machine
@${CP} ${FILESDIR}/_types.h ${WRKSRC}/opt/${COMPILERDIR}/include/machine
.endif
.if ( ${OSVERSION} >= 470101 && ${OSVERSION} < 500000 ) || \
( ${OSVERSION} >= 500042 )
OBJCOPY_OPS= --redefine-sym stdin=__stdinp \
--redefine-sym stdout=__stdoutp \
--redefine-sym stderr=__stderrp
.endif
do-build:
# Use the Linux ABI for the binaries
.for i in codecov iccbin iccfilt icpcbin icpi mcpcom prelink profmerge \
proforder profrun pronto_tool tselect xiar xild
@${BRANDELF} -t Linux ${WRKSRC}/opt/${COMPILERDIR}/bin/${i}
.endfor
# Fix unresolved references
@cd ${WRKSRC} && ${CC} ${CFLAGS} -c ${FILESDIR}/assert_fail.c \
${FILESDIR}/errno_location.c ${FILESDIR}/mcount.S
.if ( ${OSVERSION} < 502101 )
@cd ${WRKSRC} && ${CC} ${CFLAGS} -c ${FILESDIR}/cxa_atexit.c
.endif
.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
@${CC} ${CFLAGS} -c -o ${WRKSRC}/stderr.o ${FILESDIR}/stderr.c
.endif
.for i in libcxa.a libcxaguard.a libimf.a libirc.a libirc_s.a libsvml.a \
libunwind.a
2003-08-22 13:20:38 +02:00
@${OBJCOPY} --redefine-sym __sigsetjmp=sigsetjmp \
${OBJCOPY_OPS} \
${WRKSRC}/opt/${COMPILERDIR}/lib/${i}
.endfor
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${AR} cr ${WRKSRC}/opt/${COMPILERDIR}/lib/libiccfbsd.a ${WRKSRC}/*.o
# Some magic to be able to link
@${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 \
${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
@${STRIP_CMD} ${WRKSRC}/opt/${COMPILERDIR}/bin/ldwrapper/ld
@${CHMOD} 755 ${WRKSRC}/opt/${COMPILERDIR}/bin/ldwrapper/ld
# Make ICC happy with regards to crtbegin.o, crtend.o and libgcc.a which it
# expects to find in GXX_ROOT.
.for file in crtbegin.o crtend.o libgcc.a
@cd ${WRKSRC}/opt/${COMPILERDIR}/lib && ${LN} -s /usr/lib/${file} ${file}
.endfor
do-install:
@cd ${WRKSRC}/opt && ${FIND} . -print | \
${CPIO} -pdu -R ${BINOWN}:${BINGRP} --quiet ${PREFIX}
post-install:
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${ECHO} "${PKGNAME} is now installed in ${PREFIX}/${COMPILERDIR}, to use it you have to put your license into your \$${INTEL_FLEXLM_LICENSE} (default: ${PREFIX}/${COMPILERDIR}/licenses) directory and add ${PREFIX}/${COMPILERDIR}/bin to your PATH." | fmt
@${ECHO}
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${ECHO} "On FreeBSD 5 with __FreeBSD_version >= 502108 icpc is set up to use the GNU libstdc++ from the base as STL by default. Alternatively you can use the \"-cxxlib-icc\" option with icpc to use devel/stlport-icc as STL instead. In order to be able to compile C++ source with icpc on FreeBSD 4 or FreeBSD 5 with __FreeBSD_version < 502108 you have to install devel/stlport-icc. No further options to icpc to use devel/stlport-icc are required there." | fmt
@${ECHO}
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${ECHO} "If you use icc on a Pentium 4 you may have to use 'options CPU_ENABLE_SSE' (depending on the OS version, if in doubt try if it works) in your kernel config (have a look at http://www.FreeBSD.org/handbook/ if you do not know how to do this), else icc will hang forever." | fmt
@${ECHO}
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${ECHO} "WARNING: If you use icc while having linux_devtools installed, icc will use the wrong includes and therefore will generate bogus (not working) binaries!" | fmt
@${ECHO}
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${ECHO} "If you encounter further problems with icc please consult the errata at http://support.intel.com/support/performancetools/c/C_Compiler_Errata.htm first." | fmt
@${ECHO}
@${ECHO} "Call for benchmarks:"
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${ECHO} "Intel is interested to see some benchmark numbers which compare gcc with icc. If you have a CPU produced by Intel and are able to do benchmarks with either your own source or with one of our major ports (e.g. with a webserver, a mailserver, a database system, an important graphics suite/program or some important math tool, ...) please try to spend some time to do a benchmark and send me (${MAINTAINER}) the result. You should include your system specs (CPU: speed/model, RAM: amount/speed, used disks (if necessary), chipset/mainboard type, ...), the version of the used software (OS, gcc, icc, ...), non default tuning options (kernel, sysctl) and the used compiler switches. If you don't use some 'standard' benchmark (e.g. the official MySQL benchmark, or the performance test suite of your prefered scripting language), please include a description about the benchmark too." | fmt
@${ECHO}
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${ECHO} "Please use FreeBSD as the name of your OS in communications with the support, the larger the FreeBSD userbase is, the more work gets done on FreeBSD specific issues by Intel. And please thank them for the FreeBSD support, they are already spending some time to improve icc on FreeBSD." | fmt
@${ECHO}
- Update to 8.1.024. - Declare a PATCH_DEPENDS on emulators/linux_base-8 only if actually using RTPpatch to apply an Intel provided binary patch. - Turn the GCC-compatibility of ICC on by default for FreeBSD >= 502108; except for one bug which is worked around by this port and will be fixed in src later FreeBSD gained support for using the GCC-compatibility along with the patch to compile the kernel with ICC (but the ICC 8.0 series wasn't configurable/hackable enough to actually use it on FreeBSD, which resulted into the aforementioned bug). - On FreeBSD >= 502108 default to using libstdc++ from the base as STL instead of STLport unless "-cxxlib-icc" is passed to icpc (made possible by turning on the GCC-compatibility and the compatibility to GCC 3.3 and 3.4 which was added to ICC 8.1). On FreeBSD < 502108 STLport i.e. devel/stlport-icc is and will continue to be the only STL available. Update the instructions displayed by the post-install target accordingly. - Put the wrappers for glibc specific symbols and other GNU/Linux compat hacks into their own library "libiccfbsd" and teach the ld-wrapper to injected this lib instead of adding these things to the Intel libcxa and libcxaguard. Beginning with ICC 8.1 non of the Intel libs is "guaranteed" to be linked into resulting executable (this is actually a fix in ICC as libcxa and libcxaguard are C++ only). This fixes linking against libm with icc amongst other things [1]. - Clean the ld-wrapper up a bit. Stop trying to create a perfect world for the real ld(1) regarding superfluous linkage options, ICC natively passes far to many of them to the linker that we easily could remove them all. - Change the ld-wrapper to allow for bootstrapping STLport in a bit different way that we used to do it, required to make devel/stlport-icc build correctly again. - Use fmt(1) to print the infos displayed by the post-install target so the text is formated properly after the included variables are expanded [2]. Todo: - Rework the freaking thread library selection via the PTHREAD_LIBS environment variable by the ld-wrapper, this causes really annoying problems when compiling ports with ICC. Some functionality analogous to the GCC "-pthread" option (which is also known by ICC but is not documented and doesn't do the right thing for FreeBSD) would be great. - Make devel/stlport-icc build again with ICC 8.1 after devel/stlport has been updated to 4.6.2 (PR 73604). Patch for 4.5.3 already done. Reported by: Dan Nelson <dnelson@allantgroup.com> [1] Courtesy of: netchild [2] Approved by: netchild
2004-11-16 21:14:47 +01:00
@${ECHO} "To read the entire post install message again, just run 'make post-install | less'." | fmt
.include <bsd.port.post.mk>