Date: Tue, 2 Apr 2002 10:31:39 +0200 (CEST) From: Alexander Leidinger <Alexander@Leidinger.net> To: freebsd-current@FreeBSD.org Cc: winter@jurai.net Subject: Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include Message-ID: <200204020831.g328VdRj000551@Magelan.Leidinger.net> In-Reply-To: <20020401141059.B23489@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 Apr, David O'Brien wrote:
>> > This is fine just to get things working. But please consider Doing It
>> > Right -- that being wrap the definitions of CC, CFLAGS, and PICFLAG with
>> > USE_ICC rather than strew USE_ICC all over the place. For instance:
>> >
>> > /usr/share/mk/sys.mk
>> > .if defined(USE_ICC)
>> > CC= icc
>> > .else
>> > CC= cc
>> > .endif
>>
>> - How do you want to solve the single suffix rules then?
>
> What is the problem with them?
>
> .c:
> ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.IMPSRC}
>
> CC and CFLAGS is used.
You can't link native FreeBSD binaries with icc, it tries to link
against glibc. You have to use icc to produce object files, and cc to
link them. Obviously substituting cc with icc doesn't work here, so we
need a way to circumvent it, e.g. (untested)
${CC} -c ${CFLAGS} -o - ${.IMPSRC} | ${LD} ${LDFLAGS} -o ${.TARGET}
I don't know if this works, but it should. IMHO.
>> - Do we use ${LD} in every significant place?
>
> If we don't it is a bug -- send in a patch. But LD is `ld', does ICC
> come with its own linker?
It's integrated into 'icc', but see above.
>> - What about ports with "CC=${CC}" in CONFIGURE_ENV (they would break
>> in the USE_ICC case)?
>
> How would they?? CC=icc if you have USE_ICC defined. Either in
> /etc/make.conf or `make USE_ICC=yes'.
>
> It seems you do not realize the whole reason for "${CC}" rather than just
> "cc".
I do realite the whore reason, but this solution doesn't fit the
problem.
We also have files (in the kernel) which fail to compile because they
are assembler files, but they get compiled with CC. Have a look at
http://www.leidinger.net/FreeBSD/LINT_with_icc_20020327_newPORTREVISION_withFixes.log.bz2
I wan't to provide a smooth transition, not a large 'do everything at
once' patch (I first tried to keep the icc parts completely indepenend
form the CC/CFLAGS parts to minimize the gcc specific CFLAGS, but I
realized this would be very time consuming, so I just tried to have
something useable). I haven't the time to do everything at once, but I
(and perhaps others too) have time to do it piecemeal. The actual patch
allows people to already work on fixing the kernel and the userland for
icc, while other people work on designing an improvement for the build
system.
>> >> > -D__attribute__(x)=
>> >> > -D__GNUC__=2
>> >>
>> >> Ok as a short term solution, but IMHO this should get solved in the
>> >> source.
>> >
>> > Totally agreed for defining __GNUC__.
>>
>> And the __attribute__ line is the reason why libc doesn't work.
>
> Explain "does not work".
Matthew wrote:
---snip---
Libc had some issues with malloc and mmap() and wouldn't function when
installed, but other things worked fine.
---snip---
Icc doesn't understand __attribute__(x). I assume it isn't able to do
its job becaue of different alignment and packing issues. But this is a
guess.
Bye,
Alexander.
--
Yes, I've heard of "decaf." What's your point?
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204020831.g328VdRj000551>