Re: pkg-comment
> > That will certainly be a big help. When we got rid of the pkg/ and
> > patches/ directories I begged Satoshi to go farther and put patches in
> > main port directory and get rid of pkg/COMMENT. That was back when we
> > hit 3000 ports -- I guess people didn't want to accept we would hit 8000
> > in only a few years.
> >
> > Of course why we don't just put "COMMENT=blah" in the ports's Makefile
>
> Posted patch uses `head -1 ${DESCR}` however.
> I'd prefer to go NetBSD way and use COMMENT=blah for ports comments
This patch is small and simple and allows us to reclaim a huge number of
inodes. It also allows for an easy transition.
I think the information in the comment probably belongs at the top of the
description as well, but either way is fine as soon as I see a patch for
other proposed placement. I just want my inodes back, sooner rather than
later.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pkg-comment
hi, there!
On Mon, Aug 12, 2002 at 12:36:51PM -0700, David O'Brien wrote:
> > > Since pkg-comment contains only a single line, wouldn't it be more subtile
> > > to put it in a COMMENT field as does NetBSD, instead of using a file? I think
> > > it would speed up updates.
> >
> > http://people.FreeBSD.org/~eric/ports-comment.diff
> >
> > Will Andrews said that portmgr would be going over this sometime soon,
> > hopefully they will commit it.
>
> That will certainly be a big help. When we got rid of the pkg/ and
> patches/ directories I begged Satoshi to go farther and put patches in
> main port directory and get rid of pkg/COMMENT. That was back when we
> hit 3000 ports -- I guess people didn't want to accept we would hit 8000
> in only a few years.
>
> Of course why we don't just put "COMMENT=blah" in the ports's Makefile
Posted patch uses `head -1 ${DESCR}` however.
I'd prefer to go NetBSD way and use COMMENT=blah for ports comments
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: pkg-comment
On Sun, Aug 11, 2002 at 12:23:19PM -0700, Eric Melville wrote: > > Since pkg-comment contains only a single line, wouldn't it be more subtile > > to put it in a COMMENT field as does NetBSD, instead of using a file? I think > > it would speed up updates. > > http://people.FreeBSD.org/~eric/ports-comment.diff > > Will Andrews said that portmgr would be going over this sometime soon, > hopefully they will commit it. That will certainly be a big help. When we got rid of the pkg/ and patches/ directories I begged Satoshi to go farther and put patches in main port directory and get rid of pkg/COMMENT. That was back when we hit 3000 ports -- I guess people didn't want to accept we would hit 8000 in only a few years. Of course why we don't just put "COMMENT=blah" in the ports's Makefile To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pkg-comment
> Since pkg-comment contains only a single line, wouldn't it be more subtile > to put it in a COMMENT field as does NetBSD, instead of using a file? I think > it would speed up updates. http://people.FreeBSD.org/~eric/ports-comment.diff Will Andrews said that portmgr would be going over this sometime soon, hopefully they will commit it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pkg-comment
Since pkg-comment contains only a single line, wouldn't it be more subtile to put it in a COMMENT field as does NetBSD, instead of using a file? I think it would speed up updates. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: ports/sysutils Makefile ports/sysutils/rclean Makefile distinfo pkg-comment pkg-descr pkg-plist
On Wed May 15, 2002 at 09:55:42PM +0300, Maxim Sobolev wrote: > The Anarcat wrote: > > > > [putting anti-flame on] s/on/suit on/ > To invite a normal discussion you should at least provide the > following information: Well, I expected people to look at the port, but I'll provide more information here. > - What `rclean' is for? " rclean provides a command-line tool to order and clean content of rc.conf, using option order from /etc/defaults/rc.conf and printing only choices that were different by the default value in /etc/rc.conf. Output is customizable from "only used values" to "full listing". WWW: http://www.lapo.it/rclean/ " > - Why do you think it could be useful in base system? Well, that part is more personal, but I think it could remove the tendency people have of complaining about the current /etc/defaults scheme. There has been a few threads about problems arising when /etc/defaults/rc.conf was getting updated. I think rclean might help solve those problems, in the same spirit mergemaster helps managing configuration file changes. > Your assumption that the list readers know answers to those two > questions (or would care enough to dig for the answers by themselves) > is incorrect and entitles you not to flamewar but to "ugh, what this > is all about?" reaction from their part and likely to the complete > lack of any discussion at all as a result. I wonder what's best after all. ;) I must admit I was being a bit blunt by just challenging people to put this in base, somehow assuming everything should go in. In other words, the question is: "Why should this go in base?" rather than: "Why isn't this in base?" My apologies. A. -- Un éducateur dans l'âme ne prend rien au sérieux que par rapport à ses disciples -- soi-même non excepté. - Nietzsche, "Par delà le bien et le mal" msg38387/pgp0.pgp Description: PGP signature
Re: (fwd) Re: cvs commit: ports/sysutils Makefile ports/sysutils/rclean Makefile distinfo pkg-comment pkg-descr pkg-plist
The Anarcat wrote: > > [putting anti-flame on] To invite a normal discussion you should at least provide the following information: - What `rclean' is for? - Why do you think it could be useful in base system? Your assumption that the list readers know answers to those two questions (or would care enough to dig for the answers by themselves) is incorrect and entitles you not to flamewar but to "ugh, what this is all about?" reaction from their part and likely to the complete lack of any discussion at all as a result. -Maxim > > -- > N'aimer qu'un seul est barbarie, car c'est au détriment de tous les > autres. Fût-ce l'amour de Dieu. > - Nietzsche, "Par delà le bien et le mal" > > -- > > Subject: Re: cvs commit: ports/sysutils Makefile ports/sysutils/rclean Makefile >distinfo pkg-comment pkg-descr pkg-plist > Date: Thu, 16 May 2002 03:15:29 +0900 > From: SADA Kenji <[EMAIL PROTECTED]> > Organization: Private > To: The Anarcat <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > > On Wed, 15 May 2002 13:16:52 -0400 > The Anarcat <[EMAIL PROTECTED]> wrote: > > > Why isn't this part of base? > > It needs agreement of -current. > Why don't you ask there ? > > -- > Computer science is no more about computers > than astronomy is about telescopes > - E. Dijkstra > > -- >Part 1.2Type: application/pgp-signature To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(fwd) Re: cvs commit: ports/sysutils Makefile ports/sysutils/rclean Makefile distinfo pkg-comment pkg-descr pkg-plist
[putting anti-flame on] -- N'aimer qu'un seul est barbarie, car c'est au détriment de tous les autres. Fût-ce l'amour de Dieu. - Nietzsche, "Par delà le bien et le mal" --- Begin Message --- On Wed, 15 May 2002 13:16:52 -0400 The Anarcat <[EMAIL PROTECTED]> wrote: > Why isn't this part of base? It needs agreement of -current. Why don't you ask there ? -- Computer science is no more about computers than astronomy is about telescopes - E. Dijkstra --- End Message --- msg38383/pgp0.pgp Description: PGP signature
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
