>> No. installworld more or less assumes single user.
>
>This is really what I'm getting at. :-)
>
>If installworld assumes single-user mode, why do we install -C
>ld-elf.so.1 ? The first time I asked this question, I didn't mention
>single-user mode and your answer was that it's to protect "live
On Thu, Jan 28, 1999 at 08:06:58PM +1100, Bruce Evans wrote:
> Someday -C should avoid touching the file if possible, so that it
> doesn't clobber the file's ctime and backups based on ctimes don't do
> unnecessary work. This is possible if none of the attributes except
> the file times would chan
>> Why _not_ use -C? What is the point in replacing a file with the same file?
>> install -C will replace the file if the new file is diffrent.
>
>Aaaah, thank you. I misread the manpage description of -C and didn't
>notice "and the files are the same"...
>
>Cleared up, head back on straight.
On Wed, 27 Jan 1999 18:42:03 CST, Zach Heilig wrote:
> It does update the 'ctime' entry of ld-elf.so.1, so using 'find /usr
> \! -ctime 1 -print' right after make world will find all the "old"
> files.
That's fine, then. I figured install -C wouldn't adjust ctime for files
that hadn't changed.
On Thu, 28 Jan 1999 00:34:30 +0100, Mattias Pantzare wrote:
> Why _not_ use -C? What is the point in replacing a file with the same file?
> install -C will replace the file if the new file is diffrent.
Aaaah, thank you. I misread the manpage description of -C and didn't
notice "and the fil
>> If installworld assumes single-user mode, why do we install -C
>> ld-elf.so.1 ? The first time I asked this question, I didn't mention
>> ...
>Why _not_ use -C? What is the point in replacing a file with the same file?
>install -C will replace the file if the new file is diffrent.
Plain insta
On Wed, Jan 27, 1999 at 02:12:10PM +0200, Sheldon Hearn wrote:
> On Wed, 27 Jan 1999 22:41:46 +1100, Bruce Evans wrote:
> > So that ld-elf.so.1 can be installed safely on an active system.
> I assume I should take your "installed safely" to mean "not installed"?
It is not installed because the b
> > No. installworld more or less assumes single user.
>
> This is really what I'm getting at. :-)
>
> If installworld assumes single-user mode, why do we install -C
> ld-elf.so.1 ? The first time I asked this question, I didn't mention
> single-user mode and your answer was that it's to protect
>From: Sheldon Hearn
>Date: Wed, 27 Jan 1999 13:13:49 +0200
>> I did note that, unlike the SNAP, the result had a /usr/libexec/ld.so;
>Did you make your RELENG_3 world with or without -DNOAOUT? I don't think
>/usr/libexec is created for a -DNOAOUT world. I've noticed this
>particularly with jdk.
On Wed, 27 Jan 1999 23:56:51 +1100, Bruce Evans wrote:
> No. installworld more or less assumes single user.
This is really what I'm getting at. :-)
If installworld assumes single-user mode, why do we install -C
ld-elf.so.1 ? The first time I asked this question, I didn't mention
single-user m
>> So that ld-elf.so.1 can be installed safely on an active system.
>
>I assume I should take your "installed safely" to mean "not installed"?
I meant what I said.
>Are there a lot of files that aren't installed for similar reasons
>during an installworld? If there are, I'd be interested in heari
On Wed, 27 Jan 1999 22:41:46 +1100, Bruce Evans wrote:
> So that ld-elf.so.1 can be installed safely on an active system.
I assume I should take your "installed safely" to mean "not installed"?
Are there a lot of files that aren't installed for similar reasons
during an installworld? If there
>> Read the install(1) manpage, particularly the -C option.
>
>The question, though, is _why_ the need to use -C when installing
>ld-elf.so.1? It's not flagged schg, from the looks of my box.
So that ld-elf.so.1 can be installed safely on an active system.
Plain install is braindamaged (doesn't gi
On Tue, 26 Jan 1999 11:01:25 PST, Mike Smith wrote:
> Read the install(1) manpage, particularly the -C option.
The question, though, is _why_ the need to use -C when installing
ld-elf.so.1? It's not flagged schg, from the looks of my box.
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@
On Tue, 26 Jan 1999 09:51:05 PST, David Wolfskill wrote:
> I did note that, unlike the SNAP, the result had a /usr/libexec/ld.so;
Did you make your RELENG_3 world with or without -DNOAOUT? I don't think
/usr/libexec is created for a -DNOAOUT world. I've noticed this
particularly with jdk.
Ciao
>
> On the other hand, it seems that the /usr/libexec/ld-elf.so.1 was *not*
> modified by the "make world" process; I thought that odd.
Read the install(1) manpage, particularly the -C option.
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ m...@smith.ne
>Date: Tue, 26 Jan 1999 12:25:37 -0500 (EST)
>From: Daniel Aaron Meyer
>Are the links in /usr/lib correct? They didnt get moved to /usr/lib/aout
>when a make aout-to-elf was run?...
In our case, I didn't do a "make aout-to-elf": I started with a system
on which I installed the 3.0-SNAP of 1999
Are the links in /usr/lib correct? They didnt get moved to /usr/lib/aout
when a make aout-to-elf was run? I believe this causes ypcat to display
the maps, but ypmatch will not work.
libcrypt.a -> libdescrypt.a
libcrypt.so.2 -> libdescrypt.so.2
libcrypt_p.a -> libdescrypt_p.a
--Dan
On
>From: Frank Bonnet
>Date: Tue, 26 Jan 1999 16:52:11 MET
>I'm in trouble with NIS on a 3.0 client.
>NIS is setup correctly ;-)
>"ypcat" works well but NOT "ypmatch" ( for any map )
>The NIS master server is a HPUX 10.20 box which is
>accessed by many UNIX clients ( HP and Sun ) without
>probl
Hi
I'm in trouble with NIS on a 3.0 client.
NIS is setup correctly ;-)
"ypcat" works well but NOT "ypmatch" ( for any map )
The NIS master server is a HPUX 10.20 box which is
accessed by many UNIX clients ( HP and Sun ) without
problem.
Any idea ?
TIA
--
Frank Bonnet
Groupe ESIEE Paris
http
20 matches
Mail list logo
