Re: New ipfw code available
÷ Sun, 09.06.2002, × 07:19, Luigi Rizzo ÎÁÐÉÓÁÌ:
Hi
over the past 2-3 weeks I have done an extensive rewrite of the
ipfw code (userland + kernel) in an attempt to make it faster and
more flexible.
The idea (which I discussed a few times on the mailing lists) was
to replace the current ipfw rules (macroinstructions) with a set
of microinstructions, each of them performing a single operation
such as matching an address, or a port range, or a protocol flag,
etc. -- much in the spirit of BPF and derivatives -- and to let
the userland front-end compile ipfw(8) commands into an appropriate
set of microinstructions.
Really COOL!
And what about radix-tree-based ip-list matching ?
like this:
ipfw add 1 allow ip from {1.2.3.0/24,1.3.5.0/24,17.2.3.4/45,11.2.3.4/30}
or
cat mylist | ipfw list add mylist -
ipfw add 1 allow ip from @mylist
or something like
If you deal with large access-lists ipfw becomes not best tool due to
linear comparison.
translates to a couple of microinstructions (whose complete
implementation is below the instructions themselves):
O_IP_DST
if (((ipfw_insn_ip *)cmd)-addr.s_addr ==
(dst_ip.s_addr ((ipfw_insn_ip *)cmd)-mask.s_addr))
goto cmd_match;
goto cmd_fail;
O_ACCEPT:
retval = 0; /* accept */
goto accept;
But there is a lot more -- the instruction set is easily extensible,
and without backward compatibility problems. Furthermore, you can
build (and I have already implemented them) more complex rules by
assembling microinstructions with OR and NOT operands. I.e. you can write
something like:
pipe 10 tcp from 1.2.3.4 or 1.2.3.7 or not 1.2.3.0/28 21-25,1024-4095 \
to any in recv ed0 or recv fxp1 or recv dc0 uid 35 or uid 50
You get the idea...
I have a fairly complete version of the above code at the moment,
which is only missing a small set of functionalities
(ip/tcp flags matching, log and fixing hooks to the stateful
code). However the glue to implement all the missing pieces is
already there, it is just a matter of adding a few lines of code
and testing things.
Other than that, the code is meant to be fully compatible with the
old syntax so you will not have to rewrite your existing rulesets.
I have put a preliminary snapshot of this code (for CURRENT) at
http://info.iet.unipi.it/~luigi/ipfw5.20020609.tgz
It replaces the following files from a recent (2002/05/14) version of -current.
sys/netinet/ip_dummynet.c
sys/netinet/ip_fw.c
sys/netinet/ip_fw.h
sbin/ipfw/ipfw.c
I would be very grateful if someone could have a look at the
code, maybe give it a try, and see e.g. how it compiles your
typical ruleset and whether the new extensions can make your
ipfw rulesets simpler.
Feedback welcome, both on the architecture and on the implementation.
NOTE: if people wonder why I did not use BPF and reinvented the wheel:
the keyword is backward compatiblity -- i thought it was a bit too
complex to compile the existent ipfw syntax into BPF, especially because
BPF at least as far as i know does not handle UIDs, and GIDs and
interface matches and different actions than match or not match,
so i would have had to extend the code anyways, at which point i
thought I could as well write my own microinstruction set...
cheers
luigi
---+-
Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
Mobile +39-347-0373137
---+-
to
thanks
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
Vladimir B. Grebenschikov
[EMAIL PROTECTED], SWsoft, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Sat, 08 Jun 2002 10:57:32 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: Is the solution to this to use M_NOWAIT and continue re-trying untill it succeeds? Is there on-going smp work in locking down struct proc that will eliminate this problem? Well, the real solution probably involves changing where we dink with uidinfo structs so we bump the reference count on teh new one before we grab the proc lock, change over to the new one while holding the proc lock, then release the reference to the old one after we are done. Well... this is basically what happens setuid - creates a new ucred - locks p - calls change_ruid() change_ruid - calls uifind() uifind - does MALLOC w/ M_WAITOK After thinking about it for a while, this is the solution I came up with: Each new struct ucred will carry an array of pointers to struct uidinfo. This will be an array of 3 elements (a spare for cr_ruidinfo, cr_uidinfo, null). Obviously, it gets added after -cr_endcopy. When crget() is called it calls a function whose job it is to create an array of pointers to struct uidinfo and allocate the memory for them. When uifind() is called it will be given an array of pointers to uidinfo structs (the ones from ucred), in addition to the uid it is to lookup. If it already has a uidinfo for that uid, then it returns that to the calling function. If it can't find the uid, then it unhooks (copies the address, and deletes it from the array) the last struct uidinfo from the array, initializes it, inserts it into the hashtable and returns it to the caller. When crfree is called it calls a function that deallocates the spare structs uidinfo. This solution has the advantage that the only code that has to change is the ucred and setuid/gid helper functions that already know about the struct uidinfo functions. In fact only three functions not related to uidinfo(9) need to be touched: proc0_init(), change_ruid(), change_uid(). The disadvantage is the memory bloat and a small amount of code complexity (but as I said, this is localized, and not very complex either). Do you like it? Should I go ahead and implement a patch? Anything I overlooked? Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New ipfw code available
On Mon, Jun 10, 2002 at 12:47:40PM +0400, Vladimir B. Grebenschikov wrote:
...
And what about radix-tree-based ip-list matching ?
yes, it is planned.
cheers
luigi
ipfw add 1 allow ip from {1.2.3.0/24,1.3.5.0/24,17.2.3.4/45,11.2.3.4/30}
or
cat mylist | ipfw list add mylist -
ipfw add 1 allow ip from @mylist
or something like
If you deal with large access-lists ipfw becomes not best tool due to
linear comparison.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: My postgresql7 not working for new gcc
--- aaron g [EMAIL PROTECTED] wrote: I do beleive the OpenSSL library has moved to a new default location. I could be wrong. - aarong -- I don't think it has been moved as of yestersday. Regards, shizuka# ls -al /usr/include/openssl/ssl.h -r--r--r-- 1 root wheel 60914 Jun 9 02:30 /usr/include/openssl/ssl.h __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My postgresql7 not working for new gcc
On Mon, Jun 10, 2002 at 02:52:02AM -0700, Shizuka Kudo wrote: --- aaron g [EMAIL PROTECTED] wrote: I do beleive the OpenSSL library has moved to a new default location. I could be wrong. - aarong -- I don't think it has been moved as of yestersday. OpenSSL has not moved (and is not expected to be moved). Kris msg39426/pgp0.pgp Description: PGP signature
Re: My postgresql7 not working for new gcc
On Wed, Jun 05, 2002 at 04:35:40AM -0700, Shizuka Kudo wrote: snip/ checking for readline/readline.h... no checking for readline.h... no checking for readline/history.h... no checking for history.h... no checking for openssl/ssl.h... no configure: error: header file openssl/ssl.h is required for OpenSSL actually that is a problem with the autoconf version used by postgresql. the new gcc 3.1 gives out a warning if one of the system include directories is also given as a -I argument (in this case -I/usr/include). the autoconf, when compiling the test program, mistakenly interprets this warning as an error, and decides that the feature is not present, thus giving that openssl/ssl.h is not present, and in fact it is. one messy and temporary solution is to compile with make CFLAGS=-Wp,-w CXXFLAGS=-Wp,-w which tells gcc to pass -w to the preprocessor, and -w means inhibit all warnings. with this, postgresql compiles and works fine. for 'correct' solution - the configure script for postgresql must be regenerated from configure.in, using the newer autoconf, but I am not sure whether that would be successfull, as there were (AFAIK), some incompatibilities between the two - but i may be wrong. anyway, HTH -tacho -- [a lie is my shield] | [http://daemonz.org/ || [EMAIL PROTECTED]] 0x44fc3339 || [02b5 798b 4bd1 97fb f8db 72e4 dca4 be03 44fc 3339] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problems building world in kdump
Hi there, I've been attempting to build current on and off over the past few weeks with little success. Problems occur when making dependencies within kdump as shown below. Sources last update June 9, 2002 at 12:30 GMT. I've been through UPDATING, README and mailling lists to no avail. Any assistance appreciated. Regards, Scott. === usr.bin/kdump sh /usr/src/usr.bin/kdump/mkioctls /usr/obj/usr/src/i386/usr/include ioctl.c cpp0: warning: changing search order for system directory /usr/obj/usr/src/i386/usr/include cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory /usr/obj/usr/src/i386/usr/include cpp0: warning: as it has already been specified as a non-system directory In file included from /usr/obj/usr/src/i386/usr/include/sys/param.h:107, from /usr/obj/usr/src/i386/usr/include/security/lomac/lomacio.h:42, from stdin:49: /usr/obj/usr/src/i386/usr/include/machine/limits.h:71:1: warning: INT_MAX redefined In file included from stdin:23: /usr/obj/usr/src/i386/usr/include/machine/if_wl_wavelan.h:149:1: warning: this is the location of the previous definition In file included from stdin:70: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:19:1: warning: MDF_ACTIVE redefined In file included from stdin:47: /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:115:1: warning: this is the location of the previous definition In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:860:1: warning: EATAUSRCMD redefined In file included from stdin:97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:265:1: warning: this is the location of the previous definition In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:861:1: warning: DPT_SIGNATURE redefined In file included from stdin:97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:269:1: warning: this is the location of the previous definition In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:862:1: warning: DPT_NUMCTRLS redefined In file included from stdin:97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:274:1: warning: this is the location of the previous definition In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:863:1: warning: DPT_CTRLINFO redefined In file included from stdin:97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:276:1: warning: this is the location of the previous definition In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:864:1: warning: DPT_SYSINFO redefined In file included from stdin:97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:282:1: warning: this is the location of the previous definition In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:865:1: warning: DPT_BLINKLED redefined In file included from stdin:97: /usr/obj/usr/src/i386/usr/include/vm/dev/asr/osd_unix.h:288:1: warning: this is the location of the previous definition In file included from stdin:101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:379:1: warning: LUN_MASK redefined In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:138:1: warning: this is the location of the previous definition In file included from stdin:101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:380:1: warning: TARGET_MASK redefined In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:135:1: warning: this is the location of the previous definition In file included from stdin:101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:381:1: warning: BUS_MASK redefined In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:136:1: warning: this is the location of the previous definition In file included from stdin:101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:382:1: warning: HBA_MASK redefined In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:137:1: warning: this is the location of the previous definition In file included from stdin:101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:384:1: warning: minor2lun redefined In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:143:1: warning: this is the location of the previous definition In file included from stdin:101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:385:1: warning: minor2target redefined In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:140:1: warning: this is the location of the previous definition In file included from stdin:101: /usr/obj/usr/src/i386/usr/include/vm/dev/iir/iir.h:386:1: warning: minor2bus redefined In file included from stdin:100: /usr/obj/usr/src/i386/usr/include/vm/dev/dpt/dpt.h:141:1: warning: this is the location of
Re: My postgresql7 not working for new gcc
Stanislav Grozev wrote: actually that is a problem with the autoconf version used by postgresql. the new gcc 3.1 gives out a warning if one of the system include directories is also given as a -I argument (in this case -I/usr/include). the autoconf, when compiling the test program, mistakenly interprets this warning as an error, and decides that the feature is not present, thus giving that openssl/ssl.h is not present, and in fact it is. one messy and temporary solution is to compile with make CFLAGS=-Wp,-w CXXFLAGS=-Wp,-w which tells gcc to pass -w to the preprocessor, and -w means inhibit all warnings. with this, postgresql compiles and works fine. for 'correct' solution - the configure script for postgresql must be regenerated from configure.in, using the newer autoconf, but I am not sure whether that would be successfull, as there were (AFAIK), some incompatibilities between the two - but i may be wrong. anyway, HTH That's ugly. Since it's jamming in includes anyway: By using both `-nostdinc' and `-I-', you can limit the include-file search file to only those directo- ries you specify explicitly. e.g.: you should be able to get it to work with warnings fully enabled, and explicit use of system include paths in the Makefile. This might be a more permanent fix... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current (DP1) and USB transfers
Maksim Yevmenkin writes: The problem is that as soon as i open isochronous pipe and start incoming isochronous transfer, the isochronous callback gets called over and over again. Both isoc. pipe and isoc. transfer have USBD_NO_SHORT_XFER flag set. I also set configuration #5 for interface 1. The funny part that device says that it got zero bytes from the pipe. It does not affect (or so it seems) the other transfers and everything still works. I also tried ugen driver with the same results. What is up with that? My experience with isochronous pipes is the same. I'm working with a couple of webcams and the isoc callback is invoked repeatedly, but always with a size of 0. This occurs in both -stable and -current, tested on two different UHCI chipsets. I also played around with ugen (stock ugen and a userland driver, as well as a custom ugen) but the results were the same. While I have no other USB devices to try out under FreeBSD, my guess is that the problems are mainly with isoc transfers; there are plenty of supported devices using bulk and interrupt transfers but there is only one case I'm aware of that makes use of isoc transfers. Reportedly a different webcam works under 4.6-RC using ugen and a userland program (/usr/ports/graphics/vid). I'm also a USB newbie so I cannot answer your other questions. Carlos -- Carlos A. Ugarte[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My postgresql7 not working for new gcc
On Mon, Jun 10, 2002 at 07:02:14AM -0700, Terry Lambert wrote: Stanislav Grozev wrote: That's ugly. well, i _did_ mention that it's a messy and a temporary solution, but at least it gets postgresql (and many others) to compile and run fine. Since it's jamming in includes anyway: By using both `-nostdinc' and `-I-', you can limit the include-file search file to only those directo- ries you specify explicitly. e.g.: you should be able to get it to work with warnings fully enabled, and explicit use of system include paths in the Makefile. This might be a more permanent fix... I agree... but still I don't see the point in that warning, which is useless (IMHO) in 99% of the cases (normal development) and in the 1% where it is usefull (gcc devel, libc, etc.) the people doing it already know their stuff and know what they're doing. but I digress... -- Terry -tacho -- [a lie is my shield] | [http://daemonz.org/ || [EMAIL PROTECTED]] 0x44fc3339 || [02b5 798b 4bd1 97fb f8db 72e4 dca4 be03 44fc 3339] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My postgresql7 not working for new gcc
On Mon, Jun 10, 2002 at 07:02:14AM -0700, Terry Lambert wrote: one messy and temporary solution is to compile with make CFLAGS=-Wp,-w CXXFLAGS=-Wp,-w which tells gcc to pass -w to the preprocessor, and -w means inhibit all warnings. with this, postgresql compiles and works fine. for 'correct' solution - the configure script for postgresql must be regenerated from configure.in, using the newer autoconf, but I am not sure whether that would be successfull, as there were (AFAIK), some incompatibilities between the two - but i may be wrong. anyway, HTH That's ugly. Since it's jamming in includes anyway: By using both `-nostdinc' and `-I-', you can limit the include-file search file to only those directo- ries you specify explicitly. e.g.: you should be able to get it to work with warnings fully enabled, and explicit use of system include paths in the Makefile. This might be a more permanent fix... *sigh*, why not a *real* fix? --- configure.in.orig Thu Sep 27 01:03:56 2001 +++ configure.inMon Apr 29 13:20:27 2002 @@ -200,7 +200,9 @@ done if test $ac_found_openssl_lib_dir != no; then echo found in $ac_found_openssl_lib_dir - INCLUDES=-I$ac_found_openssl_inc_dir $INCLUDES + if test $ac_found_openssl_inc_dir != /usr/include; then + INCLUDES=-I$ac_found_openssl_inc_dir $INCLUDES + fi DEFINES=-DOPENSSL $DEFINES else echo not found. You'll note that they bother with this kind of check for other headers, but for some reason didn't consider it for openssl headers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel breakage in XE module
Been trying to buildkernel, and as of about 2 weeks ago something
happened to the XE module. Anyone have some ideas?
-Troy
=== xe
@ - /usr/src/sys
machine - /usr/src/sys/i386/include
awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h
awk -f @/tools/makeobjops.awk @/dev/pccard/card_if.m -h
awk -f @/tools/makeobjops.awk @/kern/device_if.m -h
rm -f .depend
CC='/usr/bin/cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I.
-I@ -I@/dev -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/mod
ules/xe/../../dev/xe/if_xe.c /usr/src/sys/modules/xe/../../dev/xe/if_xe_pccard.c
cd /usr/obj/usr/src/sys/SINDROME; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386
MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec GROFF_BIN_PATH=
/usr/obj/usr/src/i386/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386
INSTALL=sh /usr/src/tools/install.sh
PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/l
ibexec make KERNEL=kernel all
/usr/bin/cc -c -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winl
ine -Wcast-qual -Wno-format -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src
/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/us
r/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common
-mpreferred-stack-boundary=2 -ffreestanding /usr/src/sys/i386/i386/locore.s
{standard input}: Assembler messages:
{standard input}:1684: Warning: rest of line ignored; first ignored character is
`t'
{standard input}:1686: Error: unknown pseudo-op: `.'
{standard input}:1801: Error: missing ')'
{standard input}:1801: Error: missing ')'
{standard input}:1801: Error: junk `tmpstk)- 0xc000)' after expression
*** Error code 1
Stop in /usr/obj/usr/src/sys/SINDROME.
*** Error code 1
Stop in /usr/src.
*** Error code 1
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Kernel breakage in XE module
In the last episode (Jun 10), Troy said: Been trying to buildkernel, and as of about 2 weeks ago something happened to the XE module. Anyone have some ideas? Upgrade your gcc in the base system. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compilingXFree86-4-libraries
The libraries build for me without incident. However, anything which tries to link against libGLU generates this error for me: /usr/X11R6/lib/libGLU.so: undefined reference to `operator new[](unsigned)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete(void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `__gxx_personality_v0' /usr/X11R6/lib/libGLU.so: undefined reference to `__cxa_pure_virtual' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete[](void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator new(unsigned)' -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 2L, UST School of Law Minneapolis, Minnesota If you want to follow Jesus, you better look good on wood. --Daniel Berrigan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On Mon, Jun 10, 2002 at 12:02:41PM -0500, Michael D. Harnois wrote: The libraries build for me without incident. However, anything which tries to link against libGLU generates this error for me: Your current is too old. Please do a fresh build. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compilingXFree86-4-libraries
On Mon, 2002-06-10 at 12:13, David O'Brien wrote: On Mon, Jun 10, 2002 at 12:02:41PM -0500, Michael D. Harnois wrote: The libraries build for me without incident. However, anything which tries to link against libGLU generates this error for me: Your current is too old. Please do a fresh build. Since 6:30 last night? -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 2L, UST School of Law Minneapolis, Minnesota Wise men talk because they have something to say; fools, because they have to say something. -- Plato To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On Mon, Jun 10, 2002 at 12:15:40PM -0500, Michael D. Harnois wrote: On Mon, 2002-06-10 at 12:13, David O'Brien wrote: On Mon, Jun 10, 2002 at 12:02:41PM -0500, Michael D. Harnois wrote: The libraries build for me without incident. However, anything which tries to link against libGLU generates this error for me: Your current is too old. Please do a fresh build. Since 6:30 last night? You must have NO_CXX or something -- you aren't linking with the C++ support libs for some reason. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new zero copy sockets snapshot, WITNESS problems
1. sf_buf_init() calls kmem_alloc_pageable(), which through several calls ends up calling vm_map_entry_create(). vm_map_entry_create() calls uma_zalloc() with M_WAITOK. Alan Cox and Tor Egge just fixed this in -current in rev 1.247 of vm_map.c. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My postgresql7 not working for new gcc
--- David O'Brien [EMAIL PROTECTED] wrote:
*sigh*, why not a *real* fix?
--- configure.in.orig Thu Sep 27 01:03:56 2001
+++ configure.in Mon Apr 29 13:20:27 2002
@@ -200,7 +200,9 @@
done
if test $ac_found_openssl_lib_dir != no;
then
echo found in
$ac_found_openssl_lib_dir
- INCLUDES=-I$ac_found_openssl_inc_dir
$INCLUDES
+ if test $ac_found_openssl_inc_dir !=
/usr/include; then
+
INCLUDES=-I$ac_found_openssl_inc_dir
$INCLUDES
+ fi
DEFINES=-DOPENSSL $DEFINES
else
echo not found.
You'll note that they bother with this kind of check
for other headers,
but for some reason didn't consider it for openssl
headers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of
the message
Hi David,
Which version of postgresql that you are using? I have
cvsupped the postgresql7 ports and didn't find what
you referred here. However, I didn't manage to patch
configure not to include /usr/include based on
your advice. Here's the patch if anyone is interested.
Thanks
--- configure.orig Mon Mar 18 23:04:09 2002
+++ configure Mon Jun 10 18:06:57 2002
@@ -1697,7 +1697,9 @@
# SRCH_INC comes from the template file
for dir in $with_includes $SRCH_INC; do
if test -d $dir; then
-INCLUDES=$INCLUDES -I$dir
+if test $dir != /usr/include; then
+ INCLUDES=$INCLUDES -I$dir
+fi
else
echo configure: warning: *** Include directory
$dir does not exist. 12
fi
@@ -2008,7 +2010,9 @@
if test -d $krb4_prefix/include; then
-INCLUDES=$INCLUDES -I$krb4_prefix/include
+if test $krb4_prefix/include != /usr/include;
then
+ INCLUDES=$INCLUDES -I$krb4_prefix/include
+fi
fi
if test -d $krb4_prefix/lib; then
LIBDIRS=$LIBDIRS -L$krb4_prefix/lib
@@ -2053,7 +2057,9 @@
if test -d $krb5_prefix/include; then
-INCLUDES=$INCLUDES -I$krb5_prefix/include
+if test $krb5_prefix/include != /usr/include;
then
+ INCLUDES=$INCLUDES -I$krb5_prefix/include
+fi
fi
if test -d $krb5_prefix/lib; then
LIBDIRS=$LIBDIRS -L$krb5_prefix/lib
@@ -2158,7 +2164,9 @@
if test -d ${openssl_prefix}/include ; then
-INCLUDES=$INCLUDES -I${openssl_prefix}/include
+if test ${openssl_prefix}/include !=
/usr/include; then
+ INCLUDES=$INCLUDES
-I${openssl_prefix}/include
+fi
fi
if test -d ${openssl_prefix}/lib ; then
LIBDIRS=$LIBDIRS -L${openssl_prefix}/lib
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Kernel breakage in XE module
the HIDENAME() macro was changed to work with Gcc3.1 (the new compiler)
but broke it for the old compiler/assembler.
back out the definition in i386/include/asmacros.h to what it was before
(it used to use the CONCAT() macro)
OR
bite the bullet and upgrade to a new -current and get the new compiler.
On Mon, 10 Jun 2002, Troy wrote:
Been trying to buildkernel, and as of about 2 weeks ago something
happened to the XE module. Anyone have some ideas?
-Troy
=== xe
@ - /usr/src/sys
machine - /usr/src/sys/i386/include
awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h
awk -f @/tools/makeobjops.awk @/dev/pccard/card_if.m -h
awk -f @/tools/makeobjops.awk @/kern/device_if.m -h
rm -f .depend
CC='/usr/bin/cc' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I.
-I@ -I@/dev -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/mod
ules/xe/../../dev/xe/if_xe.c /usr/src/sys/modules/xe/../../dev/xe/if_xe_pccard.c
cd /usr/obj/usr/src/sys/SINDROME; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386
MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec GROFF_BIN_PATH=
/usr/obj/usr/src/i386/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386
INSTALL=sh /usr/src/tools/install.sh
PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/l
ibexec make KERNEL=kernel all
/usr/bin/cc -c -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winl
ine -Wcast-qual -Wno-format -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src
/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/us
r/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common
-mpreferred-stack-boundary=2 -ffreestanding /usr/src/sys/i386/i386/locore.s
{standard input}: Assembler messages:
{standard input}:1684: Warning: rest of line ignored; first ignored character is
`t'
{standard input}:1686: Error: unknown pseudo-op: `.'
{standard input}:1801: Error: missing ')'
{standard input}:1801: Error: missing ')'
{standard input}:1801: Error: junk `tmpstk)- 0xc000)' after expression
*** Error code 1
Stop in /usr/obj/usr/src/sys/SINDROME.
*** Error code 1
Stop in /usr/src.
*** Error code 1
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Kernel breakage in XE module
In the last episode (Jun 10), Troy said: Dan, Thanks for your response. I just built the gcc31 package, but it doesn't appear to replace the 2.95. Can you be a bit more specific on what I should do to upgrade the GCC in your last note. Basically, buildworld. If you're lucky, just building and installing /usr/src/gnu/usr.bin/cc might work. I guess another question would be should you be able to build a -current kernel with 2.95.3 anymore? It might make upgrades from 4.* a bit difficult. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mozilla 1.0 error
Hello, Kris Kennaway! On Fri, Jun 07, 2002 at 02:02:52PM -0700, you wrote: On Fri, Jun 07, 2002 at 04:56:45PM -0400, Joe Marcus Clarke wrote: On Fri, 2002-06-07 at 10:52, Jun Kuriyama wrote: At Fri, 7 Jun 2002 12:43:27 + (UTC), John Angelmo wrote: (cd /usr/ports/www/mozilla/work/mozilla/dist/bin; /usr/bin/env LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regxpcom; echo skin,install,select,classic/1.0 chrome/installed-chrome.txt; echo locale,install,select,en-US chrome/installed-chrome.txt; /usr/bin/env LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regchrome) [1] Segmentation fault (core dumped) *** Error code 139 Stop in /usr/ports/www/mozilla. I got same result, too. This problem seems to happen on -CURRENT and alpha -stable. And i386 -stable. Worked fine for me: [never@mile ~]$ cat /usr/ports/www/mozilla/Makefile | grep \$FreeBSD # $FreeBSD: ports/www/mozilla/Makefile,v 1.107 2002/06/06 18:52:31 sobomax Exp $ [never@mile ~]$ uname -a FreeBSD mile.nevermind.kiev.ua 4.6-RC FreeBSD 4.6-RC #0: Wed Jun 5 21:12:35 EEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/mile i386 [never@mile ~]$ gcc -v Using builtin specs. gcc version 2.95.3 20010315 (release) [FreeBSD] -- NEVE-RIPE Ukrainian FreeBSD User Group http://uafug.org.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GCC3.1 internal compiler error when compiling XFree86-4-libraries
On Mon, Jun 10, 2002 at 10:26:36AM -0700, David O'Brien wrote: On Mon, Jun 10, 2002 at 12:15:40PM -0500, Michael D. Harnois wrote: On Mon, 2002-06-10 at 12:13, David O'Brien wrote: On Mon, Jun 10, 2002 at 12:02:41PM -0500, Michael D. Harnois wrote: The libraries build for me without incident. However, anything which tries to link against libGLU generates this error for me: Your current is too old. Please do a fresh build. Since 6:30 last night? You must have NO_CXX or something -- you aren't linking with the C++ support libs for some reason. Sorry David, but I experienced the same thing. No matter if I used the base system c++ compiler, or the latest gcc31 port. The problem is all the more interesting, because X worked for me fine, no matter what compiler I used to build it (with a few patches from the XFree86-4-libraries port) and libGLU is the only part of XFree that is wirtten in C++. If I specify -lstdc++ on the link line of any programs that use libGLU, it works (see xc/programs/glxinfo). My -CURRENT is from Saturday (8th), NO_CXX is *not* set. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New ipfw code available
On Mon, 10 Jun 2002, Luigi Rizzo wrote:
On Mon, Jun 10, 2002 at 12:47:40PM +0400, Vladimir B. Grebenschikov wrote:
...
And what about radix-tree-based ip-list matching ?
yes, it is planned.
cheers
luigi
ipfw add 1 allow ip from {1.2.3.0/24,1.3.5.0/24,17.2.3.4/45,11.2.3.4/30}
or
cat mylist | ipfw list add mylist -
ipfw add 1 allow ip from @mylist
or something like
If you deal with large access-lists ipfw becomes not best tool due to
linear comparison.
Luigi, gave this a try, and dummynet and my current rulesets except for
one worked fine...
I tried to add a divert rule, and it kept telling me it was an invalid
port for divert/tee.
I went back to the original code... just because I happen to be using natd
:)
After this is fixed, I'll install again and play with the new features :)
-Trish
--
Trish Lynch [EMAIL PROTECTED]
FreeBSD The Power to Serve
Ecartis Core Team [EMAIL PROTECTED]
http://www.freebsd.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Device cloning
Hackers, The project i'm working on might require some sort of device cloning. The current way of cloning, i.e. use DEVFS and allocate unique minor numbers, is not very good for my purpose. The idea is simple: the same device(major,minor) can be opened several times by different processes (or possibly threads within the same process) and each process (thread) will have unique device instance. Device driver will create new instance, every time open() called. It will use D_TRACKCLOSE flag and destroy instances in close(). What kind of information should i store to identify each instance? Is/Will it be possible to identify a single thread within a process? Is there any problems with fork()? The support for the threads is optional. I can live with single instance per process. thanks, max __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
In message [EMAIL PROTECTED], Maksim Yevmenk in writes: Hackers, The project i'm working on might require some sort of device cloning. The current way of cloning, i.e. use DEVFS and allocate unique minor numbers, is not very good for my purpose. The idea is simple: the same device(major,minor) can be opened several times by different processes (or possibly threads within the same process) and each process (thread) will have unique device instance. Sorry, but this wont work for a large number of reasons. For one thing none of the dup(2) or fork(2) like systemcalls report what happens to the filedescriptors down to the device drivers so you have no way to correctly track which process or which instance you are working on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
÷ Tue, 11.06.2002, × 01:15, Poul-Henning Kamp ÎÁÐÉÓÁÌ: In message [EMAIL PROTECTED], Maksim Yevmenk in writes: Hackers, The project i'm working on might require some sort of device cloning. The current way of cloning, i.e. use DEVFS and allocate unique minor numbers, is not very good for my purpose. The idea is simple: the same device(major,minor) can be opened several times by different processes (or possibly threads within the same process) and each process (thread) will have unique device instance. Sorry, but this wont work for a large number of reasons. For one thing none of the dup(2) or fork(2) like systemcalls report what happens to the filedescriptors down to the device drivers so you have no way to correctly track which process or which instance you are working on. As far as I understand _key_ word is open, each new instance appears on open(), but fork() and dup() only do regular work. dup'ed or fork'ed descriptors will be same from driver's point of view, but each new open() will create new instance. Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
about beforeinstall target in /usr/share/mk/*.mk
Hi.
In /usr/share/mk/bsd.*.mk, 'beforeinstall' target execute after install
on current.
You found it to doing below in current:
% cd /usr/src/share/mk
% make install -n
install -c -o root -g wheel -m 444 bsd.README bsd.cpu.mk bsd.dep.mk bsd.doc.mk
bsd.files.mk bsd.info.mk bsd.incs.mk bsd.init.mk bsd.kern.mk bsd.kmod.mk bsd.lib.mk
bsd.libnames.mk bsd.man.mk bsd.nls.mk bsd.obj.mk bsd.own.mk bsd.port.mk
bsd.port.post.mk bsd.port.pre.mk bsd.port.subdir.mk bsd.prog.mk bsd.subdir.mk
bsd.sys.mk sys.mk /usr/share/mk
date '+%Y%m%d' /var/db/port.mkversion
%
but, in makefile,
beforeinstall:
date '+%Y%m%d' ${DESTDIR}/var/db/port.mkversion
beforeinstall target execute after install.
### I found it at installing portupgrade from ports. :-)
--
[EMAIL PROTECTED][EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: My postgresql7 not working for new gcc
David O'Brien wrote: *sigh*, why not a *real* fix? Feel free to submit this to the Postgres project... they may even incorporate it. You'll note that they bother with this kind of check for other headers, but for some reason didn't consider it for openssl headers. Mostly the reason that this fix was not being bandied about is that the Postgres source code is largely under third party control. If the change can be made to the Makefile, etc., which is under direct control of FreeBSD, then the code will compile unmodified. That means if there are future changes, we won't end up with a local patch to third party code, which doesn't apply cleanly. Locally maintaining patches against large projects is a very big headache; in fact, this headache is one of the primary things people rely upon in order to ensure that people donate tactical fixes back to the FreeBSD project itself. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld problem
how do I resolve this? === gnu/usr.bin/groff/src/libs/libgroff c++ -O -pipe -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../src/include -D__FBSDID=__RCSID -fno-rtti -fno-exceptions -c /usr/src/contrib/groff/src/libs/libgroff/assert.cc -o assert.o ld: unrecognized option `-o' Use `ld --help' for a complete list of options. *** Error code 1 Stop in /usr/src/gnu/usr.bin/groff/src/libs/libgroff. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Device cloning
Vladimir B. Grebenschikov wrote: As far as I understand _key_ word is open, each new instance appears on open(), but fork() and dup() only do regular work. dup'ed or fork'ed descriptors will be same from driver's point of view, but each new open() will create new instance. No. The problem is that if you open the same thing N times, you will get N references to the single vnode of the thing. For devices, it's possible to kludge this, so that the device gives you a different vnode for each instance; however, the close is not sufficiently tracked unless you also give back a different minor number for each open instance. The problem is that there is no per reference instance information that is stored with the vnode and given to the device, as a context, with each operation, other tha the device context itself. So the only way to do this is a different minor number, so that the device is capable of maintaining its own per open instance information. It's also really questionable what the correct course of action for the fork/dup/dup2 code is. Consider the case of a program that intentionally forks, so that one process can read from the /etc/tty and write to the device, while the other can do the opposite (this is how the original cu program worked). On top of this, add descriptor passing. This breaks down to: are you creating a new open instance, or are you manipulating a reference to an existing open instance? Pushing this information over the struct fileops barrier is not a very easy thing to do. It would require reorganization of a lot of code. While this code is in *dire* need of reorganization, when you are done, if you can't answer the question about whether you are doing a dup or passing a reference to a single instance when you pass an FD between processes... well... you're in a bit of a jam. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My postgresql7 not working for new gcc
Shizuka Kudo wrote: --- David O'Brien [EMAIL PROTECTED] wrote: *sigh*, why not a *real* fix? [ ... ] Which version of postgresql that you are using? I have cvsupped the postgresql7 ports and didn't find what you referred here. However, I didn't manage to patch configure not to include /usr/include based on your advice. Here's the patch if anyone is interested. David's fix is more correct. The configure program you are patching is actually created from the configure.in file that David was patching. Since it's machine generated, it's a bad idea to patch it directly. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My postgresql7 not working for new gcc
--- Terry Lambert [EMAIL PROTECTED] wrote: Shizuka Kudo wrote: --- David O'Brien [EMAIL PROTECTED] wrote: *sigh*, why not a *real* fix? [ ... ] Which version of postgresql that you are using? I have cvsupped the postgresql7 ports and didn't find what you referred here. However, I didn't manage to patch configure not to include /usr/include based on your advice. Here's the patch if anyone is interested. David's fix is more correct. The configure program you are patching is actually created from the configure.in file that David was patching. Since it's machine generated, it's a bad idea to patch it directly. -- Terry I don't think autoconf was called in postgresql7 port, and patching configure is necessary. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: one or two errors in installworld
In message [EMAIL PROTECTED], Steve Kargl wr ites: If you don't think it's bogus, then fix the documentation of make.conf and commit an UPDATING entry to warn everyone who set INSTALL several years ago. Check out the next to last few entries in: http://www.freebsd.org/cgi/cvsweb.cgi/src/share/sendmail/Makefile?sortby=log or http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/xinstall/xinstall.c So, on to a new topic. Which is better, ^? or ^H ? Andrew Lankford To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My postgresql7 not working for new gcc
Shizuka Kudo wrote: I don't think autoconf was called in postgresql7 port, and patching configure is necessary. It's derived data, and the patches will likely not remain valid after the next release/upgrade. That basically means that the way to correct your complaint about autoconf not being run is to make the port Makefile run autoconf. A patch to a derived file is not one that will make it back into the project source tree. If the patch isn't one that the Postgres people will accept, it's probably a bad patch. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel breakage in XE module
On Mon, 10 Jun 2002, Julian Elischer wrote: the HIDENAME() macro was changed to work with Gcc3.1 (the new compiler) but broke it for the old compiler/assembler. Ugh. I was surprised that this change worked for any gcc. The change is from: #define HIDENAME(asmsym)__CONCAT(.,asmsym) to: #define HIDENAME(asmsym).asmsym Note that the change isn't for use of CONCAT with , and word lke its commit message says. It is for use of __CONCAT with . and word. Here the quotes are to mark up identifiers -- there are no strings involved. The problem is that the ISO C concatenation operator ## is less useful than might first appear. It is only required to work if the result could be a preprocessing token, and the rules for when the result could be a preprocessing token are quite complicated. E.g., .foo is not a preprocessing token but .1 is. The result of concatenating . with foo is undefined, and gcc now detects this error. Since .foo is lexed as separate tokens, there is no need for the preprocessor to keep the . and the foo separate. In practice, previous versions of the preprocessor inserted a space between the tokens and the current version doesn't. The current HIDENAME() macro depends on this implementation detail in the current preprocessor and is just broken in general. back out the definition in i386/include/asmacros.h to what it was before (it used to use the CONCAT() macro) OR bite the bullet and upgrade to a new -current and get the new compiler. OR for a quick fix, fixing one of the following related bogons: (1) For non-profiling kernels, HIDENAME is only used for the tmpstk variable in locore.s, but there is no need for this variable to be hidden. Hiding it mainly broke examining it using ddb before ddb was fixed to recognize symbols with a . in their name. (2) For non-profiling kernels, HIDENAME is only used for the tmpstk variable in locore.s, but the old macro still works for cpp'ing assembler sources. This is why committing gcc-3 didn't break building of all kernels. Fixing the following related bogon would have no significant affect: (3) HIDENAME still has its old definition in at least the i386 machine/asm.h. This is harmless at least on i386's because that definition is not actually used. This leaves the problem of fixing the use of HIDENAME in profiling kernels. Unfortunately, the standard name for mcount requires a . in it for the ELF case (the ELF case is more broken than the aout case here). This problem is avoided for userland profiling using a magic asm in machine/profile.h. The i386 prof_machdep.c uses HIDENAME to get slightly less magic asm. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: one or two errors in installworld
On Tue, Jun 11, 2002 at 12:09:23AM -0400, Andrew Lankford wrote: In message [EMAIL PROTECTED], Steve Kargl wr ites: If you don't think it's bogus, then fix the documentation of make.conf and commit an UPDATING entry to warn everyone who set INSTALL several years ago. Check out the next to last few entries in: http://www.freebsd.org/cgi/cvsweb.cgi/src/share/sendmail/Makefile?sortby=log or http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/xinstall/xinstall.c So, on to a new topic. Which is better, ^? or ^H ? What's your point? Greg kludged share/sendmail/Makefile to work around Ruslan's broken implementation in xinstall. Either fix xinstall so options that conflict with -d are ignored (I've already posted a patch, twice), or fix the documentation of make.conf (I've already posted a patch for this, too) and fix the example make.conf under share/example/etc and add an entry to UPDATING. There is also an open problem report bin/37795, which Ruslan knew existed, and he has not closed it (his kludge invalidates the PR). At one time, setting INSTALL to install -C in make.conf could be a BIG time saver during a make world? One can no longer set INSTALL. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
