Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Wed, Aug 15, 2001 at 12:40:19PM +1000, Bruce Evans wrote:
[...]
> > > +mkmagic: apprentice.c print-hacked.c
> > > + ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > > + -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
> > >
> > Whoa, cool!
> >
> > That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
> > It then fits just nicely into the `build-tools' concept. And we
> > don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
> > set correctly during the `build-tools' stage. Let's don't reinvent
> > the wheel, and please try the attached patch instead.
>
> I agree (except the build-tools concept is a hack to work around
> build-tools binaries not being buildable and installable in the usual
> way (with 1 binary per Makefile)).
>
It seems pretty easy to add src/tools/build-tools/, and move all the
build-tools there. What do you say?
[...]
> See sh/Makefile for other tweaks (depend on .o instead of .c ...). Other
> probems with this (generally shared with all build-tools binaries):
> - CFLAGS for the main binary may be inappropriate for the tools
> - missing dependencies on headers.
>
Dependency of a build-tool on .o instead of .c is bad if:
1) build-tools are built in the same ${.OBJDIR} as the main ${PROG}
(this is always true)
2) objects for a build-tool are created for the host arch
3) objects for a ${PROG} are created for a different arch
4) ${PROG} and build-tool share one or more object files
This is not the case for bin/sh, but it's true for usr.bin/file.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: devfs and Vinum (was: any -current && vinum problems?)
In message <[EMAIL PROTECTED]>, Greg Lehey writes: >> I'm working on the 16char limit problem as well, but I want to avoid >> allocating memory in incovenient circumstances if at all possible. > >The problem is that I kept having problems with the devfs/vinum >combination even after increasing the size to 96 characters. As I >said to you on IRC quite some time ago now: Yeah, I remember you saying that, and that has made me even more cautious because the only explanation I could find would be stack overruns or places which knew about the "16". But trust me, you are on my list of things to do, but I'm still trying to get rid of my contractors and getting things into a general shape where I will have some spare time again... -- 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: devfs and Vinum (was: any -current && vinum problems?)
On Wednesday, 15 August 2001 at 7:16:02 +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Andrew Kenneth Milton
> writes:
>> +---[ Greg Lehey ]--
>>>
>>
>> [snip]
>>
>>> whether it's been fixed. Basically, devfs as supplied in CURRENT had
>>> a 16 character limit on device names, and it didn't understand
>>> subdirectories: it treated the / as a part of the device name.
>>
>> The subdir part bit me about a week ago, so I'd say it's still not fixed.
>
> This is absolutely news to me.
Thinking about it, it is to me too. I noticed that devfs doesn't
create directory nodes when I was trying to find ways to delete
existing directory entries, but that's the only problem I've had with
it. I mentioned it here because it related to the name length limit:
the length of the name includes the complete path from the mount
point.
> More details on this bug are most welcome.
>
> I'm working on the 16char limit problem as well, but I want to avoid
> allocating memory in incovenient circumstances if at all possible.
The problem is that I kept having problems with the devfs/vinum
combination even after increasing the size to 96 characters. As I
said to you on IRC quite some time ago now:
phk: I've been getting a lot of panics out of zaphod.
phk: I suspect a bogon or misunderstandingn with Vinum and devfs.
groggy: any clues/traces/pointers ?
wli: you're not a member of the club.
phk: I'm just guessing that it's a name length problem.
phk: Hmm. Could be due to incorrect header files somewhere.
phk: I upped the name length to 96 chars.
phk: Traceback:
1 0xc01b88c4 in panic (fmt=0xc034ce38 "getnewvnode: free vnode isn't") at
../../kern/kern_shutdown.c:598
#2 0xc01fb30e in getnewvnode (tag=VT_UFS, mp=0xc230d400, vops=0xc22c4600,
vpp=0xcfcdec10) at ../../kern/vfs_subr.c:552
#3 0xc02c33aa in ffs_vget (mp=0xc230d400, ino=0x12099, vpp=0xcfcdec60) at
../../ufs/ffs/ffs_vfsops.c:1157
#4 0xc02b409d in ffs_valloc (pvp=0xcfc9b920, mode=0x81a4, cred=0xc252db00,
vpp=0xcfcdec60)
at ../../ufs/ffs/ffs_alloc.c:615
#5 0xc02cc670 in ufs_makeinode (mode=0x81a4, dvp=0xcfc9b920, vpp=0xcfcdeea4,
cnp=0xcfcdeeb8)
at ../../ufs/ufs/ufs_vnops.c:2215
#6 0xc02c9c14 in ufs_create (ap=0xcfcdedbc) at ../../ufs/ufs/ufs_vnops.c:194
#7 0xc02ccb39 in ufs_vnoperate (ap=0xcfcdedbc) at
../../ufs/ufs/ufs_vnops.c:2587
#8 0xc02068a9 in vn_open (ndp=0xcfcdee90, flagp=0xcfcdee5c, cmode=0x1a4) at
vnode_if.h:90
#9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at
../../kern/vfs_syscalls.c:1077
#10 0xc0312445 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f,
tf_edi = 0xbfbff9b8, tf_esi = 0x8,
tf_ebp = 0xbfbff820, tf_isp = 0xcfcdefd4, tf_ebx = 0x80b54a0, tf_edx =
0x80b5b80, tf_ecx = 0x10, tf_eax = 0x5,
tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x8091fec, tf_cs = 0x1f,
tf_eflags = 0x293, tf_esp = 0xbfbff7f4,
tf_ss = 0x2f}) at ../../i386/i386/trap.c:1176
phk: I'm wondering whether to analyse, reboot and upgrade, or ignore for the
moment.
groggy doesn't really point to either of vinum or DEVFS if you ask me...
(kgdb) f 9
#9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at
../../kern/vfs_syscalls.c:1077
warning: Source file is more recent than executable.
1077error = vn_open(&nd, &flags, cmode);
(kgdb) p *uap
$1 = {
path = 0x80c4030 "lib/username.o",
path_ = 0xcfcdef84 "\001\006",
flags = 0x601,
flags_ = 0xcfcdef88 "¶\001",
mode = 0x1b6,
mode_ = 0xcfcdef8c "¸ù¿¿\006"
}
phk: Not directly. I'm suspecting some kind of corruption.
phk: But nobody else has mentioned it, and there must be some reason why it
keeps happening.
phk: The trouble is, I use this box for two different purposes;
phk: 1: Testing Vinum.
phk: 1: Testing Samba.
* groggy points at http://build.samba.org/
s/1/2/
phk: This only started happening since I installed devfs, and I think it only
happens if Vinum is loaded.
groggy: well, as far as I know we still havn't conclusive evidence that
vinum+DEVFS does the right thing, do we ?
phk: Exactly.
phk: I was just waiting for you to say "hey, that sounds familiar".
groggy I'm sorry I havn't gotten further on the long-names for devices, but life
has kind of kept me busy this week, starting with a leaky water pipe last sunday...
phk: No worries. I'll keep looking, maybe.
Sorry I can't give you a date on this, but I'm sure you remember.
Maybe the leaky water pipe will put a date on it :-)
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: devfs and Vinum (was: any -current && vinum problems?)
In message <[EMAIL PROTECTED]>, Andrew Kenneth Milton writes: >+---[ Greg Lehey ]-- >| > >[snip] > >| whether it's been fixed. Basically, devfs as supplied in CURRENT had >| a 16 character limit on device names, and it didn't understand >| subdirectories: it treated the / as a part of the device name. > >The subdir part bit me about a week ago, so I'd say it's still not fixed. This is absolutely news to me. I'm pretty sure that you will find that /dev/fd[012] exists on your system and that it was created using '/' in make_dev calls... More details on this bug are most welcome. I'm working on the 16char limit problem as well, but I want to avoid allocating memory in incovenient circumstances if at all possible. -- 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: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, 14 Aug 2001, David O'Brien wrote:
> On Tue, Aug 14, 2001 at 08:30:45PM +0300, Ruslan Ermilov wrote:
>
> > The build in ${DESTDIR} is allowed, we, for
> > example, execute makewhatis(1) at the end of `installworld'. But this
> > "build" is implicit, i.e., it's not done by make dependencies.
>
> What is wrong with doing the .mgc creation during make install?
1. May have cross building problems. Installing on the host should work
someday.
2. Doesn't work as well as install(1) unless we add most of install(1)'s
features to the creation program.
> The
> behavior of ``file -C'' is to write the .mgc in the same directory as the
> source file. That behavior does not make me happy, and is the source of
> the use of "magic.mime.PITA".
It takes 23 lines just to append ".mgc" to the source file name. This
misfeature could be left out for the COMPILE_ONLY case.
> > That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
> > It then fits just nicely into the `build-tools' concept. And we
> > don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
> > set correctly during the `build-tools' stage.
>
> I personally often find `build-tools' a hack, and would really prefer to
> build things that can be at program compile time.
The correct way is to build the tools earlier, in one directory for each
tool so that the standard rules work right and different compilation
environments can easily be arranged. This would be easy to implement
for file(1) since there is only one tool.
> > Let's don't reinvent the wheel, and please try the attached patch
> > instead.
>
> I don't see why HOST_CC is such a hack. I think it is more clear what is
> going on than adding mkmagic to build-tools.
It essentially hard-codes a special case of TMAKE/TMAKEENV. It is
superficially easier to understand, but actually much more complicated.
TMAKEENV gives a relatively simple host environment, with things like
COMPILER_PATH unset. When you build mkmagic later, the more complicated
WMAKEENV environment is in effect, and you need to kill parts of it
to get back to TMAKEENV. This is not easy. HOST_CC only sets a couple
of parts IIRC, and doesn't do this quite right (it should unset
COMPILER_PATH instead of setting it ...).
> > RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
> ...
> > +build-tools: mkmagic
> > +
> > +mkmagic: apprentice.c print-hacked.c
> > + ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > + -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
>
> Why shouldn't mkmagic be added to CLEANFILES?
It is (just in a different place?).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, 14 Aug 2001, Ruslan Ermilov wrote:
> On Tue, Aug 14, 2001 at 08:55:56AM -0700, David O'Brien wrote:
> > >From a correctness stand point, building the .mgc files at install time
> > is the correct thing to do... or maybe we should do both -- doing the
> > [re]creation of the .mgc files at install time in the cross-[arch-]build
> > case.
Not both.
> > +mkmagic: apprentice.c print-hacked.c
> > + ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > + -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
> >
> Whoa, cool!
>
> That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
> It then fits just nicely into the `build-tools' concept. And we
> don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
> set correctly during the `build-tools' stage. Let's don't reinvent
> the wheel, and please try the attached patch instead.
I agree (except the build-tools concept is a hack to work around
build-tools binaries not being buildable and installable in the usual
way (with 1 binary per Makefile)).
> Index: usr.bin/file/Makefile
> ===
> RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
> retrieving revision 1.21
> diff -u -r1.21 Makefile
> --- usr.bin/file/Makefile 2001/08/08 16:19:30 1.21
> +++ usr.bin/file/Makefile 2001/08/14 17:30:11
> @@ -34,23 +34,29 @@
> CFLAGS+= -DMAGIC='"${MAGICPATH}/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H
> CFLAGS+= -I${.CURDIR} -I${SRCDIR}
>
> -CLEANFILES+= magic magic.mgc magic.mime.mgc magic.mime.PITA
> +CLEANFILES+= mkmagic magic magic.mgc magic.mime.mgc magic.mime.PITA
CLEANFILES= magic magic.mgc magic.mime.mgc magic.mime.PITA mkmagic
(This fixes disorder and the usual style bug for the initial assignment
to CLEANFILES.)
>
> MAGFILES=${SRCDIR}/Header\
> ${SRCDIR}/Localstuff\
> ${SRCDIR}/Magdir/[a-z]*
>
> -all: file magic magic.mgc magic.mime.mgc
> +all: ${PROG} magic magic.mgc magic.mime.mgc
all: magic magic.mgc magic.mime.mgc
(Don't depend on `file' twice. Putting it first may have been a workaround
for broken dependencies in an old version of the Makefile.)
> +build-tools: mkmagic
> +
> +mkmagic: apprentice.c print-hacked.c
> + ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> + -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
This should use CFLAGS if possible, and should use LDFLAGS, something
like:
${CC} -DCOMPILE_ONLY {CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.ALLSRC}
See sh/Makefile for other tweaks (depend on .o instead of .c ...). Other
probems with this (generally shared with all build-tools binaries):
- CFLAGS for the main binary may be inappropriate for the tools
- missing dependencies on headers.
> +
> magic: ${MAGFILES}
> cat ${.ALLSRC} > ${.TARGET}
>
> -magic.mgc: file magic
> - ./${PROG} -C -m magic
> +magic.mgc: mkmagic magic
> + ./mkmagic magic
>
> -magic.mime.mgc: file magic.mime
> +magic.mime.mgc: mkmagic magic.mime
> ln -sf ${SRCDIR}/magic.mime magic.mime.PITA
> - ./${PROG} -C -m magic.mime.PITA
> + ./mkmagic magic.mime.PITA
> mv magic.mime.PITA.mgc magic.mime.mgc
>
> CLEANFILES+= print-hacked.c
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, Aug 14, 2001 at 08:30:45PM +0300, Ruslan Ermilov wrote:
> Just to clarify. Nothing should be built in ${.OBJDIR} at install time,
> as it may be read-only.
Correct.
> The build in ${DESTDIR} is allowed, we, for
> example, execute makewhatis(1) at the end of `installworld'. But this
> "build" is implicit, i.e., it's not done by make dependencies.
What is wrong with doing the .mgc creation during make install? The
behavior of ``file -C'' is to write the .mgc in the same directory as the
source file. That behavior does not make me happy, and is the source of
the use of "magic.mime.PITA".
> And
> also note that only bootstrap-tools and utilities copied to the
> ${TMPPATH} as the first step of `installworld' are allowed during
> `installworld'.
>
> > +mkmagic: apprentice.c print-hacked.c
> > + ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > + -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
> >
> Whoa, cool!
>
> That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
> It then fits just nicely into the `build-tools' concept. And we
> don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
> set correctly during the `build-tools' stage.
I personally often find `build-tools' a hack, and would really prefer to
build things that can be at program compile time.
> Let's don't reinvent the wheel, and please try the attached patch
> instead.
I don't see why HOST_CC is such a hack. I think it is more clear what is
going on than adding mkmagic to build-tools.
> RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
...
> +build-tools: mkmagic
> +
> +mkmagic: apprentice.c print-hacked.c
> + ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> + -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
Why shouldn't mkmagic be added to CLEANFILES?
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: devfs and Vinum (was: any -current && vinum problems?)
+---[ Greg Lehey ]-- | [snip] | whether it's been fixed. Basically, devfs as supplied in CURRENT had | a 16 character limit on device names, and it didn't understand | subdirectories: it treated the / as a part of the device name. The subdir part bit me about a week ago, so I'd say it's still not fixed. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
devfs and Vinum (was: any -current && vinum problems?)
On Tuesday, 14 August 2001 at 19:26:09 -0400, Michael Lucas wrote: > Before I start generating crash dumps & etc., are there any gotchas > with Vinum & -current? I'm using devfs on a SMP system, upgraded 3 > days ago. I get a panic whenever I stripe something. Ah, now you say devfs. There was a bug in devfs; I haven't checked whether it's been fixed. Basically, devfs as supplied in CURRENT had a 16 character limit on device names, and it didn't understand subdirectories: it treated the / as a part of the device name. Vinum device names can be much longer than 16 characters, so I changed the limit to 96 characters on my test machine, but wasn't able to get it to run reliably. I've told phk about this on IRC some months ago, but I haven't seen a commit fixing the problem. I could have missed something, of course. To help localize this problem, could you please try this same thing on a kernel without devfs? The dump you sent me did not look like a Vinum bug, as I said in my reply. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
any -current && vinum problems?
Before I start generating crash dumps & etc., are there any gotchas with Vinum & -current? I'm using devfs on a SMP system, upgraded 3 days ago. I get a panic whenever I stripe something. Thanks, Michael -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Last Words...(documentation)
Joe Kelsey wrote: > However, I have one last comment to make. TWO people have written to me > and said that the reason THEY write documentation in their "day" jobs is > that they get PAID for it. So, excuse me! I guess real programmers > only write documentation when they are PAID! Obviously, working on a > FREE product, you don't get paid so you don't document! After all, the > meaning is obvious from the code! There are tons of productization issues surrounding Open Source projects which involve work that peole will only do if the get PAID to do it. One of these, historically, has been the install process, and another the release engineering process (Jordan was PAID by Walnut Creek to do it, then was PAID by BSDI to do it, abd ...). The real question you need to answer is "what needs to be done to incentivize commercial organizations to PAY for the work to be done?". For documentation, I have suggested that FreeBSD find some way to leverage the situation where students are being PAID with their grades to do technical writing. For installation, I've suggested that sysintall not be the first user experience (and it seems that this has met with lukewarm, but not cold, reception the last time it was raised), to permit a company to be PAID for its distribution on the basis of it being a better first experience for the user. Likewise, Bill Paul is PAID to write network drivers, and many of us are PAID, one way or the other, to hack on the code that the ones PAYING us want hacked on... Note that this is not limited to commercial organizations: DARPA is currently PAYING to improve FreeBSD security... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: driver writing newbie
Thus spake Kenneth Wayne Culver ([EMAIL PROTECTED]): > SYS_RES_MEMORY instead of SYS_RES_IOPORT (all these combinations are for > use in bus_alloc_resource). The thing is everything I've tried fails to > work, so I can't attach my driver because it won't map the resources. > Can anyone suggest other things I could try to make this work right? Source? Alex -- WELCOME DATACOMP! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bash in /usr/local/bin?
David O'Brien writes: | On Tue, Aug 14, 2001 at 01:23:40PM +0200, Johann Visagie wrote: | > if ( "$tty" != "" ) then | > | > (There may be a more elegant way to check for shell interactivity in csh, and | > if there is I'd like to know about it, please. :-) | | I've used "if ($?USER == 0 || $?prompt == 0)" in the past. I've used 'tty' to tell me for more info 'man tty'. a21p% echo hello | tty && echo hi not a tty a21p% tty && echo hi /dev/ttypg hi a21p% Don't know if this has been mentioned since I generally ignore things about bash. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, Aug 14, 2001 at 08:55:56AM -0700, David O'Brien wrote:
> On Tue, Aug 14, 2001 at 09:54:04AM +0300, Ruslan Ermilov wrote:
> > > They produce the same output, but in the general case they do not need
> > > to.
> >
> > What I hear? Hell, then my solution (or something similar) should be
> > committed, as it at least unbreaks the 4.x -> 5.0 upgrade path, which
> > I am mostly concerned about (on the same arch).
>
> I never said they weren't the same format nor that it wouldn't be fixed.
> I said I wanted to try some things. NetBSD something simular to the
> patch below in their usr.bin/file/Makefile -- they build the .mgc files
> during build time. The patch to src/Makefile.inc is one way to implement
> the needed hooks.
>
Good.
> >From a correctness stand point, building the .mgc files at install time
> is the correct thing to do... or maybe we should do both -- doing the
> [re]creation of the .mgc files at install time in the cross-[arch-]build
> case.
>
Just to clarify. Nothing should be built in ${.OBJDIR} at install time,
as it may be read-only. The build in ${DESTDIR} is allowed, we, for
example, execute makewhatis(1) at the end of `installworld'. But this
"build" is implicit, i.e., it's not done by make dependencies. And
also note that only bootstrap-tools and utilities copied to the
${TMPPATH} as the first step of `installworld' are allowed during
`installworld'.
> +mkmagic: apprentice.c print-hacked.c
> + ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> + -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
>
Whoa, cool!
That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
It then fits just nicely into the `build-tools' concept. And we
don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
set correctly during the `build-tools' stage. Let's don't reinvent
the wheel, and please try the attached patch instead.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.208
diff -u -r1.208 Makefile.inc1
--- Makefile.inc1 2001/08/04 18:25:38 1.208
+++ Makefile.inc1 2001/08/14 17:30:11
@@ -600,7 +600,8 @@
build-tools:
.for _tool in bin/csh bin/sh ${_games} gnu/usr.bin/cc/cc_tools ${_fortran} \
-${_libroken4} ${_libkrb5} lib/libncurses ${_share} usr.sbin/sysinstall
+${_libroken4} ${_libkrb5} lib/libncurses ${_share} usr.bin/file \
+usr.sbin/sysinstall
cd ${.CURDIR}/${_tool}; ${MAKE} build-tools
.endfor
Index: usr.bin/file/Makefile
===
RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- usr.bin/file/Makefile 2001/08/08 16:19:30 1.21
+++ usr.bin/file/Makefile 2001/08/14 17:30:11
@@ -34,23 +34,29 @@
CFLAGS+= -DMAGIC='"${MAGICPATH}/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H
CFLAGS+= -I${.CURDIR} -I${SRCDIR}
-CLEANFILES+= magic magic.mgc magic.mime.mgc magic.mime.PITA
+CLEANFILES+= mkmagic magic magic.mgc magic.mime.mgc magic.mime.PITA
MAGFILES= ${SRCDIR}/Header\
${SRCDIR}/Localstuff\
${SRCDIR}/Magdir/[a-z]*
-all: file magic magic.mgc magic.mime.mgc
+all: ${PROG} magic magic.mgc magic.mime.mgc
+build-tools: mkmagic
+
+mkmagic: apprentice.c print-hacked.c
+ ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
+ -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
+
magic: ${MAGFILES}
cat ${.ALLSRC} > ${.TARGET}
-magic.mgc: file magic
- ./${PROG} -C -m magic
+magic.mgc: mkmagic magic
+ ./mkmagic magic
-magic.mime.mgc: file magic.mime
+magic.mime.mgc: mkmagic magic.mime
ln -sf ${SRCDIR}/magic.mime magic.mime.PITA
- ./${PROG} -C -m magic.mime.PITA
+ ./mkmagic magic.mime.PITA
mv magic.mime.PITA.mgc magic.mime.mgc
CLEANFILES+= print-hacked.c
Re: bash in /usr/local/bin?
At 1:23 PM +0200 8/14/01, Johann Visagie wrote: >You may also want to restrict it so that only interactive login sessions >cause bash to be invoked. To summarise: > > if ( "$tty" != "" ) then > if ( -x /usr/local/bin/bash ) then > setenv SHELL /usr/local/bin/bash > exec /usr/local/bin/bash -login > endif > endif > >(There may be a more elegant way to check for shell interactivity in csh, >and if there is I'd like to know about it, please. :-) If you check in the standard (default) .cshrc, it has the lines: if ($?prompt) then # An interactive shell -- set some stuff up set filec set history = 100 set savehist = 100 set mail = (/var/mail/$USER) endif So I suspect that's the check I should use in .login -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bash in /usr/local/bin?
On Tue, Aug 14, 2001 at 01:23:40PM +0200, Johann Visagie wrote: > if ( "$tty" != "" ) then > > (There may be a more elegant way to check for shell interactivity in csh, and > if there is I'd like to know about it, please. :-) I've used "if ($?USER == 0 || $?prompt == 0)" in the past. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD's aggressive keyboard probe/attach
On Mon, 13 Aug 2001, Terry Lambert wrote: > Chris Dillon wrote: > > Occasionally I'll have mouse sync problems when I switch between > > FreeBSD and NT when the NT box has had difference mice (wheel vs. > > non-wheel MS mice, apparently) used on it via the dual-user KVM > > switch. NT seems to handle that case fairly well by resetting the > > PS/2 port and/or the mouse (not sure which) and redetecting the mouse > > type. > > There is actually a Cybex-specific "Microsoft Knowledge Base" > article which discusses the registry setting you need to pound > on to make NT not attempt to detect the mouse wheel (FWIW). I've found it. This will apply to any case where you would want to disable the wheel mouse detection in NT. For archive purposes, here it is: http://support.microsoft.com/support/kb/articles/Q165/3/25.ASP > > FreeBSD doesn't like when NT has done that to the mouse, > > though, and spews sync errors when I switch back. Usually I can kill > > moused and restart it to fix the problem. > > The 0x8000 flag fixes exactly this problem! I see that this flag exists in -STABLE but is undocumented as of yet. I'll give it a try. Luckily this problem is not too common since I rarely use the second user on the other KVM switch. [...snip...] > > Hmm... I'll have to check, maybe thats why mine works. :-) > > Little square sticker with rounded corners on the bottom, about > 1/2" by 1/4", with just the version, e.g. "1.9"... The 4-port OmniCube on my desk only has version 1.5, but that probably doesn't matter (how would I upgrade it? I have a ROM burner). I can't find the firmware version on my OmniView Matrix. The only caveat with these two KVM switches hooked together is that it is a real PITA when I hit Scroll Lock twice to change consoles on the remote KVM that sometimes the local KVM will see the same sequence and think I want to change consoles on it instead. I wish there were a way to disable the keyboard shortcuts on the OmniCube and just use the front-panel button. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64 (Itanium), PowerPC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, Aug 14, 2001 at 09:54:04AM +0300, Ruslan Ermilov wrote:
> > They produce the same output, but in the general case they do not need
> > to.
>
> What I hear? Hell, then my solution (or something similar) should be
> committed, as it at least unbreaks the 4.x -> 5.0 upgrade path, which
> I am mostly concerned about (on the same arch).
I never said they weren't the same format nor that it wouldn't be fixed.
I said I wanted to try some things. NetBSD something simular to the
patch below in their usr.bin/file/Makefile -- they build the .mgc files
during build time. The patch to src/Makefile.inc is one way to implement
the needed hooks.
>From a correctness stand point, building the .mgc files at install time
is the correct thing to do... or maybe we should do both -- doing the
[re]creation of the .mgc files at install time in the cross-[arch-]build
case.
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.208
diff -u -r1.208 Makefile.inc1
--- Makefile.inc1 2001/08/04 18:25:38 1.208
+++ Makefile.inc1 2001/08/13 23:42:09
@@ -199,6 +199,7 @@
WMAKEENV= ${CROSSENV} \
DESTDIR=${WORLDTMP} \
INSTALL="sh ${.CURDIR}/tools/install.sh" \
+ HOST_CC='env COMPILER_PATH=/usr/libexec:/usr/bin LIBRARY_PATH=/usr/lib
+/usr/bin/cc' \
PATH=${TMPPATH}
WMAKE= ${WMAKEENV} ${MAKE} -f Makefile.inc1
Index: usr.bin/file/Makefile
===
RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- usr.bin/file/Makefile 2001/08/08 16:19:30 1.21
+++ usr.bin/file/Makefile 2001/08/14 15:53:21
@@ -45,13 +45,18 @@
magic: ${MAGFILES}
cat ${.ALLSRC} > ${.TARGET}
-magic.mgc: file magic
- ./${PROG} -C -m magic
+magic.mgc: mkmagic magic
+ ./mkmagic magic
-magic.mime.mgc: file magic.mime
+magic.mime.mgc: mkmagic magic.mime
ln -sf ${SRCDIR}/magic.mime magic.mime.PITA
- ./${PROG} -C -m magic.mime.PITA
+ ./mkmagic magic.mime.PITA
mv magic.mime.PITA.mgc magic.mime.mgc
+
+CLEANFILES+= mkmagic
+mkmagic: apprentice.c print-hacked.c
+ ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
+ -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
CLEANFILES+= print-hacked.c
print-hacked.c: print.c
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: bash in /usr/local/bin?
Terry Lambert on 2001-08-11 (Sat) at 12:47:01 -0700: > > Garance A Drosihn wrote: > > > > As to Jason's situation, I also like to use bash as my shell > > even when I am root. However, I do not want to muck around with > > the port for 'bash', or do anything else to move where bash is > > or how it's built. So, the way I decided to handle it was to > > add the following lines in the /root/.login file: > > > > if ( -x /usr/local/bin/bash ) then > > # echo "Switching to bash" > > exec /usr/local/bin/bash -login > > endif > > > > So, strictly speaking /bin/csh is still the default shell for > > root, but the effect for me is that I automatically get bash > > whenever I log in. This seems to work fine for me, and I am > > not aware of any problems which have been caused by this trick > > in the few years that I have been using it. > > Add "setenv SHELL /usr/local/bin/bash", and only do your trick > in the initial interactive login shell, and your logins will > be faster, and you will get the "right" (for those definitions > of "right" which include intentional use of "bash" 8-)) shell > when you shell out of "vi" or other programs. You may also want to restrict it so that only interactive login sessions cause bash to be invoked. To summarise: if ( "$tty" != "" ) then if ( -x /usr/local/bin/bash ) then setenv SHELL /usr/local/bin/bash exec /usr/local/bin/bash -login endif endif (There may be a more elegant way to check for shell interactivity in csh, and if there is I'd like to know about it, please. :-) -- V To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
