On 28 Mär, Matthew N. Dodd wrote:

>> I've tried to give it a start, so I also allowed __ICC in pcpu.h, now it
>> fails with:
> I got most of src/bin src/sbin src/usr.bin src/usr.sbin and lib to compile
> with it.

Does libm work? At my first try (January) ICC complained about some
files. But perhaps BDE's commits to the libm solved these...

> Libc had some issues with malloc and mmap() and wouldn't function when
> installed, but other things worked fine.
> My patches to src/share/mk/ are here:
>       ftp://ftp.jurai.net/users/winter/icc.mk.diff
> This allows you to set 'USE_ICC' and 'ICFLAGS' and build stuff.

Personally I would prefer ICCCFLAGS or ICC_CFLAGS.

My review of your patch:
   - Shouldn't ICC_PICFLAG be encapsulated withhin '.if !defined(ICC_PICFLAC)'
     like PICFLAG is?
   - Does ${LOCALBASE} instead of /usr/local work here?
   - Have a look at the '#ICC' line.
   - The single suffix rules are wrong (line 127, 195). This has to get
     splitted into an icc compile line and a CC link line. Perhaps with
     a temporary file (mtemp(1)) which gets rm'ed after linking.
   - You've commented bsd.cpu.mk out. We should add USE_ICC stuff there too.
> Setting 'CFLAGS' to nil and 'NO_WARNS' is also a good idea.
> icc.cfg:

I reordered the lines a little bit:

> -Ulinux
> -U__linux__
> -U__linux
> -D__FreeBSD__=5
> -D__ELF__=1

hould I add these to the port? Seems to be a good idea to me...

> -D__ICC__=1

ICC already defines '__ICC', doe we really need this?

> -D__attribute__(x)=
> -D__GNUC__=2

Ok as a short term solution, but IMHO this should get solved in the

> -nolib_inline

I have to look this up, but if this means some of the distributable icc
libs don't get linked into the programs, then I don't think this is a
good idea. This makes the complete userland dependend on the icc port.

> -X
> -I/usr/include

Why? Did I missed a linux secific include file?

> I also added a few lines to my
> /usr/local/intel/compiler50/ia32/bin/iccvars.csh

> setenv ICFLAGS '-O3 -tpp6 -ip'
> setenv USE_ICC
> setenv CFLAGS
> setenv NO_WARNS yes

I think they should reside in /etc/make.conf...


            Give a man a fish and you feed him for a day;
     teach him to use the Net and he won't bother you for weeks.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to