There slipped in a hardcoded /usr/local, it was supposed to be a
placeholder for LOCALBASE (to find the stlport lib in the ld wrapper).
Thanks to: Marius Strobl <marius@alchemy.franken.de>
for reviewing the commits.
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]
- Transform some warnings into errors as suggested by some included
docs (some kind of MSVC compatibility which isn't reverted in icc
for linux).
ld.c:
- add possibility to use a different threads lib via PTHREAD_LIBS
variable (e.g. PTHREAD_LIBS=-lthr) [1]
this may be subject to change when gcc learns how to handle our
different threads libs
- refactor some code [1][2]
- remove mailwrapper license, there's no code from mailwrapper
anymore [2]
- correct the order of libc and libc_r [1][2]
Submitted by: mi [1]
Submitted by: Marius Strobl <marius@alchemy.franken.de> [2]
Reviewed by: Marius Strobl <marius@alchemy.franken.de> [1]
icc -shared -o libfoo.so foo.o -lbaz
the ld wrapper gets confused and thinks that a static link is intended
and the link fails. This patch appears to fix things.
Submitted by: dfr
(this may break ports which depend upon OpenSSL from ports which was
compiled as a base system replacement because it includes a system
header directory again)
- ignore "-pipe" in CFLAGS, this should unbreak some ports with hardcoded
"-pipe"
Noticed by: Krzysztof Parzyszek <kristof@swissmail.org> [1]
Tested by: Krzysztof Parzyszek <kristof@swissmail.org> [1]
path, thus adding a system path with -I results in not respecting the
sunstitute headers. This results in problems because we have some important
changes there.
Parts of this commit where
Submitted by: marius@alchemy.franken.de
- fix [dfi]vec.h with stlport-iostreams
- do not install a Windows header (mathf.h)
- do not install libompstub (depends on pthread_atfork(), see PR 17437)
Submitted by: marius@alchemy.franken.de
- point to the icc errata after make install
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.
- Use an exclude file for cpio, there's not much sense in extracting
and chmod'ing a whole bunch of files only to delete them afterwards.
- Fix two bugs in the ld-wrapper that could cause it to dump core in
rare cases.
- Remove a forgotten C++ include.
- Improve IGNORE message.
Submitted by: marius@alchemy.franken.de
- link libc_p.a/lib_c_r.a when compiling with "-pg -static"
- fix unresolved symbols to make "-pg" and "-prof_gen" work
Submitted by: marius@alchemy.franken.de
Approved by: kris
- Re-enable patching of iccvars.(c)sh (solely called by icid and therefore
overlooked), accidentally broken by last commit.
- Fix generation of multi-threaded code, triggered by the (badly documented)
compiler option "-mt".
- Disable compiler options "-openmp*" and "-parallel", they depend on
libguide which itself depends on pthread_atfork() (not provided by libc_r),
therefore don't install libguide.
Note: All compiler options are now believed to either work on FreeBSD or
be disabled (Maintainer note: '-prof_gen' is under investigation).
- Add a message about installing stlport-icc in order to get full C++ support.
- Remove workaround for generation of shared objects with binutils/ld 2.12.x,
appears to be fixed (unfortunately no confirmation by Intel Support, "That
is good news <...> then we should just close this issue." *sigh*).
Submitted by: marius@alchemy.franken.de
- Add note about a problem on P4 and how to solve it.
Suggested by: Martin Kahlert <martin.kahlert@infineon.com>
- Remove outdated information in pkg-descr.
handling when generating shared objects with binutils/ld 2.12.[0,1], link
in the icc C++ ABI definitions not those of gcc
- remove libcprts (STL): it has unresolvable glibc dependencies in both,
dynamic and static, versions, therefore is not usable and entirely unneeded
when libstlport is used instead
- add libimf (Intel's optimized math functions library), while there's no
measurable speed improvement (at least for the functions tested) in
comparison to FreeBSD's libm beyond the "normal" icc vs. gcc boost icc
occasionally produces code depending on libimf when told to optimize for
Pentium 4
- replace the ld-script with a wrapper written in C as (c)sh is a bit limited
and long winded for that purpose
- minor stuff and cleanup
Submitted by: marius@alchemy.franken.de
- use reinplace command where appropriate
- gzip man page
- clarify download instructions (1)
- fix typo in a comment (2)
- preparation for successfull C++ compiles (2, minor changes by me)
Even if I bumped the port revision for the C++ parts, there's no need to
update yet, wait until I commit the icc-stlport.
Requested by: mi (1)
Submitted by: Marius Strobl <marius@alchemy.franken.de> (2)
