Linux-Development-Sys Digest #997, Volume #6 Tue, 27 Jul 99 15:14:06 EDT
Contents:
Re: Writing shared libraries (Magdalene Tan)
Re: Compiling Linux 1.0 (David T. Blake)
Re: drives mount in linux and dos-like OS's (David T. Blake)
Re: IO Completion Ports ([EMAIL PROTECTED])
Re: Formating from C code ("Rapha�l Co�ffic")
Re: Writing shared libraries (Paul D. Smith)
Re: when will Linux support > 2GB file size???
Re: Need help with PAM/g++ (Glen Wiley)
Compiling Linux 1.0 (Matthias Maisenbacher)
Re: when will Linux support > 2GB file size??? (Philip Brown)
Re: hang at "finding module dependencies" ("Rapha�l Co�ffic")
Re: Writing shared libraries (David B Anderson)
Re: ASCII to speech??? (Gergo Barany)
Re: How do I learn about the Scheduling Algorithm used in Linux? (leoxx)
ASCII to speech???
Re: Need help with PAM/g++ (Huaming Wang)
Re: problem with linuxthreads (glibc 2.1) and user stacks (peter hatch)
----------------------------------------------------------------------------
From: Magdalene Tan <[EMAIL PROTECTED]>
Subject: Re: Writing shared libraries
Date: Tue, 27 Jul 1999 22:35:21 +0800
Look at:
http://www.cl.cam.ac.uk/users/iwj10/linux-faq/index.html
"How to make shared library".
Kevin Woodward wrote:
>
> Hi All,
>
> I'm looking for information/help on writing shared libraries for
> Linux. I'd appreciate any URLs or book titles on the subject.
>
> Thanks,
>
> Kevin Woodward.
--
\\\|/// Peter Teoh
\\ - - // Oracle Certified Professional
( @ @ )
__oOOo-(_)-oOOo____________________________________
| _____ |
| (~._.~) |
|Email:[EMAIL PROTECTED] _{ Y }_ |
|Phone:97813086(HP) ()_~~~_()|
|Pager:96047971 (_)-(_) |
|http://web.singnet.com.sg/~petermag/ |
|__________________________________________________|
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: Compiling Linux 1.0
Date: 27 Jul 1999 13:36:15 GMT
Reply-To: [EMAIL PROTECTED]
Matthias Maisenbacher <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> while trying to compile an original linux 1.0 kernel i've got
> some trouble.
> I didn't expect any problems when doing the usual
Do a grep for include statements in the source, and
then double check the /usr/include/linux and /usr/include/asm*
links to ensure they are set properly for the new (old)
kernel.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: drives mount in linux and dos-like OS's
Date: 27 Jul 1999 13:38:11 GMT
Reply-To: [EMAIL PROTECTED]
Alexander Viro <[EMAIL PROTECTED]> wrote:
> D'oh. So write it... It's a one-liner - mount name_of_the_mountpoint and
> there you go. Just add the appropriate line into /etc/fstab (don't
> forget to add noauto,user to options field). What's the problem?
I think he probably wants to add user,auto to /etc/fstab
so that he doesn't even need the script.
Or use supermount.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: IO Completion Ports
Date: 27 Jul 1999 08:29:24 -0400
>>>>> "Williams" == Williams <[EMAIL PROTECTED]> writes:
Williams> else. Functionally, there's nothing about linux that makes completion
Williams> ports unnecessary, it would in fact be good to have such a mechanism
Williams> available. But, they're simply not available there, that's all (well,
Williams> 'select' kind of does a similar thing.)
But posix aysnc io IS there. You need glibc-2.1. Isn't that what you
want?
------------------------------
From: "Rapha�l Co�ffic" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Formating from C code
Date: Tue, 27 Jul 1999 16:39:05 +0200
Neal Richter wrote:
> Hello,
> Could someone please direct me to some sample code and/or documentation
> of formating drives from C/C++ code... Partitioning would be good too.
You can find the sources of fdisk at the folowing location :
ftp://ftp.funet.fi/pub/Linux/tools/fdisk-1.5.tar.gz
I wish you a good dive into these sources !
Raf.
------------------------------
From: [EMAIL PROTECTED] (Paul D. Smith)
Subject: Re: Writing shared libraries
Date: 27 Jul 1999 12:19:32 -0400
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] (Kevin Woodward) writes:
kw> Thanks. From that I assume libx.a is a.out format and libx.so is
kw> for ELF?
No. The .a is a static library, in case you want to link statically
(otherwise you don't need it), and the .so is a shared library.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: Tue, 27 Jul 1999 10:13:53 -0700
On Tue, 27 Jul 1999 05:49:25 GMT, Bloody Viking <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.advocacy Philip Brown <[EMAIL PROTECTED]> wrote:
>
>: Umm.... a low-end alpha was affordable 2 years ago.
>
>Depends on your definition of "affordable", which is of course a function
2 years ago, PC prices were a lot worse too. You would be lucky
to find a brand name machine in a shiop for less than $1500.
Better machines were going for considerably more.
So, in that context, a $2000 Alpha was affordable.
>of your take-home pay. For a professional making $80K/yr, you're right.
>For a postal worker, no. Becuse I'm a postal worker, the Y2K-3 DEC Alphas
Some of the early Atarians, back when the console alone went
for $800 were postmen and other similar working class stiffs.
[deletia]
--
It helps the car, in terms of end user complexity and engineering,
that a car is not expected to suddenly become wood chipper at some |||
arbitrary point as it's rolling down the road. / | \
Seeking sane PPP Docs? Try http://penguin.lvcm.com
------------------------------
From: Glen Wiley <[EMAIL PROTECTED]>
Subject: Re: Need help with PAM/g++
Crossposted-To: comp.unix.programmer
Date: Tue, 27 Jul 1999 17:00:23 GMT
In comp.unix.programmer lx <[EMAIL PROTECTED]> wrote:
: This seems like such a simple problem, but it's just not working
: out that way. ;)
: I have successfully completed an application in C which utilizes
: the pam (0.66) libraries to authenticate a user via the system's
: passwd list. It works great; compiles, executes, gives valid data.
: I have compiled it with gcc, egcs 2.91.66 (and running Redhat 6.0).
: I am trying to suture it into the mother application, which is in
: C++, and upon running the same compile request with g++ rather
: than gcc, I get "undefined references" on the pam libs.
: These are my command lines:
: gcc auth.c -o auth -ldl -lpam -lpam_misc
: g++ auth.c -o auth -ldl -lpam -lpam_misc
: The first works. The second yields undefined references on PAM
: functions described in both libpam.so and libpam_misc.so. What on
: earth is going on here??
: If any of you UNIX gurus can assist on this, I will be more than
: a little in your debt.
C functions must be dclared as extern "C" in order to be called by
C++ code. The pam headers in RedHat do not test the cplusplus
macro so you should do something similar to the following:
extern "C" {
#include <myfile.h>
};
--
Glen Wiley [EMAIL PROTECTED]
Senior Software Engineer http://www.wwa.com/~gwiley/glen
3Com - Carrier Systems R&D
"UNIX _IS_ user friendly, its just picky about who its friends are."
------------------------------
From: [EMAIL PROTECTED] (Matthias Maisenbacher)
Subject: Compiling Linux 1.0
Date: 27 Jul 1999 12:27:22 GMT
Reply-To: [EMAIL PROTECTED]
Hi,
while trying to compile an original linux 1.0 kernel i've got
some trouble.
I didn't expect any problems when doing the usual
unzip
untar
make config
make dep
make clean
make zImage
but it failed not after the make dep step.
There was some duplicate symbols and missing incude files.
Is there any receipe for what i'm doing wrong or do i have
to repair all errors one by one?
Many others mut have had this problem before.
It's a Debian 2.1 system with 2.0.36 or 2.2.10 Linux
gcc is 2.7.2.3
Any help is very appreciated
Matthias
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Reply-To: [EMAIL PROTECTED]
Date: 27 Jul 1999 17:16:40 GMT
On 26 Jul 1999 12:30:29 -0700, [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
>Philip Brown <[EMAIL PROTECTED]> wrote:
>>THe people complaining about lack of 64-bit filesystems are NOT going to be
>>using this on /usr :-) They want a very large data filesystem, and they could
>>care less about libraries on that filesystem. Which is why I suggested hacking
>>a NEW filesystem, that doesn't support memory mapping, but DOES support
>>having large files.
>
>Common database operation:
>
>fd = open("/opt/bloated_commercial_database/data/big_fat_table.dat");
>foo = mmap(start, 100000000000, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);
Yes, I know that. However, that's not the ONLY way databases work.
They can be reformulated to work with "raw" devices, which don't support
memory mapping. Yes, I know there aren't too many databases for linux that
support this. But it's not impossible with the existing VM, like you seem to
be making it out.
>And again, I tell you, THE FILESYSTEM DOES NOT SUPPORT MEMORY MAPPING.
And again, I tell you, "SO WHAT" :-)
>>Givena choice between fiddling with a filesystem, and screwing with
>>memory management for my entire system... I'd choose fiddling with a
>>filesystem :-)
>
>So would I. IF IT WORKS. It won't.
If I wasn't already busy writing solaris drivers, I'd love to shove code in
your face to prove you wrong :-)
Bottom line:
If you have an application, and all it wants to do is do
while(1){
lseek64()
read/write()
}
on a really large data file, it should be doable on a 32-bit VM system, with
some custom filesystem rewrites, and possibly an override of the lseek64()
libc routine.
It won't be pretty. It won't be efficient. But it is doable, and safer
than messing around with the VM system.
[On the other hand, it may end up being a lot more work. But since I'm not
the one who needs it, I don't care :-) ]
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
--------------------------------------------------
The word of the day is mispergitude
------------------------------
From: "Rapha�l Co�ffic" <[EMAIL PROTECTED]>
Subject: Re: hang at "finding module dependencies"
Date: Tue, 27 Jul 1999 16:02:48 +0200
Yung-Hsiang Lu wrote:
> Hi, Everyone,
>
> Does anyone know what can make Linux hang at "finding module
> dependencies"? I believe I did not change anything related to
> modules. I am using Linux 2.2.5 (redhat 6.0).
I think you probably recompiled the kernel ?!
If you did so, you probably forgot 'make modules' and 'make
modules_install'. But first, you must delete the previous content of the
module directory (/lib/modules/linux-2.2.5/ in your case).
If you want to test your module configuration type 'depmod -a'. if you
get any error, that means that you should reinstall the modules.
Bye,
Raf.
------------------------------
From: [EMAIL PROTECTED] (David B Anderson)
Subject: Re: Writing shared libraries
Date: 27 Jul 1999 18:07:34 GMT
In article <[EMAIL PROTECTED]>,
Kevin Woodward <[EMAIL PROTECTED]> wrote:
>
>Thanks. From that I assume libx.a is a.out format and libx.so is for
>ELF?
>On Tue, 27 Jul 1999 22:35:21 +0800, Magdalene Tan wrote:
>>Look at:
>>
>>http://www.cl.cam.ac.uk/users/iwj10/linux-faq/index.html
>>
>>"How to make shared library".
===========
Question 5.8. How do I make a shared library ?
For ELF,
gcc -fPIC -c *.c
gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
For a.out, get tools-n.nn.tar.gz from tsx-11.mit.edu, in /pub/linux/packages/GCC/src.
It comes with documentation that
will tell you what to do. Note that a.out shared libraries are a very tricky business.
===========
[WARNING: what follows is all tedious detail you don't
really care about: sorry]
===========
And a.out shared libraries are not really standard: you can
create such only on some systems (Linux is one).
So it's not such a great idea to use them as the portability
is limited.
===========
Archive (archives have *.a names by convention)
members can be anything.
COFF archive objects, elf non-PIC archive objects,
elf PIC archive objects, source files,
or anything.
elf PIC objects (from archive(s) and/or
from separate elf PIC objects) can be combined to *create*
a shared library.
By convention libx.so means a shared library (which
would be composed of PIC object files linked together).
libx.a is less clear.
You have to look at the *contents* of libx.a to know.
It does not help the general
confusion that a.out is both one name of
an object format and the default name of an executable
from Linux/UNIX compilations.
[In Elf, there is really very little difference between
an Elf a.out and an Elf shared library.
Aside from an indication in the Elf file header
(ET_EXEC vs ET_DYN)
there is little to distinguish them.
(there are some hints, but the format is identical
and they contain the same data sections and segments).
An ELF object file is the same *format* of course, but
it has ET_REL as the marking and has no segments
and has not had various sections created by the linker.]
corrections to:
David B. Anderson [EMAIL PROTECTED] http://reality.sgi.com/davea/
Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
Julk, August, September, October, November, December.
------------------------------
From: [EMAIL PROTECTED] (Gergo Barany)
Crossposted-To: comp.os.linux.misc
Subject: Re: ASCII to speech???
Date: 27 Jul 1999 17:44:58 GMT
In article <7nkjc5$t8s$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>I am looking for voice recognition software with ASCII to speech
>capabilities. Also hardware and software for a video camera.
ASCII to speech would be voice synthesis, not recognition. There is a
package called rsynth which might do what you want.
>may the force be with you....
>
>Mark Cohen
>
>------------------ Posted via SearchLinux ------------------
> http://www.searchlinux.com
Please don't use SearchLinux. It puts garbage at the end of your lines
and is a lot slower and less comfortable than a real newsreader. And
their code is not even free :-(
Gergo
--
This is a good time to punt work.
GU d- s:+ a--- C++>$ UL+++ P>++ L+++ E>++ W+ N++ o? K- w--- !O !M !V
PS+ PE+ Y+ PGP+ t* 5+ X- R>+ tv++ b+>+++ DI+ D+ G>++ e* h! !r !y+
------------------------------
From: [EMAIL PROTECTED] (leoxx)
Subject: Re: How do I learn about the Scheduling Algorithm used in Linux?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 25 Jul 1999 14:19:39 GMT
> Can any one tell me how i can learn of the scheduling algo used in
>linux and also about the various other mechanism like page
>handling, semaphores, networking etc in Linux? I have the source code that
>accompanies the Linux distribution, but is there any other way to learn of
>the internal working? Please tell me. I really want to learn and
>contribute something to Linux.
Probably the best documentation would be one of the many Linux kernel
books that have been written. One I've seen is called "Linux Kernel
Internals" by Michael Beck.
--
JR
------------------------------
From: <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: ASCII to speech???
Date: 27 Jul 1999 15:31:17 GMT
I am looking for voice recognition software with ASCII to speech
capabilities. Also hardware and software for a video camera.
may the force be with you....
Mark Cohen
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: Huaming Wang <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: Need help with PAM/g++
Date: Tue, 27 Jul 1999 12:09:02 -0500
Aha, I guess it's a classical name mangling problem. It happens when you
try to connect c program with c++ program. To avoid this, you might want
to include your c routines with
extern "C"{
your c routines here...
}
For details, you need to check reference book or just take a look of
some standard include header files.
G'day
Huaming Wang
lx wrote:
> This seems like such a simple problem, but it's just not working
> out that way. ;)
>
> I have successfully completed an application in C which utilizes
> the pam (0.66) libraries to authenticate a user via the system's
> passwd list. It works great; compiles, executes, gives valid data.
> I have compiled it with gcc, egcs 2.91.66 (and running Redhat 6.0).
>
> I am trying to suture it into the mother application, which is in
> C++, and upon running the same compile request with g++ rather
> than gcc, I get "undefined references" on the pam libs.
>
> These are my command lines:
>
> gcc auth.c -o auth -ldl -lpam -lpam_misc
> g++ auth.c -o auth -ldl -lpam -lpam_misc
>
> The first works. The second yields undefined references on PAM
> functions described in both libpam.so and libpam_misc.so. What on
> earth is going on here??
>
> If any of you UNIX gurus can assist on this, I will be more than
> a little in your debt.
>
> Thanks in advance,
> .lx
> --
> [ [EMAIL PROTECTED] -- http://www.audiophonic.com/lx/ ]
> [ "in a mirror, all the time turns counter-clockwise." ]
> [ "and every time i look, i find my face has changed." ]
------------------------------
From: peter hatch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: problem with linuxthreads (glibc 2.1) and user stacks
Date: Tue, 27 Jul 1999 11:23:51 -0500
Kaz Kylheku wrote:
>
> On Mon, 26 Jul 1999 20:36:34 -0500, peter hatch <[EMAIL PROTECTED]> wrote:
> >I've just found out that if your application supplies itself with some
> >stacks (for instance if your app is a virtual machine) and you use
>
> If your app is a virtual machine, what's it doing messing around with
> *real* stacks? :) :) :)
>
It's doing byte code->machine code JIT compilation.
> >linuxthreads, everything gets messed up if you get a signal while
> >executing in our own stack space.
>
> So what exactly are you doing? Changing stack contexts in a similar
> way to setjmp()/longjmp() or any number of user-level threading
> schemes? Why bother if you have threads already?
>
No, the vm maintains it's own byte-code execution stack.
> I say, stick to one method or another. Or else, observe the
> appropriate caveats.
>
What caveats are those? Why is it that *no* other thread implementation
(and we run on 11 platforms) has this restriction???
> >There is an assumption in thread_self() (not pthread_self()) that
> >assumes that a thread can only execute on a) the process's stack b) a
> >thread-specific stack. It makes no allowances for threads that might
> >execute on *both* the process stack *and* a user managed stack.
>
> You simply have to avoid making any pthread_* calls when the stack has been
> modified to point somewhere other than where the threading implemenation
> expects it to be. LinuxThreads discover their own identity by using their stack
> pointer. That's just how it is.
>
You can't "avoid" signals.
> The technique you are doing is less than well-defined according to
> the standards that govern the language and libraries you are using.
>
What I'm saying is that it shouldn't be "less than well defined." The
process doesn't need two stacks (or more, up to 10) because it's running
out of stack room. It needs them because the execution rules on each
stack are different. You can't mix them. This has run quite well on
almost *every* other unix since about 1994.
> >than anything else. If your application doesn't need to spawn threads
> >during a particular execution, then why should it? Looks messy having
> >every invocation of the vm show up as 2 processes....
>
> And it doesn't look messy when a HLL program messes with stack pointers? ;)
>
No, it looks necessary. It's part of the design. The stack space is
just one of 9 memory spaces our vm manages. You can't get rid of it.
> >So, I'm searching for a better hack.
>
> How about this: have your stacks, but make sure they are in the
> same sandbox as where the thread's stack is expected to be.
>
Can't do that. It would break the whole vm. The vm has more than 20
years of development in it, and we can't go about drastically altering
the core design just so linuxthreads can make silly assumptions about
where *I* can have stacks.
> LinuxThreads maps thread stacks at equal intervals in memory. They are 2
> megabytes apart. A given thread's stack region could be subdivided further and
> the subdivisions used as multiple stacks. I think that if you did this, then
> thread_self() will still work, because all it cares about is that your stack
> pointer is within that 2 megabyte box associated with that thread. If that
> pointer is in that box, then the calculation done by thread_self() will
> succeed. Just stay away from the unmapped guard page at the upper end (i.e.
> lowest address)!
>
> How much stack space do you need anyway?
Like I said, it's not a matter of space. It's a matter of function.
All that needs to happen is that I be given an interface for setting
__pthread_nonstandard_stacks. With that, the problem is solved.
This vm has over 350,000 lines of code. It's one of the fastest
non-animorphic vms around. This is because of the tight control we keep
over our JIT stack and associated memory spaces. The only problem here
is that Linux has a *very* funky threads implementation that makes
assumptions about my architecture that it doesn't need to make. It just
needs to be fixed, that's all.
------------------------------
** 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
******************************
