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