Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include
On 2 Apr, Matthew N. Dodd wrote:
>> Oh that is easy to fix. We can do it in one of two ways.
>> Show me the exact link line from icc (I want the equivalent to gcc -v).
I don't know how to produce something like with icc, but...
> We can also tell 'icc' to use our 'ld'.
>
> -Qlocation,ld,/usr/bin
>
> That didn't seem to work to well though as it still tries to use their
> 'crti.o' object.
... I used our ld with icc and let icc invoke it with --verbose. Output
attached.
Bye,
Alexander.
--
0 and 1. Now what could be so hard about that?
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
test.c:
/usr/libexec/elf/ld: warning: libc.so.6, needed by
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1, not found (try using -rpath or
-rpath-link)
/usr/local/intel/compiler50/ia32/lib/crtxi.o: In function
`__record_needed_destruction':
/usr/local/intel/compiler50/ia32/lib/crtxi.o(.text+0x113): undefined reference to
`__cxa_atexit'
/usr/local/intel/compiler50/ia32/lib/crtxi.o(.data+0x58): undefined reference to
`__cxa_finalize'
/usr/local/intel/compiler50/ia32/lib/crtxn.o: In function `__icrt_terminate(void)':
/usr/local/intel/compiler50/ia32/lib/crtxn.o(.text+0xbf): undefined reference to
`__cxa_finalize'
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1: undefined reference to
`[EMAIL PROTECTED]'
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1: undefined reference to
`[EMAIL PROTECTED]'
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1: undefined reference to
`[EMAIL PROTECTED]'
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1: undefined reference to
`[EMAIL PROTECTED]'
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1: undefined reference to
`[EMAIL PROTECTED]'
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1: undefined reference to
`[EMAIL PROTECTED]'
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1: undefined reference to
`[EMAIL PROTECTED]'
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1: undefined reference to
`[EMAIL PROTECTED]'
/usr/local/intel/compiler50/ia32/lib/libcxa.so.1: undefined reference to
`[EMAIL PROTECTED]'
GNU ld version 2.12.0 [FreeBSD] 2002-03-20
Supported emulations:
elf_i386
using internal linker script:
==
/* Default linker script, for normal executables */
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
"elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
SEARCH_DIR("/usr/lib");
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
SECTIONS
{
/* Read-only sections, merged into text segment: */
. = 0x08048000 + SIZEOF_HEADERS;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version: { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.init : { *(.rel.init) }
.rela.init : { *(.rela.init) }
.rel.text : { *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) }
.rela.text : { *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) }
.rel.fini : { *(.rel.fini) }
.rela.fini : { *(.rela.fini) }
.rel.rodata : { *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) }
.rela.rodata: { *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*) }
.rel.data : { *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) }
.rela.data : { *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*) }
.rel.ctors : { *(.rel.ctors) }
.rela.ctors : { *(.rela.ctors) }
.rel.dtors : { *(.rel.dtors) }
.rela.dtors : { *(.rela.dtors) }
.rel.got: { *(.rel.got) }
.rela.got : { *(.rela.got) }
.rel.bss: { *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) }
.rela.bss : { *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*) }
.rel.plt: { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init :
{
KEEP (*(.init))
} =0x90909090
.plt: { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
} =0x90909090
.fini :
{
KEEP (*(.fini))
} =0x90909090
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1: { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN(0x1000) + (. & (0x1000 - 1));
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
.eh_frame : { KEEP (*(.eh_frame)) }
.gcc_except_table : { *(.gcc_except_table) }
.dynamic: { *(.dynamic) }
.ctors :
{
/* gcc uses crtbegin.o to find t
Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include
On Tue, Apr 02, 2002 at 10:31:39AM +0200, Alexander Leidinger wrote: > > You can't link native FreeBSD binaries with icc, it tries to link > against glibc. Oh that is easy to fix. We can do it in one of two ways. Show me the exact link line from icc (I want the equivalent to gcc -v). -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include
On Sat, Mar 30, 2002 at 10:03:47AM +0100, Alexander Leidinger wrote:
> On 29 Mär, David O'Brien wrote:
>
> >> > 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.
> >
> > 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.
> - 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?
> - 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".
> >> > -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".
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ICC userland patch (was: Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include)
On 29 Mär, David O'Brien wrote: >> Not tested, feel free to point out some typo's: >> http://www.leidinger.net/FreeBSD/icc.mk.diff > > Also forbidden to access. Fixed. Sorry. Bye, Alexander. -- Reboot America. 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
Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include
On 29 Mär, David O'Brien wrote:
>> > 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.
>
> 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?
- Do we use ${LD} in every significant place?
- What about ports with "CC=${CC}" in CONFIGURE_ENV (they would break
in the USE_ICC case)?
>> > -D__ICC__=1
>>
>> ICC already defines '__ICC', doe we really need this?
>
> I see no reason for it. We should use the vendor's spelling for
> identifying their compiler.
>
>> > -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.
Bye,
Alexander.
--
The computer revolution is over. The computers won.
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
Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include
On Fri, Mar 29, 2002 at 11:44:06AM +0100, Alexander Leidinger wrote: > > 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. 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 > > -D__ICC__=1 > > ICC already defines '__ICC', doe we really need this? I see no reason for it. We should use the vendor's spelling for identifying their compiler. > > -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__. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ICC userland patch (was: Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include)
On Fri, Mar 29, 2002 at 12:33:37PM +0100, Alexander Leidinger wrote: > Not tested, feel free to point out some typo's: > http://www.leidinger.net/FreeBSD/icc.mk.diff Also forbidden to access. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ICC userland patch (was: Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include)
On 29 Mär, An: [EMAIL PROTECTED] wrote: >> My patches to src/share/mk/ are here: >> >> ftp://ftp.jurai.net/users/winter/icc.mk.diff Not tested, feel free to point out some typo's: http://www.leidinger.net/FreeBSD/icc.mk.diff It's based upon your patch and addresses the points below. > My review of your patch: > bsd.lib.mk: >- Shouldn't ICC_PICFLAG be encapsulated withhin '.if !defined(ICC_PICFLAC)' > like PICFLAG is? > sys.mk: >- Have a look at the '#ICC' line. >- You've commented bsd.cpu.mk out. We should add USE_ICC stuff there too. Bye, Alexander. -- Secret hacker rule #11: hackers read manuals. 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
Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include
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:
bsd.lib.mk:
- Shouldn't ICC_PICFLAG be encapsulated withhin '.if !defined(ICC_PICFLAC)'
like PICFLAG is?
bsd.prog.mk:
- Does ${LOCALBASE} instead of /usr/local work here?
sys.mk:
- 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
source.
> -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 CWARNFLAGS
> setenv NO_WARNS yes
I think they should reside in /etc/make.conf...
Bye,
Alexander.
--
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
Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include
On Thu, Mar 28, 2002 at 08:23:27PM -0500, Matthew N. Dodd wrote: > On Thu, 28 Mar 2002, David O'Brien wrote: > > On Thu, Mar 28, 2002 at 06:37:25PM -0500, Matthew N. Dodd wrote: > > > icc.cfg: > > ... > > > -D__GNUC__=2 > > > > This is really wrong. Why not properly impliment cdefs.h for __ICC__ ? > > Of course its really wrong. > > How else am I supposed to deal with files that are booby trapped to ONLY > work with GCC? Typically these files use inline asm calls, which 'icc' > supports just fine. Either add "|| defined(__ICC__)" where they are used. Or if the syntax is slightly different, make a version for ICC. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include
On Thu, Mar 28, 2002 at 06:37:25PM -0500, Matthew N. Dodd wrote: > icc.cfg: ... > -D__GNUC__=2 This is really wrong. Why not properly impliment cdefs.h for __ICC__ ? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
LINT compiled with icc (was: Re: cvs commit: ports/lang Makefile ports/lang/icc Makefile distinfo pkg-comment pkg-descr pkg-plist ports/lang/icc/files patch-include)
[cvs* stripped, -current added] On 27 Mär, I wrote: > I just startet a LINT compile (-current as of ~2 hours ago) with icc, > expect the compile log to appear at http://www.leidinger.net/FreeBSD/ as > soon as it finishes. > I also will include a list of generated object files at the end of the > log. I've also outlined some errors at the end of the log which seem to me (I'm not a kernel hacker) to be the most fruitfull ones. The compressed log is at http://www.leidnger.net/FreeBSD/LINT_with_icc_20020327.log.bz2 (71k), it's about 3MB uncompressed. Have fun with it. Bye, Alexander. -- Weird enough for government work. 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
