Linux-Development-Sys Digest #998, Volume #6 Tue, 27 Jul 99 19:14:15 EDT
Contents:
Re: problem with linuxthreads (glibc 2.1) and user stacks (mlw)
Re: Compiling Linux 1.0 (David Wragg)
Re: problem with linuxthreads (glibc 2.1) and user stacks (peter hatch)
Re: problem with linuxthreads (glibc 2.1) and user stacks (Kaz Kylheku)
Re: Compiling Linux 1.0 (Mark Tranchant)
Re: drives mount in linux and dos-like OS's (Johan Kullstam)
Re: Multiple kernels with different modules (Frodo Looijaard)
Re: Compiling Linux 1.0 (Paul Kimoto)
Re: Writing shared libraries ([EMAIL PROTECTED])
Re: when will Linux support > 2GB file size??? (Johan Kullstam)
reading damaged CDs ([EMAIL PROTECTED])
Re: ASCII to speech??? ("Elias Penttil�")
----------------------------------------------------------------------------
From: mlw <[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 19:06:54 +0000
peter hatch 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
> linuxthreads, everything gets messed up if you get a signal while
> executing in our own stack space.
Looking at your posts, tell me if I am correct.
While in real program land, you use the application stack space, When
you switch to jit-compiled code you switch stacks to java VM stack
execute some jit code and exit.
I do not know why other platforms do not exhibit problems, but, I can
tell you this is not a good way to go about doing it. Switching stacks
around like this is a dangerous business.
Have you tried allocating stack space within the java stack for the
application code?
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit http://www.mohawksoft.com
------------------------------
From: David Wragg <[EMAIL PROTECTED]>
Subject: Re: Compiling Linux 1.0
Date: 27 Jul 1999 19:01:48 +0000
[EMAIL PROTECTED] (Matthias Maisenbacher) writes:
> while trying to compile an original linux 1.0 kernel i've got
> some trouble.
>
> [snip]
>
> It's a Debian 2.1 system with 2.0.36 or 2.2.10 Linux
> gcc is 2.7.2.3
Are you building with an a.out compiler? I don't think the kernel
supported ELF builds until sometime in 1.1.x
------------------------------
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 15:07:54 -0500
mlw wrote:
>
> peter hatch 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
> > linuxthreads, everything gets messed up if you get a signal while
> > executing in our own stack space.
>
> Looking at your posts, tell me if I am correct.
>
> While in real program land, you use the application stack space, When
> you switch to jit-compiled code you switch stacks to java VM stack
> execute some jit code and exit.
>
Actually, it's a Smalltalk vm. What happens is that the byte codes are
executed on the byte code stack, while C code is executed on the
application stack. This has to be done in order to execute the byte
codes. I know that java vms don't typically do this, but then again
they're pretty new (and pretty slow).
> I do not know why other platforms do not exhibit problems, but, I can
> tell you this is not a good way to go about doing it. Switching stacks
> around like this is a dangerous business.
>
But, the design has been in production use since 1983 with *no problems*
on any platform until now. It's a straigh-forward stack-based
architecture that's been used for decades. And Linux/glibc 2.1 is the
only platform we run on where we've found problems, and the problems are
simply due to the nascent code in the linuxthreads library.
> Have you tried allocating stack space within the java stack for the
> application code?
>
That would be a platform-specific hack since it's not needed on any
platform but Linux/glibc 2.1. Our VM code runs on every vendor Unix
system (plus Win and Mac). This kind of thing isn't needed under any of
them....
The problem is that there is a mechanism in linuxthreads that allows me
to do what I need to do, I just can't get at it cleanly. If I start up
and immediately create a thread with a user-supplied stack which
immediately dies, then everything works fine since I've succeeded in
setting the __pthread_nonstandard_stacks variable. But, this is the
only way to set that variable since it's not exported from libpthread.
I think it would be much better to have an initialization interface for
setting this variable.
> --
> Mohawk Software
> Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
> Visit http://www.mohawksoft.com
Cheers,
pete
(Virtual Machine Developer, Linux Product Manager
ObjectShare, Inc.)
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: problem with linuxthreads (glibc 2.1) and user stacks
Date: Tue, 27 Jul 1999 20:20:05 GMT
On Tue, 27 Jul 1999 15:07:54 -0500, peter hatch <[EMAIL PROTECTED]> wrote:
>The problem is that there is a mechanism in linuxthreads that allows me
>to do what I need to do, I just can't get at it cleanly. If I start up
>and immediately create a thread with a user-supplied stack which
>immediately dies, then everything works fine since I've succeeded in
>setting the __pthread_nonstandard_stacks variable. But, this is the
>only way to set that variable since it's not exported from libpthread.
I think you have to get on the glibc mailing list with this one.
You may have to build your own LinuThreads and statically link it in.
Even if the library maintainers put in a fix, your program will still have to
run in installations where the interface to set __pthread_nonstandard_stacks is
not available.
------------------------------
From: Mark Tranchant <[EMAIL PROTECTED]>
Subject: Re: Compiling Linux 1.0
Date: Tue, 27 Jul 1999 14:53:26 +0100
Reply-To: [EMAIL PROTECTED]
A guess - your /usr/include/linux and /usr/include/asm (?) symbolic
links are pointing to the 2.x files.
Mark.
Matthias Maisenbacher 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
>
> 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: Johan Kullstam <[EMAIL PROTECTED]>
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 16:07:51 -0400
YamYam <[EMAIL PROTECTED]> writes:
> Hi...
> I want to ask about the difference in mount/umount the drivers in
> linux 'is it necessary, if so why?' and the easy one in Dos-like
> OS's 'e.g., Win95, Win98, ...'.
> I found it very complicated for the Dos-like users to switch to linux at
> this point. Is there any suggessions to make easy for that user, such as
> writing a script to mount/umount the floppy and cdrom?
1) don't bother mounting floppies. for unix-unix file transfer, use
tar to write to them like a tape. for linux-dos, use mtools. fyi
mtools can access your V?FAT partitions too.
2) you can set options in /etc/fstab to let random luser mount the
cdrom. in my experience, it's not the typing of mount/umount, it's
the hassle of becoming root to do it that's annoying. perhaps
mtools works with cdroms too?
--
johan kullstam
------------------------------
From: [EMAIL PROTECTED] (Frodo Looijaard)
Crossposted-To: ucsc.comp.os.linux
Subject: Re: Multiple kernels with different modules
Date: 27 Jul 1999 20:56:33 GMT
In <7ni357$81i$[EMAIL PROTECTED]> [EMAIL PROTECTED] (bill davidsen)
writes:
>In article <[EMAIL PROTECTED]>,
>Tom M. Kroeger <[EMAIL PROTECTED]> wrote:
>|
>| I'm modifying the 2.2.9 kernel to conduct some tests and
>| want to have several versions of the same kernel on
>| one system. My problem is that the modules are different
>| as well, and that I'd like to be able to at boot (maybe
>| thought a lilo.conf variable) set where the modules
>| for the current kernel should be found
>| eg..:
>In the Makefile is a value named EXTRA_VERSION which can be changed for
>each kernel permutation. If you run both uni and SMP kernels it's
>important to have two sets of modules, since some modules use structs
>which change.
>In the old days before that was available, I used to add a leading zero
>to the subversion, like 2.2.009, for SMP. That field needed to be a
>number, there were modules furiously checking versions as code changed.
Check out http://huizen.dds.nl/~frodol/howto.html for a better way.
Frodo
--
Frodo Looijaard <[EMAIL PROTECTED]> PGP key and more: http://huizen.dds.nl/~frodol
At my homepage you will also find a guide for installing glibc under Linux.
New: Linux hardware monitoring kernel modules (LM78/79/80, Winbond etc.)
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Compiling Linux 1.0
Date: 27 Jul 1999 14:21:36 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, David T. Blake wrote:
> Matthias Maisenbacher <[EMAIL PROTECTED]> wrote:
[is using Debian]
> 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.
On Debian, /usr/include/linux and /usr/include/asm are regular
directories containing Debian-approved files, not symbolic links
as in the traditional arrangement. You may have to fiddle with
the "-I/directory" arguments given to the C compiler when building
the kernel support programs (including, perhaps, for "make dep").
(I believe that the flags are set correctly for building the
kernel proper.)
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Writing shared libraries
Date: 27 Jul 1999 15:32:32 GMT
Kevin Woodward <[EMAIL PROTECTED]> schrieb
am Tue, 27 Jul 1999 14:20:48 GMT in comp.os.linux.development.system:
KW> Thanks. From that I assume libx.a is a.out format and libx.so is for
KW> ELF?
No.
The .a file was created with "ar", it is a "Archive" or static library,
you may use this like this:
when libx.a is located in Dir "."
gcc -o my_program my_program.o -L. -lx
You can create a libx.a
ar -r libx.a object1.o object2.o object3.o
You can only identify a ELF or A.OUT binary type using
file "libx.a"
A .so File is a SharedObject.
mfG
Jojo
--
- Professionelle Linux Server, Professioneller Support und Dienstleistungen
- AutomatiX GmbH - Vollautomatische Kransteuerungen & SAP f�higes Lagerger�t
- J�rgen Sauer Neue Str. 11 28790 Schwanewede mailto:[EMAIL PROTECTED]
- +49 4209-4699 +49 172-5466499 FAX +49 4209 4644 http://www.automatix.de
------------------------------
From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 27 Jul 1999 14:03:48 -0400
[EMAIL PROTECTED] (bill davidsen) writes:
> Yeah, it's the other uses of int which might be a problem for
> performance on some applications. But the compiler using 64 bits for int
> and off_t would certainly allow more programs to work which aren't quite
> as well written.
why couldn't *long* be 64 bits? afaik there's nothing in the standard
for C that says that longs can only be 32 bits. the relevant file
functions like fseek and ftell already take longs in case your int is
only 16 bits. therefore a system which uses
int type bits
char 8
short int 16
int 32
long int 64
should be able to have large files and reasonably sized plain ints.
--
johan kullstam
------------------------------
From: [EMAIL PROTECTED]
Subject: reading damaged CDs
Date: 27 Jul 1999 20:07:29 GMT
It seems that in /usr/include/cdrom.h there's a way to make the cdrom
driver ignore bad blocks or at least not throw an EIO back when read(2)ing
a damaged block. How is this done?
--
David Griffith
[EMAIL PROTECTED]
------------------------------
From: "Elias Penttil�" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: ASCII to speech???
Date: Wed, 28 Jul 1999 01:07:33 +0300
Maybe this http://www.cstr.ed.ac.uk/projects/festival/ is interesting...
Elias
[EMAIL PROTECTED] wrote in message
<7nkjc5$t8s$[EMAIL PROTECTED]>...
>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
------------------------------
** 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
******************************
