freebsd-ports/lang/icc/Makefile

255 lines
11 KiB
Makefile
Raw Normal View History

# New ports collection makefile for: icc
# Date created: 24.Jan.2002
# Whom: netchild@FreeBSD.org
#
# $FreeBSD$
#
PORTNAME= icc
PORTVERSION= 8.1.038
CATEGORIES= lang linux devel
MASTER_SITES=
2004-12-12 18:12:26 +01:00
DISTNAME= l_cc_pc_${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}
Mega-patch to cleanup the ports infrastructure regarding our linux bits: - USE_LINUX now implies NO_FILTER_SHLIBS=yes. It also doesn't use FreeBSD tools to strip binaries anymore, so it's not neccesary anymore to override STRIP and STRIP_CMD. - USE_LINUX_PREFIX implies NO_MTREE now. - In the USE_LINUX case, USE_XLIB now depends upon the linux X11 libraries instead upon the native FreeBSD libraries. - The variable LINUX_BASE_PORT contains a string which is suitable as an item in *_DEPENDS, so if a port BATCH_DEPENDS or FETCH_DEPENDS upon the default (or overriden) linux base, ${LINUX_BASE_PORT} should be used instead of a hardcoded reference. - Change all ports to comply to the "new world order". - The Ports Collection now allows to override the default linux_base port. Specify e.g. OVERRIDE_LINUX_BASE_PORT=rh-9 in /etc/make.conf to use ${PORTSDIR}/emulators/linux_base-rh-9 (the logic is to use ${PORTSDIR}/emulators/linux_base-${OVERRIDE_LINUX_BASE_PORT}). - If USE_LINUX or OVERRIDE_LINUX_BASE doesn't point to an existing linux_base port and if USE_LINUX isn't set to "yes" (case insensitive), the port will be marked as IGNORE. [1] - Readd USE_LINUX knobs into several ports and make several uses of a conditional dependency ("USE_LINUX?=") into an unconditional one ("USE_LINUX=") which where removed/changed by Trevor to allow the use of alternative linux_base ports. While this is a nice goal, the implementation resulted in missing dependencies. The OVERRIDE_LINUX_BASE_PORT knob in this commit is supposed to fix the problem while keeping the feature. Basicaly this includes a backout of Trevor's commit, to prevent confusion I mention it here explicitely. - Use the correct prefix (X11- instead of LOCAL- or LINUX-) for some ports. Chase dependencies for this. - Changes to make linux_devtools installable on amd64, remove some stray device nodes (they don't work on recent OS versions and aren't really needed). - Make linux_base-8 PREFIX clean and remove some stray device nodes. Additionally tell a little bit more about how to setup NIS/YP [2]. - Update the PGSQL dependency in the linux-opengroupware port to a recent version (the old one isn't available anymore), I don't know if this works (at least it isn't more broken than before). - Use PREFIX/usr/share/doc instead of PREFIX/usr/doc in the divx4linux ports, the former path exists already and gets populated by other packages too (PREFIX=LINUXPREFIX!). - Fix some obvious (non-linuxolator) bugs in some linux ports while being there. - Bump PORTREVISION where neccesary. Requested by: portmgr (linimon) [1] Submittted by: Gerrit Kuehn <gerrit_huehn@gruft.fido.de [2] Approved by: portmgr (kris, linimon), maintainers (or maintainer timeout) Tested on: ports cluster (kris) Reviewed by: silence on emulation@ Superseedes PR: 69997 Maintainer approval from: chris@chrisburkert.de cracauer@cons.org des girgen jamie@bishopston.net mezz mi nivit@users.sf.net pat simond@irrelevant.org riggs@rrr.de Udo.Schweigert@Siemens.com
2005-06-18 00:59:29 +02:00
PATCH_DEPENDS= ${LINUX_BASE_PORT}
.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*
Mega-patch to cleanup the ports infrastructure regarding our linux bits: - USE_LINUX now implies NO_FILTER_SHLIBS=yes. It also doesn't use FreeBSD tools to strip binaries anymore, so it's not neccesary anymore to override STRIP and STRIP_CMD. - USE_LINUX_PREFIX implies NO_MTREE now. - In the USE_LINUX case, USE_XLIB now depends upon the linux X11 libraries instead upon the native FreeBSD libraries. - The variable LINUX_BASE_PORT contains a string which is suitable as an item in *_DEPENDS, so if a port BATCH_DEPENDS or FETCH_DEPENDS upon the default (or overriden) linux base, ${LINUX_BASE_PORT} should be used instead of a hardcoded reference. - Change all ports to comply to the "new world order". - The Ports Collection now allows to override the default linux_base port. Specify e.g. OVERRIDE_LINUX_BASE_PORT=rh-9 in /etc/make.conf to use ${PORTSDIR}/emulators/linux_base-rh-9 (the logic is to use ${PORTSDIR}/emulators/linux_base-${OVERRIDE_LINUX_BASE_PORT}). - If USE_LINUX or OVERRIDE_LINUX_BASE doesn't point to an existing linux_base port and if USE_LINUX isn't set to "yes" (case insensitive), the port will be marked as IGNORE. [1] - Readd USE_LINUX knobs into several ports and make several uses of a conditional dependency ("USE_LINUX?=") into an unconditional one ("USE_LINUX=") which where removed/changed by Trevor to allow the use of alternative linux_base ports. While this is a nice goal, the implementation resulted in missing dependencies. The OVERRIDE_LINUX_BASE_PORT knob in this commit is supposed to fix the problem while keeping the feature. Basicaly this includes a backout of Trevor's commit, to prevent confusion I mention it here explicitely. - Use the correct prefix (X11- instead of LOCAL- or LINUX-) for some ports. Chase dependencies for this. - Changes to make linux_devtools installable on amd64, remove some stray device nodes (they don't work on recent OS versions and aren't really needed). - Make linux_base-8 PREFIX clean and remove some stray device nodes. Additionally tell a little bit more about how to setup NIS/YP [2]. - Update the PGSQL dependency in the linux-opengroupware port to a recent version (the old one isn't available anymore), I don't know if this works (at least it isn't more broken than before). - Use PREFIX/usr/share/doc instead of PREFIX/usr/doc in the divx4linux ports, the former path exists already and gets populated by other packages too (PREFIX=LINUXPREFIX!). - Fix some obvious (non-linuxolator) bugs in some linux ports while being there. - Bump PORTREVISION where neccesary. Requested by: portmgr (linimon) [1] Submittted by: Gerrit Kuehn <gerrit_huehn@gruft.fido.de [2] Approved by: portmgr (kris, linimon), maintainers (or maintainer timeout) Tested on: ports cluster (kris) Reviewed by: silence on emulation@ Superseedes PR: 69997 Maintainer approval from: chris@chrisburkert.de cracauer@cons.org des girgen jamie@bishopston.net mezz mi nivit@users.sf.net pat simond@irrelevant.org riggs@rrr.de Udo.Schweigert@Siemens.com
2005-06-18 00:59:29 +02:00
USE_LINUX= 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 )
PLIST_SUB+= MACHINE__TYPES_H="@comment " STDARG_H="" SYS_CDEFS_H="" \
STDBOOL_H=""
.else
PLIST_SUB+= STDARG_H="@comment " SYS_CDEFS_H="@comment "
.if ( ${OSVERSION} < 503103 || ( ${OSVERSION} >= 600000 && ${OSVERSION} < 600013 ) )
PLIST_SUB+= MACHINE__TYPES_H="" STDBOOL_H=""
.else
PLIST_SUB+= MACHINE__TYPES_H="@comment " STDBOOL_H="@comment "
.endif
- 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/}
.endif
.for file in ${DISTFILES}
.if !exists(${DISTDIR}/${DIST_SUBDIR}/${file})
2006-02-12 00:55:41 +01: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"
.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
.endif
.if ( ( ${OSVERSION} >= 502108 && ${OSVERSION} < 503103 ) || ( ${OSVERSION} >= 600000 && ${OSVERSION} < 600013 ) )
- 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
# 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} < 503103 || ( ${OSVERSION} >= 600000 && ${OSVERSION} < 600013 ) )
# Work around a bug in stdbool.h
@${SED} -e 's:__STDC_VERSION__ < 199901L.*:__STDC_VERSION__ < 199901L \&\& defined(__GNUC__) \&\& __GNUC__ < 3 \&\& !defined(__INTEL_COMPILER):g' \
</usr/include/stdbool.h \
>${WRKSRC}/opt/${COMPILERDIR}/include/stdbool.h
.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
Mega-patch to cleanup the ports infrastructure regarding our linux bits: - USE_LINUX now implies NO_FILTER_SHLIBS=yes. It also doesn't use FreeBSD tools to strip binaries anymore, so it's not neccesary anymore to override STRIP and STRIP_CMD. - USE_LINUX_PREFIX implies NO_MTREE now. - In the USE_LINUX case, USE_XLIB now depends upon the linux X11 libraries instead upon the native FreeBSD libraries. - The variable LINUX_BASE_PORT contains a string which is suitable as an item in *_DEPENDS, so if a port BATCH_DEPENDS or FETCH_DEPENDS upon the default (or overriden) linux base, ${LINUX_BASE_PORT} should be used instead of a hardcoded reference. - Change all ports to comply to the "new world order". - The Ports Collection now allows to override the default linux_base port. Specify e.g. OVERRIDE_LINUX_BASE_PORT=rh-9 in /etc/make.conf to use ${PORTSDIR}/emulators/linux_base-rh-9 (the logic is to use ${PORTSDIR}/emulators/linux_base-${OVERRIDE_LINUX_BASE_PORT}). - If USE_LINUX or OVERRIDE_LINUX_BASE doesn't point to an existing linux_base port and if USE_LINUX isn't set to "yes" (case insensitive), the port will be marked as IGNORE. [1] - Readd USE_LINUX knobs into several ports and make several uses of a conditional dependency ("USE_LINUX?=") into an unconditional one ("USE_LINUX=") which where removed/changed by Trevor to allow the use of alternative linux_base ports. While this is a nice goal, the implementation resulted in missing dependencies. The OVERRIDE_LINUX_BASE_PORT knob in this commit is supposed to fix the problem while keeping the feature. Basicaly this includes a backout of Trevor's commit, to prevent confusion I mention it here explicitely. - Use the correct prefix (X11- instead of LOCAL- or LINUX-) for some ports. Chase dependencies for this. - Changes to make linux_devtools installable on amd64, remove some stray device nodes (they don't work on recent OS versions and aren't really needed). - Make linux_base-8 PREFIX clean and remove some stray device nodes. Additionally tell a little bit more about how to setup NIS/YP [2]. - Update the PGSQL dependency in the linux-opengroupware port to a recent version (the old one isn't available anymore), I don't know if this works (at least it isn't more broken than before). - Use PREFIX/usr/share/doc instead of PREFIX/usr/doc in the divx4linux ports, the former path exists already and gets populated by other packages too (PREFIX=LINUXPREFIX!). - Fix some obvious (non-linuxolator) bugs in some linux ports while being there. - Bump PORTREVISION where neccesary. Requested by: portmgr (linimon) [1] Submittted by: Gerrit Kuehn <gerrit_huehn@gruft.fido.de [2] Approved by: portmgr (kris, linimon), maintainers (or maintainer timeout) Tested on: ports cluster (kris) Reviewed by: silence on emulation@ Superseedes PR: 69997 Maintainer approval from: chris@chrisburkert.de cracauer@cons.org des girgen jamie@bishopston.net mezz mi nivit@users.sf.net pat simond@irrelevant.org riggs@rrr.de Udo.Schweigert@Siemens.com
2005-06-18 00:59:29 +02:00
# We can't use STRIP_CMD, since we need the FreeBSD one, not the Linux one.
@/usr/bin/strip ${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
# The static linking case expects a crtbeginT.o. Based upon inspection of
# /usr/src/contrib/gnu/crtstuff.c it seems it's the same as crtbegin.o.
@cd ${WRKSRC}/opt/${COMPILERDIR}/lib && ${LN} -s crtbegin.o crtbeginT.o
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}
@${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 or crashes with an 'Illegal instruction'." | 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>