Linux-Development-Sys Digest #702, Volume #7 Fri, 24 Mar 00 00:13:17 EST
Contents:
Re: Zero padding in sprintf() doesn't work for strings - HELP ! (Stephen Richards)
Re: Driver? (Grant Edwards)
Re: Absolute failure of Linux dead ahead? (Matthias Warkus)
Re: ioctl block pthread_create ?? (Roger A. Faulkner)
Re: poll()ing TCP sockets - when can I expect a POLLHUP? (Andi Kleen)
Re: gcc problems (Frank Johnson)
Re: kernel in C++ ("AliMac")
Re: Absolute failure of Linux dead ahead? (Mario Klebsch)
Gnumeric compile help needed. ("Charles Sullivan")
Re: Absolute failure of Linux dead ahead? (Warren Young)
POSIX timer implementation available. (Kaz Kylheku)
POSIX timer implementation available. (Kaz Kylheku)
Re: moderm card! ("Ross Crawford")
Changing symbols in ELF binaries (Eric Buddington)
probs w/ USB 2.3.51 backport to 2.2.14 kernel (Peter Freeman)
Problem with SSLEay Module for Linux - Pls help ASAP ("Vasundhara Padmanabhan")
Modular booting ("D. Stimits")
----------------------------------------------------------------------------
From: Stephen Richards <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Zero padding in sprintf() doesn't work for strings - HELP !
Date: Thu, 23 Mar 2000 14:58:02 +0000
Reply-To: Stephen Richards <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>, Gerd Buesken
<[EMAIL PROTECTED]> writes
>Hi
>
>I have a problem using gcc 2.95 running on a 2.2.5-15 Red Hat linux.
>
>Regarding sprintf, the man pages say:
>0 specifying zero padding. For all conversions except n, the
>converted value is padded on the left with zeros rather than blanks.
>If a precision is given with a numeric conversion (d, i, o, u, i, x,
>and X), the 0 flag is ignored.
>
>My source looks like this:
>
>include <stdio.h>
>
>main()
>{
> char buff[30];
> char LenBuf[30];
>
> strcpy(LenBuf,"1");
> sprintf (buff,"%06s", LenBuf);
> printf( "buffer=%s; Length %06d\n",buff, strlen(LenBuf) );
>}
>
>This is the Linux output:
>buffer= 1; Length 000001
>
>This is the HP-UX output:
>buffer=000001; Length 000001
>
>It seems as if the output on Linux is wrong(using Blanks instead of zeros).
>
>Does anybody has a solution other than rewriting the code ?
>
I'm afraid that the %06s doesn't work as you expect. The 0 is a flag in
the formatting rules and indicate a padding of 0's from the left.
However this only applies to numeric field types %d, %f et al.
Keeping buff as a int (assuming it will always be numeric) with resolve
the problem, using %06d.
Stephen.
|-----------------------------\\-----------------------|
| Stephen Richards \\ SAR Computing Ltd |
| [EMAIL PROTECTED] \\ |
|________________________________\\____________________|
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: Driver?
Date: Thu, 23 Mar 2000 18:45:48 GMT
In article <[EMAIL PROTECTED]>, Shawn Halwes wrote:
>I tried all the standard SCSI cdrom drivers that came with the Red Hat
>(Cartman) relaease...
What do you mean "all"?
I'm only aware of one SCSI cdrom driver. AFAIK, the only SCSI
cdrom driver (at least since the days of 0.99.x) is
/usr/src/linux/drivers/scsi/sr.c
What have you been trying to use?
--
Grant Edwards grante Yow! .. the HIGHWAY is
at made out of LIME JELLO and
visi.com my HONDA is a barbequed
OYSTER! Yum!
------------------------------
From: [EMAIL PROTECTED] (Matthias Warkus)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 23 Mar 2000 19:34:51 +0100
Reply-To: [EMAIL PROTECTED]
It was the Thu, 23 Mar 2000 05:27:45 GMT...
...and Christopher Browne <[EMAIL PROTECTED]> wrote:
> Centuries ago, Nostradamus foresaw a time when The Ghost In The
> Machine would say:
> >In comp.os.linux.advocacy, SetMeUp <[EMAIL PROTECTED]>
> >wrote on Wed, 22 Mar 2000 19:43:06 GMT
> ><en9C4.1872$[EMAIL PROTECTED]>:
> >>> What's wrong with Modula-3? ;)
> >>
> >> It's wrong that it is not C.
> >
> >Hmm..."Not C"...um...is that close enough to Godwinize this thread? :-)
> >
> >Mind you, I do know at least two operating systems (Apollo/DOMAIN Aegis
> >and older versions of MacOS) which were written in Pascal, or some
> >variant thereof, so I guess it could work... :-)
>
> The problem with Pascal, as distinct from the others, is that the
> design just wasn't made for anything more than education.
>
> a) It defines a single pass compiler;
> b) It provides no way of splitting projects coherently into multiple
> files;
> c) The typing system doesn't cope all that well with dynamic arrays.
d) No casts
e) No pointers to functions AFAIK
f) Functions can't return complex data types AFAIK
g) No equivalent to void * (typeless pointer)
h) No escape sequences inside string literals
i) No real equivalent to malloc() (you can't allocate an arbitrary
chunk of memory, just chunks that are the size of a defined data
type)
That are the issues I've had with Turbo Pascal, and I understand that
ANSI Pascal is even more anemic. However, I'm glad that I acquired a
fairly strict programming style with Pascal before I switched to C.
mawa
--
Manchmal f�hle ich mich im Usenet wie eine Kreuzung aus Don Giovanni
und dem Zauberlehrling; w�hrend es um mich herum unkontrollierbar
wuselt, weil ich etwas losgetreten habe, m�chte ich rufen "Genug!
Genug!", und darauf warten, da� der Teufel mich holt. -- mawa
------------------------------
From: [EMAIL PROTECTED] (Roger A. Faulkner)
Crossposted-To: comp.unix.programmer,comp.unix.questions,comp.unix.solaris
Subject: Re: ioctl block pthread_create ??
Date: 23 Mar 2000 19:09:21 GMT
In article <[EMAIL PROTECTED]>,
Nathan Krasney <[EMAIL PROTECTED]> wrote:
>Hello all
>
>i have very strange phenomenon. i have a user mode application that talk
>to a file system driver via ioctl. this ioctl is envoked by user mode
>thread , problem is that creation of a new thread is suspended by the os
>until this ioctl return !!!
>
>e.g.
>main()
>{
> pthread_create run f1()
> pthread_create run ioctl
> pthread_create run f2()
> while(1)
> ......;
>}
>
>f1 will continue to run independently but f2 will NOT start running
>until the ioctl has return !!
>
>what can possibly be the problem ???
This is not a problem with the ioctl(), it is a (bad) behavior
of libthread.
Either create your threads with the PTHREAD_SCOPE_SYSTEM attribute
or call pthread_setconcurrency() to tell libthread how many LWPs
you want to have running at once (before calling pthread_create()).
Roger Faulkner
[EMAIL PROTECTED]
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: poll()ing TCP sockets - when can I expect a POLLHUP?
Date: 23 Mar 2000 21:32:38 +0100
[EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer) writes:
> Andi Kleen <[EMAIL PROTECTED]> writes:
>
> >[EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer) writes:
>
> >> >Single Unix does not require it:
> >>
> >> > POLLIN
> >> > Data other than high-priority data may be read without
> >> > blocking. For STREAMS, this flag is set in revents even if the
> >> > message is of zero length.
> >>
> >> I'm referrng to setting POLLHUP, that is a bug (if the local
> >> end isn't closed)
>
> >It is only set when the local end point is closed.
>
> I.e, when a half-close is done a filedescriptor that is subsequently polled
> and the other end has send a FIN?
s/and/or/
In Linux 2.3 it was changed to only send POLLHUP when both ends are closed
(FIN acked), this is to avoid problems with poll for CLOSE_WAIT socket.
>
> If you're talking about a loopback connection where the other end has done a
> close, I maintain it is still in error to signal POLLHUP
I'm not sure what you mean with a loopback connection here. If you assume
that Linux has some special cases in TCP for the loopback device you're
wrong.
-Andi
------------------------------
From: Frank Johnson <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.powerpc,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: gcc problems
Date: Thu, 23 Mar 2000 19:11:21 +0000
[EMAIL PROTECTED] wrote:
> Hi,
> I am having trouble with the postgres configure program, which requires gcc
> to be able to compile programs. As configure was performing its checks, it
> failed when it claimed, 'gcc is not able to compile executables'.
> OK, this is problem number 1.
> I didn't know why this was, so I tried to compile a simple printf() to make
> sure the compilers really weren't working properly. Then I got an error from
> the compiler saying it couldn't find stdio.h. Yes, I did #include <stdio.h>
> properly.
I suffered exactly the same problem when I installed RH6.0. It turned out
that I did not have the correct libraries/programs loaded. Unfortunately I
can't tell you which ones because I gave up looking and upgraded my install
and selected everything that could possibly have anything to do with egcs.
Sorry I can't be of more help.
--
Frank Johnson
------------------------------
From: "AliMac" <[EMAIL PROTECTED]>
Subject: Re: kernel in C++
Date: Thu, 23 Mar 2000 21:55:58 -0000
> 4.a kernal should be spelled kernel. ;)
>
> > new
> > destroy
> > start
> > stop
> > and all other functionality should be done by .so modules autoloading
as
> >virtual device drivers.
>
> Except these drivers have no way to call anything useful in their host
> because it only provides new, destroy, start, stop. ;)
>
these device drivers provide the callable functionality!!
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 23 Mar 2000 22:52:45 +0100
[EMAIL PROTECTED] (Matthias Warkus) writes:
>> The problem with Pascal, as distinct from the others, is that the
>> design just wasn't made for anything more than education.
>...
>e) No pointers to functions AFAIK
At least they were possible as arguments to function/procedure
calls. I am not sure, wether they are possible as stand alone
variables or as structure members. However, there were a lot pascal
compilers in use, that did not implement procedure arguments.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: "Charles Sullivan" <[EMAIL PROTECTED]>
Subject: Gnumeric compile help needed.
Date: Thu, 23 Mar 2000 17:37:14 -0500
I've been trying to recompile the Gnome 'gnumeric' spreadsheet
program without success. Advice from anyone who has successfully
accomplished this will be greatly appreciated.
I am running Red Hat 6.0 which I installed from the Cheapbytes
CD. I also have the corresponding source code CD from the same
vendor. The as-installed executable /usr/bin/gnumeric (v.23)
runs satisfactorally under Gnome, but I wanted to make a minor
modification.
The first thing I did was rpm'd the gnumeric (v.23) source code from
the CD and attempted to rebuild the executable without modification.
Following the instructions in the INSTALL file, I first ran the
command:
./configure --prefix=/usr
(the switch is to force it to install the executable into /usr/bin
and overwrite the original, rather than in the default location
/usr/local/bin).
I then ran the commands:
make
make install
The executable was installed in the right place, but I notice it
is several time larger than the original, and when I try to
execute it from within Gnome I get a Segmentation Fault.
(I tried downloading the latest version: gnumeric-0.9.tar.gz,
gnome-libs-1.0.57.tar.gz, and libxml-1.8.7.tar.gz and rebuilding
all these per instructions, but with the same result when I tried
to execute the program.)
Any ideas?
Regards,
Charles Sullivan [EMAIL PROTECTED]
------------------------------
Date: Thu, 23 Mar 2000 16:34:39 -0700
From: Warren Young <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Dale Pontius wrote:
>
> How about Ada?
[snip]
> I know none of this language shift will likely ever happen. To go
> from a model much different from C, you'd have to spend a LONG time
> reimplementing -
An observation:
Even C++, the closest cousin of C available, gets shunned a lot.
Several Open Source projects started in C++ and were later converted to
C, not because of the language itself, but to get more outside
developers. Consider also projects like Glade, which builds C code by
default: there's an addon (glade-- - note the "--" ha-ha-only-kidding
suffix) that does C++ code, but it lags behind the C version.
Face it, there's a prejudice in favor of C. It can't be considered
anything other than prejudice, because logical arguments in favor of
other languages fail regularly.
--
= Warren -- See the *ix pages at http://www.cyberport.com/~tangent/ix/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: POSIX timer implementation available.
Reply-To: [EMAIL PROTECTED]
Date: Fri, 24 Mar 2000 00:17:02 GMT
An implementation of the posix clock_* and timer_* functions is available at
http://users.footprints.net/~kaz/posixtimer.html.
Everything seems to work, except areas where there isn't enough support (no
sigqueue(), no support for new style signal handlers. timer_getoverrun() always
returns zero).
The clock_* functions basically augment gettimeofday() and friends, and work
with struct timespec instead of struct timeval.
The POSIX timer interface is a way to have signals delivered after a time
delay, with the option for retriggering. More importantly, the timer expiry
notifiation can be done in a separate thread rather than by delivery of a
signal. The interface allows the user to specify what attributes the timer
thread should have (e.g. priority).
I don't have this neatly packaged, and you may find that some of the
definitions in public.h conflict with <signal.h>. The idea behind this
release is to get some feedback.
The interface spec documentation for this is just The Single UNIX
Specification, a draft of which can be browsed online at
http://www.opengroup.org/onlinepubs/7908799/
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: POSIX timer implementation available.
Reply-To: [EMAIL PROTECTED]
Date: Fri, 24 Mar 2000 00:18:35 GMT
An implementation of the posix clock_* and timer_* functions is available
at http://users.footprints.net/~kaz/posixtimer.html.
Everything seems to work, except areas where there isn't enough support (no
sigqueue(), no support for new style signal handlers. timer_getoverrun()
always returns zero).
The clock_* functions basically augment gettimeofday() and friends,
and work with struct timespec instead of struct timeval.
The POSIX timer interface is a way to have signals delivered after a time
delay, with the option for retriggering. More importantly, the timer expiry
notifiation can be done in a separate thread rather than by delivery of a
signal. The interface allows the user to specify what attributes the timer
thread should have (e.g. priority).
I don't have this neatly packaged, and you may find that some of the
definitions in public.h conflict with <signal.h>. The idea behind this
release is to get some feedback.
The interface spec documentation for this is just The Single UNIX
Specification, a draft of which can be browsed online at
http://www.opengroup.org/onlinepubs/7908799/
--
#exclude <windows.h>
------------------------------
From: "Ross Crawford" <[EMAIL PROTECTED]>
Subject: Re: moderm card!
Date: Fri, 24 Mar 2000 11:43:41 +1000
hi sang,
sang <[EMAIL PROTECTED]> wrote in message
news:8b4kd7$mc7$[EMAIL PROTECTED]...
> I have a moderm card inside computer. How do I setup it in linux?
> Because it does not connect with com1 or com2.
>
Have you successfully used the card with Windoze? If so, you should be able
to find out from there. Try com3 & com4. I have my internal modem card set
at com4, which is /dev/ttyS3 in Linux. You may also have to fiddle with
interrupts & io addresses.
Good Luck
ROSCO
------------------------------
From: [EMAIL PROTECTED] (Eric Buddington)
Subject: Changing symbols in ELF binaries
Reply-To: [EMAIL PROTECTED]
Date: Fri, 24 Mar 2000 00:39:26 GMT
I want to find or write a utility that will take
an ELF executable and modify its compiled-in paths.
>From what I've read so far of libbfd, this seems
possible, but I can't find much good documentation.
Anyone know if this has been done, or where I could
get myself edificated?
-Eric
------------------------------
From: Peter Freeman <[EMAIL PROTECTED]>
Subject: probs w/ USB 2.3.51 backport to 2.2.14 kernel
Date: Fri, 24 Mar 2000 02:30:08 GMT
Hi all
My current system is running Mdk 7.0 with kernel 2.2.14mdk.
I've recompiled the kernel a couple times from the sources off the Mdk cd,
with no problems at all (except for performance improvements)
I have a Roadster II usb modem which I was able to power up and recognize
as a device on a PC with kernel 2.3.43 running under Redhat 6.
With this success, I downloaded the backported USB kernel code from
http://www.suse.cz/development/usb-backport/
and patched the 2.2.14mdk sources.
This was successful, the new drivers appeared in xconfig and off I went.
Only problem is that make zImage crashes when it attempts to compile the
uhci.o driver.
I dont have the error msgs here right now as I'm doing this from work but I
can get the msg if need be.
Just wondering if anyone has had any similar trouble or success with the
backport??
Regards
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
From: "Vasundhara Padmanabhan" <[EMAIL PROTECTED]>
Subject: Problem with SSLEay Module for Linux - Pls help ASAP
Date: Fri, 24 Mar 2000 11:09:59 +0800
Hi
I am trying to install the SSLeay package version 0.6.3 . I downloaded
this package from the perl site (perl.org).
I get the follwing errors when I execute the foll commands.
> make
> make test
[...]
./ssltest -server_auth -CApath ../certs
server authentication
depth=0 error=19 /C=AU/SP=QLD/O=Mincom Pty. Ltd./OU=CS/CN=SSLeay demo
server
ERROR in CLIENT
make[1]: *** [tests] Error 1
make[1]: Leaving directory `/PerlIns/SSLeay-0.6.3/test'
make: *** [tests] Error 2
Could someone pls help me in resolving this.
Thanks in advance
Vasundhara
------------------------------
Date: Thu, 23 Mar 2000 21:22:21 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Modular booting
I have a machine that I've decided to dedicate to testing and
debugging, including different distributions, applications, kernel
setups, X servers, hardware drivers, and so on. The hard drive itself
is even removable, to slap in a new one with a different distribution
whenever I choose (IDE's are about as cheap as ZIP disks now). I'll be
adding a removable IDE slot on a 2nd machine as well, to test moving
of software from one machine to another (different chipsets, hardware
brands, so on), and watching for bugs that stay versus going away on
different hardware/PCI slot orders. It allows an incredible
flexibility, without altering my normal, everyday setup.
While the use of lilo and floppies for boot easily allows a large
number of kernels to be booted, there is a dilemma for System.map.
lilo.conf seems to not be able to set this to alternate file names or
locations. The kernel's top level Makefile has the parameter
INSTALL_PATH, which is normally commented out. The comment next to it
says that normally install is to the root directory, yet I've always
put it in /boot/ along with my new kernel (lilo must not care about
this); this results in the symbols matching, and it works, so this
parameter must not actually be compiled into the kernel (it appears to
look for it in the same directory as the kernel). If I want to boot
other kernels, I end up with a symbol mismatch, since the System.map
doesn't match. With all of my kernels (with slight renaming such as
date of compile appended) and System.map files (also slight renaming)
in a single directory, lilo points just fine at the various kernels,
named via the "image=..." line. On the other hand, I have to move a
sym link to the individual System.map file each time, before I reboot.
To make this more modular, would there be any problem with placing
each kernel and System.map file pair in a subdirectory to /boot/ ?
Assuming map=/boot/map and install=/boot/boot.b remain in /boot/ ? Is
there any need to alter the kernel source top level Makefile
INSTALL_PATH setting to match each kernel's actual location, assuming
I manually copy the kernel and System.map to a subdirectory of /boot/
?
Is there some alternative that might be better than subdirectories of
/boot/ ?
Thanks!
D. Stimits, [EMAIL PROTECTED]
------------------------------
** 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
******************************
