package actually appear on the mirrors in future or are
>there
>> >>>>>
>> >>>>>CJ> issues I am not aware of preventing this from happening?
>> >>>>>
>> >>>>>Have you tried running the procps tools on current stoc
;
> >>>>>CJ> issues I am not aware of preventing this from happening?
> >>>>>
> >>>>>Have you tried running the procps tools on current stock dll
> >>>>>(1.3.12-1) ? For me most of them seem to just hang - top, procps,
&g
On Thu, Jul 04, 2002 at 02:00:06PM -0400, Nicholas Wourms wrote:
>Chris January wrote:
>>>I suspect that this must have something to do with binutils. I changed
>>>the alignments at David Billinghurst's suggestion to accommodate java.
>>>If this is causing problems, however, I'll change them back
t;>>CJ> issues I am not aware of preventing this from happening?
>>>>>
>>>>>Have you tried running the procps tools on current stock dll
>>>>>(1.3.12-1) ? For me most of them seem to just hang - top, procps,
>>>>>uptime, vmstat, w.
preventing this from happening?
> >>>
> >>> Have you tried running the procps tools on current stock dll
> >>> (1.3.12-1) ? For me most of them seem to just hang - top, procps,
> >>> uptime, vmstat, w... havent tried the others.
> >>>
> &
ally appear on the mirrors in future or are
>>there
>>> CJ> issues I am not aware of preventing this from happening?
>>>
>>> Have you tried running the procps tools on current stock dll
>>> (1.3.12-1) ? For me most of them seem to just hang - top, procps,
>
reventing this from happening?
>>
>> Have you tried running the procps tools on current stock dll
>> (1.3.12-1) ? For me most of them seem to just hang - top, procps,
>> uptime, vmstat, w... havent tried the others.
>>
>> Maybe this problem corelates with t
Hello Chris,
Thursday, July 04, 2002, 5:21:07 PM, you wrote:
>> CJ> uptime reads the /proc files regardless of what options you pass.
>>
>> int main(int argc, char *argv[]) {
>> if(argc == 1) print_uptime();
>> if((argc == 2) && (!strcmp(argv[1], "-V"))) display_version();
>> return 0;
>>
> CJ> uptime reads the /proc files regardless of what options you pass.
>
> int main(int argc, char *argv[]) {
> if(argc == 1) print_uptime();
> if((argc == 2) && (!strcmp(argv[1], "-V"))) display_version();
> return 0;
> }
>
> How ?
Try re-compiling with print_uptime commented out. Notice h
CJ>> uptime reads the /proc files regardless of what options you pass.
PT> int main(int argc, char *argv[]) {
PT> if(argc == 1) print_uptime();
PT> if((argc == 2) && (!strcmp(argv[1], "-V"))) display_version();
PT> return 0;
PT> }
PT> How ?
Ok, to answer my own question - I've noticed the
Hello Chris,
Thursday, July 04, 2002, 4:18:07 PM, you wrote:
CJ> uptime reads the /proc files regardless of what options you pass.
int main(int argc, char *argv[]) {
if(argc == 1) print_uptime();
if((argc == 2) && (!strcmp(argv[1], "-V"))) display_version();
return 0;
}
How ?
I'm curren
> Hello Chris,
>
> Thursday, July 04, 2002, 2:52:59 PM, you wrote:
>
> CJ> This is caused by the default alignment changing from 4 bytes to 8
bytes, as
> CJ> far as i can tell. Basically the size of structure passed to the NT
system
> CJ> calls is not the size of structure the call expects, so it
Hello Chris,
Thursday, July 04, 2002, 2:52:59 PM, you wrote:
CJ> This is caused by the default alignment changing from 4 bytes to 8 bytes, as
CJ> far as i can tell. Basically the size of structure passed to the NT system
CJ> calls is not the size of structure the call expects, so it fails and th
Hello Chris,
Thursday, July 04, 2002, 2:52:59 PM, you wrote:
CJ> This is caused by the default alignment changing from 4 bytes to 8 bytes, as
CJ> far as i can tell. Basically the size of structure passed to the NT system
CJ> calls is not the size of structure the call expects, so it fails and th
t stock dll
> (1.3.12-1) ? For me most of them seem to just hang - top, procps,
> uptime, vmstat, w... havent tried the others.
>
> Maybe this problem corelates with the fact that some of the /proc
> files no longer contain information - see below:
> Perhaps it has to do something w
t stock dll
> (1.3.12-1) ? For me most of them seem to just hang - top, procps,
> uptime, vmstat, w... havent tried the others.
> Perhaps it has to do something with your last patch. I don't have time
> to look at this right now though. I can send strace if you want.
Works for me (TM
f them seem to just hang - top, procps,
uptime, vmstat, w... havent tried the others.
Maybe this problem corelates with the fact that some of the /proc
files no longer contain information - see below:
paveltz@MORDOR /tmp/procps/usr/bin
$ cd /proc
paveltz@MORDOR /proc
$ ls -la
total 0
dr-xr-xr-
On Wed, Jul 03, 2002 at 10:48:13AM +0200, Corinna Vinschen wrote:
>On Tue, Jul 02, 2002 at 11:21:42PM +0100, Chris January wrote:
>> > > Ok. Do you have any thoughts on where I should put ps.exe and kill.exe?
>> >
>> >
>> > I ended up renaming 'clear.exe' from the ncurses dist to 'clearn.exe' to
>
On Tue, Jul 02, 2002 at 11:21:42PM +0100, Chris January wrote:
> > > Ok. Do you have any thoughts on where I should put ps.exe and kill.exe?
> >
> >
> > I ended up renaming 'clear.exe' from the ncurses dist to 'clearn.exe' to
> > avoid conflicts with the 'clear' package. (In ncurses, 'clear.exe'
> > Ok. Do you have any thoughts on where I should put ps.exe and kill.exe?
>
>
> I ended up renaming 'clear.exe' from the ncurses dist to 'clearn.exe' to
> avoid conflicts with the 'clear' package. (In ncurses, 'clear.exe' is
> not a 'test' program, so it didn't go into bin/ncurses-test-*/; it w
> > Ok. Do you have any thoughts on where I should put ps.exe and kill.exe?
>
>
> I ended up renaming 'clear.exe' from the ncurses dist to 'clearn.exe' to
> avoid conflicts with the 'clear' package. (In ncurses, 'clear.exe' is
> not a 'test' program, so it didn't go into bin/ncurses-test-*/; it w
Chris January wrote:
> Ok. Do you have any thoughts on where I should put ps.exe and kill.exe?
I ended up renaming 'clear.exe' from the ncurses dist to 'clearn.exe' to
avoid conflicts with the 'clear' package. (In ncurses, 'clear.exe' is
not a 'test' program, so it didn't go into bin/ncurse
On Thu, Jun 27, 2002 at 10:38:55PM +0100, Chris January wrote:
>Ok. Do you have any thoughts on where I should put ps.exe and kill.exe?
>They need to be somewhere other than /bin, but available should the user
>wish to use them. Perhaps I could rename them instead? procps.exe and
>prockill.exe, al
> >>PLEASE do not differentiate between /bin and /usr/bin. This caused no
> >>end of trouble during the early days of setup.exe when setup didn't
> >>*always* follow the mounts. Granted, setup is much better about that
> >>sort of thing now, but don't tempt fate.
> >>
> >>There's no need for sep
Chris January wrote:
>>>
>>PLEASE do not differentiate between /bin and /usr/bin. This caused no
>>end of trouble during the early days of setup.exe when setup didn't
>>*always* follow the mounts. Granted, setup is much better about that
>>sort of thing now, but don't tempt fate.
>>
>>There's
On Thu, Jun 27, 2002 at 07:49:09PM +0100, Chris January wrote:
>> > If it overwrites it, then I have packaged it wrongly. It should put
>ps.exe
>> > and kill.exe into separate subdirectories, i.e. /bin/procps/ps.exe and
>> > /usr/bin/procps/kill.exe.
>>
>>
>> PLEASE do not differentiate between /b
> > If it overwrites it, then I have packaged it wrongly. It should put
ps.exe
> > and kill.exe into separate subdirectories, i.e. /bin/procps/ps.exe and
> > /usr/bin/procps/kill.exe.
>
>
> PLEASE do not differentiate between /bin and /usr/bin. This caused no
> end of trouble during the early day
27 matches
Mail list logo
