Linux-Development-Sys Digest #923, Volume #6 Fri, 2 Jul 99 04:14:14 EDT
Contents:
Re: Why not C++ (Peter Samuelson)
Re: kernel questions (Allin Cottrell)
Re: Shared libs in Linux-Request for clarification (Allin Cottrell)
Compiling Problem! (Jaker Wong)
Compiling Problem! (Jaker Wong)
Re: Compiling Problem! (Cameron Hutchison)
Re: C++ templates: More than Turing Complete? (Davin McCall)
Re: PCI driver blues (Danny Sung)
Re: PTHREADS kernel/user level threading? (Peter Samuelson)
Re: Why not C++ (Cameron Hutchison)
Re: Send email automatically? (Peter Samuelson)
Re: usleep() ("Bruce W. Bigby")
Re: Why not C++ (Justin Vallon)
Always use `patch -p1' [was Re: vesafb for S3 868?] (Peter Samuelson)
Re: Why not C++ (Stephan Houben)
Re: Why not C++ (Klaus-Georg Adams)
Re: C++ templates: More than Turing Complete? (Stephan Houben)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 1 Jul 1999 21:39:48 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Klaus-Georg Adams <[EMAIL PROTECTED]>]
> #define some_function(x) ++x
>
> :-)
>
> You have to look at the definition anyways, in C or C++.
Yes, but there is a practical difference. Most (at least mediocre) C
programmers would never write the above, because we've all been taught
that preprocessor macros must be named in all-caps. Macros that modify
their args most definitely need to be in all-caps. The language
doesn't strictly require it but the legacy is strong.
C++ programmers, by contrast, do *not* by and large play by the rule
that arguments passed by reference must be treated as const. If they
did, we wouldn't be having this discussion.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Subject: Re: kernel questions
Date: Thu, 01 Jul 1999 22:34:06 -0400
Marty Bowers wrote:
> 1.) How do you upgrade the kernel? (I have 2.2.10 downloaded, but
> don't know what to do with it)
http://metalab.unc.edu/mdw/HOWTO/HOWTO-INDEX-3.html#ss3.1
and look for "kernel". There are lots of other useful HOWTOs there.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared libs in Linux-Request for clarification
Date: Thu, 01 Jul 1999 22:28:38 -0400
Howard Mann wrote:
> I use Red Hat 5.0 and KDE 1.1.1. An attempt to install
> a RPM package of "kexpress" failed with the following:
>
> # rpm -Uvh kexpress-0.8.0-0.i386.rpm
> failed dependencies:
> libgdbm.so.1 is needed by kexpress-0.8.0-0
> libpng.so.2 is needed by kexpress-0.8.0-0
> libstdc++.so.2.9 is needed by kexpress-0.8.0-0
>
> Using "locate" I have the following:
>
> /usr/lib/libgdbm.so.2
> /usr/lib/libgdbm.so.2.0.0
OK, so you have libgdbm, but with a higher "major" number than
the one against which kexpress was compiled. These are probably
not compatible -- though it should be possible to compile kexpress
linked against the newer libgdbm if you wish.
> /usr/lib/libpng.so.0
> /usr/lib/libpng.so.0.96
This one's older than the one needed by kexpress. Can you get rid
of it? That depends on whether you have programs on your system
that are linked specifically to libpng.so.0.
> /usr/i486-linux-libc5/lib/libstdc++.so.27
> /usr/i486-linux-libc5/lib/libstdc++.so.27.1.4
> /usr/lib/libstdc++.a
> /usr/lib/libstdc++.so
> /usr/lib/libstdc++.so.2.7.2
> /usr/lib/libstdc++.so.2.7.2.8
> /usr/lib/libstdc++.so.2.8
> /usr/lib/libstdc++.so.2.8.0
There are four distinct libs here: /usr/lib/libstdc++.a is for use
in static linking of executables. You can probably get rid of it
if you wish. /usr/lib/libstdc++.so.2.7.2.8 is one version of
libstc++; libstdc++.so.2.7.2 is just a symbolic link pointing to it,
as is /usr/lib/libstdc++.so; and libstdc++.so.2.8 is a symbolic
link to libstdc++.so.2.8.0. The 2.7 and 2.8 libs are not entirely
compatible. The one (libstdc++.so.27.1.4) in your "libc5" dir
is for supporting "legacy" applications linked to the old libc5.
> These are my questions:
>
> 1. Why do I have so many versions of these libs ?
There aren't quite as many as appears.
> Are any obviously superfluous ?
The *.a libs are superfluous if you don't need to compile programs
statically (and most of us don't). The old versions of libs (lower
numbers) may or may not be superfluous depending on whether you
have old apps lying around that want the old libs.
> What are the essential differences between them?
Pass.
> How and why are new versions continuously developed ?
To fix bugs; to add new functionality or to comply more fully
with recognized standards such as POSIX.
> 2. If I obtain the new versions I apparently need, will
> I run into conflicts with those currently installed?
No, you should not. The dynamic library loader is smart enough
to figure out what library each program needs, for the most part.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
------------------------------
Date: Fri, 02 Jul 1999 11:32:39 +0800
From: Jaker Wong <[EMAIL PROTECTED]>
Subject: Compiling Problem!
I would like to know aftering compiling the kernel, it gives me the
following error messages:
I use the following command to make the kernel:
make dep
make clean
make zlilo or
make boot
After doing this, the error messages are the following:
tools/build.c:25: stdio.h: No such file or directory
tools/build.c:26: string.h: No such file or directory
tools/build.c:27: stdlib.h: No such file or directory
tools/build.c:28: sys/types.h: No such file or directory
tools/build.c:29: sys/stat.h: No such file or directory
tools/build.c:30: sys/sysmacros.h: No such file or directory
tools/build.c:31: unistd.h: No such file or directory
tools/build.c:32: fcntl.h: No such file or directory
tools/build.c:35: errno.h: No such file or directory
However, I have used the following command which I learn from
Kernel-HOWTO.txt:
cd /usr/include
rm -rf asm linux scsi
ln -s /usr/src/linux/include/asm-i386 asm
ln -s /usr/src/linux/include/linux linux
ln -s /usr/src/linux/include/scsi scsi
But it stills not work, what's problem with my kernel.
Please help me.
My system is Redhat 5.2, kernel 2.0.36, 48M Ram 850 harddisk
------------------------------
Date: Fri, 02 Jul 1999 11:29:29 +0800
From: Jaker Wong <[EMAIL PROTECTED]>
Subject: Compiling Problem!
I would like to know aftering compiling the kernel, it gives me the
following
error messages:
tools/build.c:25: stdio.h: No such file or directory
tools/build.c:26: string.h: No such file or directory
tools/build.c:27: stdlib.h: No such file or directory
tools/build.c:28: sys/types.h: No such file or directory
tools/build.c:29: sys/stat.h: No such file or directory
tools/build.c:30: sys/sysmacros.h: No such file or directory
tools/build.c:31: unistd.h: No such file or directory
tools/build.c:32: fcntl.h: No such file or directory
tools/build.c:35: errno.h: No such file or directory
However, I have used the following command which I learn from
Kernel-HOWTO.txt:
cd /usr/include
rm -rf asm linux scsi
ln -s /usr/src/linux/include/asm-i386 asm
ln -s /usr/src/linux/include/linux linux
ln -s /usr/src/linux/include/scsi scsi
But it stills not work, what's problem with my kernel.
Please help me.
My system is Redhat 5.2, kernel 2.0.36, 48M Ram 850 harddisk
------------------------------
From: Cameron Hutchison <[EMAIL PROTECTED]>
Subject: Re: Compiling Problem!
Date: 2 Jul 1999 04:09:42 GMT
Jaker Wong <[EMAIL PROTECTED]> writes:
>I would like to know aftering compiling the kernel, it gives me the
>following error messages:
>tools/build.c:25: stdio.h: No such file or directory
>tools/build.c:26: string.h: No such file or directory
>tools/build.c:27: stdlib.h: No such file or directory
>tools/build.c:28: sys/types.h: No such file or directory
>tools/build.c:29: sys/stat.h: No such file or directory
>tools/build.c:30: sys/sysmacros.h: No such file or directory
>tools/build.c:31: unistd.h: No such file or directory
>tools/build.c:32: fcntl.h: No such file or directory
>tools/build.c:35: errno.h: No such file or directory
It would appear that you need the libc development files. On a Debian
system, that would be the package libc6-dev - locate the equivalent package
from your distribution and install it.
This is not required by the kernel itself, but it appears to be needed by
some of the tools that are used to put the kernel image together.
--
Cameron Hutchison ([EMAIL PROTECTED]) | Onward To Mars
GCS d--@ -p+ c++(++++) l++ u+ e+ m+(-) s n- h++ f? !g w+ t r+
------------------------------
From: [EMAIL PROTECTED] (Davin McCall)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: Fri, 02 Jul 1999 03:34:30 GMT
On 1 Jul 1999 01:57:18 -0700, [EMAIL PROTECTED] (Nathan Myers)
wrote:
>The convention in some communities is to ignore performance
>and engineering rigor. Certainly anything can be achieved in
>assembly language (or in T-code, if you like) that can be achieved
>with a C++ _program_, given infinite time and coding effort.
Infinite? Finite, surely!
To say that something takes an infinite amount of time to do is to say
that it can't be done. And yet, you will find that an assembly
language (or machine code) program of finite size and complexity is
generated whenever you compile a high level language program, even a
C++ program.
>Given the constraints of a sensible _library_ interface and
>equivalent-to-machine-code performance, C++ achieves what
>other languages haven't, yet.
I would say "approaching sensible" and almost completely disagree with
the performance statement. In most cases a compiled program written in
a high level language performs very acceptably, but not nearly as well
as an equivalent program hand coded in assembly language (or machine
code).
>Of course some other languages will achieve parity, someday, but
>only those designed by people who fully understand the strengths of
>standard C++. Maybe such a language will even succeed in avoiding
>its weaknesses.
I take it that you mean they must understand the principles, although
not necessarily how they are applied in C++.
Davin.
__________________________________________________________
*** davmac - sharkin'!! [EMAIL PROTECTED] ***
my programming page: http://yoyo.cc.monash.edu.au/~davmac/
------------------------------
From: [EMAIL PROTECTED] (Danny Sung)
Subject: Re: PCI driver blues
Date: Fri, 02 Jul 1999 05:27:48 GMT
Reply-To: [EMAIL PROTECTED]
Yay! I finally got it working. I finally found that I could
read/write to the AMCC command register (PCI base register 0), even
though the other registers would lock up. After digging around the
windows driver a bit, I discovered a little section that turns off
busmastering. It does this through the AMCC command register, as well
as PCI base register 4 (the MCSR for the AMCC). After doing this, I'm
now able to read/write to the other registers without having the
system lock up.
Now it's only a matter of debugging my I2C interface.
Thanks to all who helped me,
Danny Sung
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: PTHREADS kernel/user level threading?
Date: 2 Jul 1999 00:41:11 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Hugo tetreault <[EMAIL PROTECTED]>]
> This is called "process cpu affinity" and I don't think Linux support
> it.
Linux *does* support process affinity -- in that there is a penalty
(oddly enough it is called PROC_CHANGE_PENALTY or some such) for
scheduling a process on a different CPU -- but you are right that there
is no way to control this from user space, i.e. "dedicate" a CPU to a
particular process.
The problem with absolute processor affinity is the same as the problem
with other RT constructs: you end up wasting resources if the process
ever doesn't need all it has been given (e.g. it does blocking I/O). I
suppose a syscall � la `renice' to control the cpu of a given process
would be relatively trivial to add to the Linux kernel, if you needed
it. As for the other IRIXism you mention -- syscalls to direct
individual interrupts to individual CPUs -- I don't know how easy that
would be. Not too hard, I would guess.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Cameron Hutchison <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 2 Jul 1999 03:18:34 GMT
[EMAIL PROTECTED] (Peter Samuelson) writes:
>[Klaus-Georg Adams <[EMAIL PROTECTED]>]
>> #define some_function(x) ++x
>>
>> :-)
>>
>> You have to look at the definition anyways, in C or C++.
>Yes, but there is a practical difference. Most (at least mediocre) C
>programmers would never write the above, because we've all been taught
>that preprocessor macros must be named in all-caps. Macros that modify
>their args most definitely need to be in all-caps. The language
>doesn't strictly require it but the legacy is strong.
Hmm. I wonder who wrote the macro get_user that is used throughout the
linux kernel. It modifies its first argument and is named all lower case.
Must have just been a mediocre C programmer.
--
Cameron Hutchison ([EMAIL PROTECTED]) | Onward To Mars
GCS d--@ -p+ c++(++++) l++ u+ e+ m+(-) s n- h++ f? !g w+ t r+
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Send email automatically?
Date: 2 Jul 1999 00:00:09 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Matthias Kapfhamer]
> > can anybody please tell me, how I can send email automatically to a
> > number of people I keep in a database?
Either (a) get spamming software or (b) get mailing-list software,
depending on exactly what you want.
[mlw <[EMAIL PROTECTED]>]
> If you are using postgres try this:
>
> cat mailmsg.txt | sendmail $(psql -c "select email from database" database)
Classic example of a UUOC (Useless Use of Cat), as tchrist would say in
comp.unix.shell. Recommended instead:
< mailmsg.txt sendmail $(psql -c "select email from database" database)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: "Bruce W. Bigby" <[EMAIL PROTECTED]>
Subject: Re: usleep()
Date: Fri, 02 Jul 1999 02:11:46 -0400
Daniel R. Grayson wrote:
>
> Calls to usleep() take a lot longer than they need to (20000 microseconds
> instead of 1 microsecond on my system). Has anyone thought of improving the
> accuracy of usleep() in Linux? It's possible, because select() can do it.
>
> % gcc foo.c
>
> % time a.out
>
> real 0m5.006s
> user 0m0.000s
> sys 0m0.000s
>
> % cat foo.c
> #include <unistd.h>
> int main() {
> int i;
> for (i=0; i<250; i++) usleep(1);
> return 0;
> }
>
> % w
> 10:41am up 1:43, 0 users, load average: 0.09, 0.07, 0.01
> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
>
> From man usleep:
>
> SYNOPSIS
> #include <unistd.h>
>
> void usleep(unsigned long usec);
>
> DESCRIPTION
> The usleep() function suspends execution of the calling
> process for usec microseconds. The sleep may be lengthened
> slightly by any system activity or by the time spent
> processing the call.
I'd like to know the answer to this question, as well. Please e-mail me.
--
Bruce W. Bigby
http://home.rochester.rr.com/bigbyofrocny
Do for others what you would want others to do for you.
------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 2 Jul 1999 00:44:53 -0400
[EMAIL PROTECTED] (Bruce Hoult) writes:
> In article <7lbkp6$h72$[EMAIL PROTECTED]>, Cameron Hutchison
> <[EMAIL PROTECTED]> wrote:
>
> > Consider this:
> >
> > #define inc(x) (++(x))
> > ...
> > int x = 1;
> > ...
> > inc(x);
> >
> > In this case, x is being modified and you cannot tell from the context. It
> > may be bad form to write a macro with lower case letters, but it can also
> > be argued that it is bad form to use non-const references in C++.
>
> A hit! A very palpable hit!
Right, but you called the macro/function inc. Maybe it would be more
obvious if the function were named increment?
template<class T>
inline T& increment(T& x) {
return ++x;
}
Is there any question as to whether increment(y) changes the value of y?
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Always use `patch -p1' [was Re: vesafb for S3 868?]
Date: 2 Jul 1999 01:53:37 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Roope Anttinen <[EMAIL PROTECTED]>]
> The linux source tree has to be named linux-2.2.9 for that particular
> patch. Then in /usr/src directory do:
> zcat patch-s3lfb-2.2.9.gz | patch -p0
NO! The source tree can be named anything you want; this is merely a
problem with using -p0. A much safer and easier method is just to get
in the habit of using -p1 instead. cd into the Linux source tree and
zcat ../almost-any-kernel-patch.gz | patch -p1
I say "easier" because you never have to rename your source tree.
(Some people's patches go into "linux/", some into "linux-2.2.9/", some
into "generic/", etc). I say "safer" because you can *always* be sure
where the patch is going in, i.e. if you have seven source trees in
/usr/src, you *know* (because you specified via `cd') which one is
getting the patch.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 02 Jul 1999 09:01:29 +0200
[EMAIL PROTECTED] (Nathan Myers) writes:
> Stephan Houben <[EMAIL PROTECTED]> wrote:
> >
> >If you did this, then you would realize that "templates" are only
> >the shadow on the wall of a much more powerful and elegant system,
> >namely an ML-style type system.
>
> That is easily said, but it happens to be false. C++ templates
> can express useful ideas that are impossible in "an ML-style
> type system".
You mean the lack of "ad hoc" polymorphism?
That's true in a pure Hindley-Milner type system.
However, Haskell adds "type classes", which allows a kind
of ad hoc polymorphism, but in a more structured (and type-safe) way.
By the way, how would you express with C++ templates the type
of the "error" function in Haskell:
error :: String -> a
Greetings,
Stephan
------------------------------
From: Klaus-Georg Adams <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 02 Jul 1999 09:21:58 +0200
[EMAIL PROTECTED] (Peter Samuelson) writes:
> [Klaus-Georg Adams <[EMAIL PROTECTED]>]
> > #define some_function(x) ++x
> >
> > :-)
> >
> > You have to look at the definition anyways, in C or C++.
>
> Yes, but there is a practical difference. Most (at least mediocre) C
> programmers would never write the above, because we've all been taught
> that preprocessor macros must be named in all-caps. Macros that modify
> their args most definitely need to be in all-caps. The language
> doesn't strictly require it but the legacy is strong.
>
> C++ programmers, by contrast, do *not* by and large play by the rule
> that arguments passed by reference must be treated as const. If they
> did, we wouldn't be having this discussion.
from /usr/src/linux-2.2.9/include/asm-386/system.h, line 193:
#define save_flags(x) ((x)=__global_save_flags())
This is used at zillions of places in the linux kernel. And it is just
one example of such a macrodefinitions. It just goes to show that you
have to apply things like this judiciously, but you can live very well
with them.
It looks like you need programers who are better than mediocre to get
away with the above :-)
kga
------------------------------
From: Stephan Houben <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 02 Jul 1999 09:18:04 +0200
[EMAIL PROTECTED] (Davin McCall) writes:
> On 1 Jul 1999 01:57:18 -0700, [EMAIL PROTECTED] (Nathan Myers)
> wrote:
>
> >The convention in some communities is to ignore performance
> >and engineering rigor. Certainly anything can be achieved in
> >assembly language (or in T-code, if you like) that can be achieved
> >with a C++ _program_, given infinite time and coding effort.
>
> Infinite? Finite, surely!
>
> To say that something takes an infinite amount of time to do is to say
> that it can't be done. And yet, you will find that an assembly
> language (or machine code) program of finite size and complexity is
> generated whenever you compile a high level language program, even a
> C++ program.
No, not every C++ program is compiled to a finite amount of assembly.
Take the following counter-example:
================begin code==================
template <class A>
void call_me(A a, int i)
{
if (i > 0)
call_me(&a, i - 1);
}
int main(void)
{
int a;
call_me(a, 10);
return 0;
}
=================end code==================
This produces the following error message (with gcc):
test.cc:5: virtual memory exhausted
I guess that an infinite amount of processing time and
memory space would be sufficient to compile this program
Note that the program, once compiled, would actually terminate
after 10 recursive calls of call_me().
Also note that a *compiler* that can handle all possible variations
on this theme would need to be more than Turing complete.
Greetings,
Stephan
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
