Linux-Development-Sys Digest #487, Volume #6 Mon, 15 Mar 99 07:15:15 EST
Contents:
Some notes on glibc-2.1 and egcs-1.1.1 (Safuat Hamdy)
info about aio_read? (Raymond Li)
Re: kernel won't uncompress when boot from CD (Phil Howard)
Re: After Week 1 With Linux -- licking wounds. (Klaus-Georg Adams)
Re: what "rc" scripts exist for linux? (david parsons)
Re: The multi-billion $ Linux market ("Davorin Mestric")
Re: C++ wrappers around std APIs? (Juergen Heinzl)
Re: After Week 1 With Linux -- licking wounds. ("[EMAIL PROTECTED]")
Re: After Week 1 With Linux -- licking wounds. (Justin The Cynical)
Re: Linux programming jobs? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Some notes on glibc-2.1 and egcs-1.1.1
Date: Mon, 15 Mar 1999 07:47:06 GMT
Hi all,
I just built glibc-2.1 with egcs-1.1.1 and binutils 2.9.1 (running linux
2.2.1 on i586, built with egcs-1.1.1, too) as recommended. I noted some
very strange effect since then. Before I report a problem bug I'd like to
know whether other people had the same or similar observations.
1. make and make check yield no errors and make install said that the
installation is ok, but looking closer at the files the testprograms
produce I found failures:
$ find . -name "*.out" | xargs grep FAIL
./posix/runptests.out:regexp: "[^[.a.]b]", string: "abc" -> no match, FAIL
./posix/runptests.out:regexp: "[^[=a=]b]", string: "abc" -> no match, FAIL
./posix/runptests.out:regexp: "[][.-.]-0]", string: "ab0-]" -> no match, FAIL
./posix/runptests.out:regexp: "[c[.].]d]", string: "ab]cd" -> no match, FAIL
./posix/runptests.out:regexp: "[a-z]*[[.].]][A-Z]*", string: "Abcd]DEFg" -> no match,
FAIL
./posix/runptests.out:regexp: "[[.a.]b]", string: "Abc" -> no match, FAIL
./posix/runptests.out:regexp: "[[.a.]b]", string: "aBc" -> no match, FAIL
./posix/runptests.out:regexp: "[^[.a.]b]", string: "abc" -> no match, FAIL
./posix/runptests.out:regexp: "[][.-.]-0]", string: "ab0-]" -> no match, FAIL
./posix/runptests.out:regexp: "[A-[.].]c]", string: "ab]!" -> no match, FAIL
./posix/runptests.out:regexp: "[[.ch]]", string: "abc" -> compiling suceeds, FAIL
./posix/runptests.out:regexp: "[[.ab.][.CD.][.EF.]]", string: "yZabCDEFQ9" ->
compiling suceeds, FAIL
./posix/runptests.out:regexp: "[[=a=]b]", string: "Abc" -> no match, FAIL
./posix/runptests.out:regexp: "[[=a=]b]", string: "aBc" -> no match, FAIL
./posix/runptests.out:regexp: "[^[=a=]b]", string: "abc" -> no match, FAIL
./posix/runptests.out:regexp: "[[:alnum:]]*", string: " aB28gH" -> wrong match (0 to
0): FAIL
./posix/runptests.out:regexp: "[^[:alnum:]]*", string: "2 ,a" -> wrong match (0
to 0): FAIL
./posix/runptests.out:regexp: "[[:alpha:]]*", string: " aBgH2" -> wrong match (0 to
0): FAIL
./posix/runptests.out:regexp: "[[:digit:]]*", string: "a28" -> wrong match (0 to 0):
FAIL
./posix/runptests.out:regexp: "[[:punct:]]*", string: "a,2" -> wrong match (0 to 0):
FAIL
./posix/runptests.out:regexp: "[^[:space:]]*", string: " aB28gH, " -> wrong
match (0 to 0): FAIL
./posix/runptests.out:regexp: "[[:upper:]]*", string: "aBH2" -> wrong match (0 to 0):
FAIL
./posix/runptests.out:regexp: "[[:xdigit:]]*", string: "gaB28h" -> wrong match (0 to
0): FAIL
./posix/runptests.out:regexp: "[^[:xdigit:]]*", string: "a gH,2" -> wrong match
(0 to 0): FAIL
./posix/runptests.out:regexp: "[][.-.]-0]", string: "ab0-]" -> no match, FAIL
./posix/runptests.out:regexp: "[A-[.].]c]", string: "ab]!" -> no match, FAIL
./posix/runptests.out:regexp: "[a-ce-f", string: "dBCCdE" -> FAIL: Unmatched [ or [^
./posix/runptests.out:regexp: "[c[-xy]D", string: "ac-D+" -> no match, FAIL
./posix/runptests.out:regexp: "abc*XYZ", string: "890abccccccccXYZ#*" -> wrong match
(3 to 16): FAIL
./posix/runptests.out:regexp: "a\(b\)*c\1", string: "acb" -> no match, FAIL
./posix/runptests.out:regexp: "a\(b\)*c\1", string: "acb" -> no match, FAIL
./posix/runptests.out:regexp: "a\(b\(c\(d\(f\)*\)\)\)\4", string: "xYzabcdePQRST" ->
no match, FAIL
./posix/runptests.out:regexp: "\(a\)010\{1,2\}", string: "aaaabc" -> no match, FAIL
./posix/runptests.out:regexp: "\(\(a\)\1\)\{1,2\}", string: "aaaabc" -> no match, FAIL
./posix/runptests.out:regexp: "\([a-c]*\)\{2,\}", string: "abcdefg" -> wrong match (0
to 3): FAIL
./posix/runptests.out:regexp: "\^\[[[.].]]\\(\\1\\)\\*\\{1,2\\}\$", string:
"a^[]\(1\)\*\{1,2\}$b" -> no match, FAIL
./posix/runptests.out:regexp: "[[=*=]][[=\=]][[=]=]][[===]][[...]][[:punct:]]",
string: "*\]=.;" -> no match, FAIL
./posix/runptests.out:regexp: "[$\(*\)1]*", string: "$\()*^" -> wrong match (0 to 5):
FAIL
./posix/runptests.out:regexp: "\(*\)*\1*", string: "a*b*11" -> wrong match (0 to 0):
FAIL
./posix/runptests.out:regexp: "\(a\(b\{1,2\}\)\{1,2\}\)", string: "abbab" -> wrong
match (0 to 3): FAIL
./posix/runptests.out:regexp: "^[a-zA-Z]", string: "Nine99" -> wrong match (0 to 1):
FAIL
./posix/runptests.out:regexp: "[a-z]*$", string: "99ZZxyz99" -> wrong match (9 to 9):
FAIL
what does this tell me??
2. programms compiled with gcc-2.8.1 and glibc-2.0.6 which previously worked
well fail when recompiled with egcs-1.1.1 and glibc-2.1
here make (3.77) is a good example (but others exist, moc from Qt is another
one)
For instance, if want to recompile glibc-2.1, I get
$ make
make -r PARALLELMFLAGS="" CVSOPTS="" -C ../glibc-2.1 objdir=`pwd` all
make: *** [all] Segmentation fault
and that's all (I had to restore a previously compiled make from a backup).
Gotten more suspicious, I compiled make with CFLAGS=-g and run make under
control of gdb (4.16):
$ gdb make
...
(gdb) cd path/to/glibc/sources
(gdb) run
Starting program: /mnt/src/sources/LANG/make-3.77/make
/mnt/src/sources/LANG/make-3.77/make -r PARALLELMFLAGS="" CVSOPTS="" -C ../glibc-2.1
objdir=`pwd` all
make: *** [all] Segmentation fault
Program exited with code 02.
(gdb) bt
No stack.
(gdb)
Huh??? Now I've really not even the foggiest idea what went wrong.
But whatever it is, it is caused either by glibc-2.1 or egcs-1.1.1 (or both), since
nothing else
changed since then (besides the kernel, but the above behavior is invariant to the
kernel
version, as I checked this).
Did someone else made the same observations? Is there a way out of this uncomfortable
situation?
Btw.: Which feature test macro should be used to check the presence of glibc-2 (for
autoconf,
for instance)?
--
S. Hamdy | All primes are odd except 2,
[EMAIL PROTECTED] | which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
------------------------------
From: Raymond Li <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.development.apps
Subject: info about aio_read?
Date: Mon, 15 Mar 1999 00:43:55 -0800
Hello,
I am trying network programming in Linux. I wonder if asynchronus
i/os are supported in Linux. I can't find the man page for aio_read. Can
someone tell me some information are asynchronus i/o in Linux?
Thanks in advance for you advices.
Yours,
Raymond Li
------------------------------
From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: kernel won't uncompress when boot from CD
Date: Mon, 15 Mar 1999 09:36:50 GMT
On 15 Mar 1999 01:43:18 GMT H. Peter Anvin ([EMAIL PROTECTED]) wrote:
| Followup to: <kALG2.1735$[EMAIL PROTECTED]>
| By author: [EMAIL PROTECTED] (Phil Howard)
| In newsgroup: comp.os.linux.development.system
| >
| > On 13 Mar 1999 04:46:48 -0600 Peter Samuelson ([EMAIL PROTECTED]) wrote:
| >
| > | This is something syslinux is much better at than LILO. You put the
| > | kernel and the ramdisk image on a FAT floppy image, create a
| > | SYSLINUX.CFG file to suit, and run syslinux which installs LDLINUX.SYS
| > | and the boot block.
| >
| > Works fine on the real /dev/fd0. But syslinux doesn't handle /dev/ram.
| > It complains about the only blocksize being supported is 512. So I guess
| > the blocksize it is getting is probably 1024 and it doesn't like it.
| >
|
| No, syslinux complains because you need a DOS filesystem on the device
| before you can run syslinux on it. Try using mkdosfs, or cat an empty
| floppy image to /dev/ram0.
I did. syslinux truly will not operate on a ramdisk. It doesn't like
what it gets for the blocksize. However, looking at the source code with
the idea in mind of coding in a kludge to deal with ramdisk, I found it
already has a kludge to deal with loopback. So I switched gears and used
loopback instead of ramdisk. Now it works. Now I've successfully built
my own rescue CD which boots off the CD and runs from /dev/ram.
--
-- *-----------------------------* Phil Howard KA9WGN * --
-- | Inturnet, Inc. | Director of Internet Services | --
-- | Business Internet Solutions | eng at intur.net | --
-- *-----------------------------* phil at intur.net * --
------------------------------
From: Klaus-Georg Adams <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 15 Mar 1999 10:48:57 +0100
[EMAIL PROTECTED] (Jeff Szarka) writes:
>
> On Sun, 14 Mar 1999 15:53:47 -0500, [EMAIL PROTECTED] (Julian Thomas)
> wrote:
>
> :In <[EMAIL PROTECTED]>, on 03/14/99
> : at 05:33 PM, Sid Boyce <[EMAIL PROTECTED]> said:
> :
> :>Have you ever watched
> :>anyone trying to use Windows to copy a file to floppy for you ?, it's
> :>painful.
> :
> :No - Start - Programs - MS DOS prompt. CD to the directory, copy file a:
> :
> :Not even very hard if it's a long file name - copy 'long filename'
> :a:newfile
> :
>
>
>
> If you don't feel like moving to the directory just use:
>
> copy x:\path\file.ext x:\path
>
> Hard huh?
What really gets on my nerves when I have to do this in DOS is, that
the Tab key just doesn't work the way it is supposed to... (in bash
and emacs anyways). This leaves you with way too much typing or short
meaningless directory and filenames.
-- kga
=========================================================================
Klaus-Georg Adams Email: [EMAIL PROTECTED]
Institut f. Anorg. Chemie, Lehrstuhl II Tel: 49(0)721 608 3485
Universität Karlsruhe, D-76128 Karlsruhe
=========================================================================
------------------------------
From: o r c @ p e l l . p o r t l a n d . o r . u s (david parsons)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: what "rc" scripts exist for linux?
Date: 14 Mar 1999 21:31:38 -0800
In article <7c0d24$suf$[EMAIL PROTECTED]>,
M Sweger <[EMAIL PROTECTED]> wrote:
>
>Hi,
> I was just wondering what types of "rc" scripts exist out there for
>Linux and what tar file names they go by? I.E SysV vs. BSD style.
>Presently Redhat seems to use SysV whereas slackware uses BSD. I'll
>assume there is also a version that is a cross between SysV and BSD
>for linux.
>
> I'm trying to rebuild the Linux system from the ground up, but don't
>know the "rc" script package names or which of the ways is best.
It depends on what you're trying to do.
The BSD-style one that Slackware uses has one master rc file
that explicitly calls in other rc files to configure various
subsystems. This has the advantage of being traditional.
The SysV-style one that Redhat, et alii, use has a collection of rc
directories that contain rc files that start up (and stop) various
services, These files are named S<number><name> and
K<number><name>, and the master rc script walks through them in
numeric order (via something like for rc in S*; ...) to start or
kill services. This has the advantage of it being really easy to
add new services, though it has the disadvantage that you have to
hand-sort the services so that they won't start before their
prerequisites.
There are other schemes that try to get around this disadvantage of
SysV rc services, though they are pretty much experimental. One
of these -- the rc scheme that my research distribution Mastodon[1]
uses has a bunch of rc directories containing rc files, just like
SysV, but instead of ordering them by name, the rc files call in
the prerequisites they need (cf: UCSD Pascal `uses' statement) at
runtime, and remembers the order that each services was started so
it can shut those services down in order later. This has the
advantage that you don't need to give them special names, but it
has the decided disadvantage that it's not traditional and NONE
of the various Unix howto books and FAQs will help a novice
system administrator with it. Other people have RC setups that
are somewhat like this, but using different threading schemes
and file formats (which I have to be vague about, because it's
been a while since I've see one of the schemes.)
If you're planning to build a distribution, consider your audience.
SysV and BSD-style are probably split 50/50 in influence, but SysV
is MUCH better laid out and is a lot easier to tweak to fit. If
your audience is Unix literate, you should choose one of these. If
your audience is NOT Unix literate, you should also choose one of
these, because eventually something will go wrong that they'll have
to poke around in the RC files to fix, and it's much better to give
them a format that's documented. If, however, you're doing it for
your convenience or are aiming it at people who don't give a fuck
about Tradition!, I'd <BLATANT SELF-PROMOTION> suggests the
Mastodon[1] style because it's about as unlike the traditional Unix
rc as you can get while still using files </BLATANT SELF-PROMOTION>.
____
david parsons \bi/ [1: Blatant self-promotion:
\/ http://www.pell.chi.il.us/~orc/Mastodon/
INST0039 is about to be dug out of the
tar pit that is my spare time.]
------------------------------
From: "Davorin Mestric" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: The multi-billion $ Linux market
Date: Mon, 15 Mar 1999 01:16:16 +0100
James Kelley wrote in message <[EMAIL PROTECTED]>...
>IBM, Oracle, Sybase, SUN, HP, Corel, Informix,
>etc. etc. etc. KNOW AND UNDERSTAND the threat the MS monopoly has on the
>software industry as a whole.
And none of them cares about it! ('It' being 'the threat the MS [.] has
on the [.] whole')
They care only about their asses.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: C++ wrappers around std APIs?
Date: Sun, 14 Mar 1999 19:29:16 GMT
In article <[EMAIL PROTECTED]>, Michael Schuerig wrote:
>Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>> [EMAIL PROTECTED] (Michael Schuerig) writes:
>>
>> > I'm looking for C++ wrappers around standard and common Linux APIs. Any
>> > pointers to things I ought to have a look at?
>>
>> http://www.cs.wustl.edu/~schmidt/ACE.html
>>
>> It may be overkill for your purposes though.
>
>No, ACE just doesn't do what I'm looking for. ACE is a communication
>environment. What I'm thing of are wrappers around file access,
>passwords, signal handling, processes.
None known ... what for BTW, code bloat ? No really, where's the beef ? You
hide one interface by another and so either loose some options or end up
with having to learn two.
Some stuff, like signal handling ... well, tricky since, just an example.
your are not to do much within a signal handler anyway. Processes ... not
much to say, you fork(), you wait(), that's it (more or less). Yes, this
is meant a bit as criticism because I've seen just that "let's wrap it all
up in C++ since C++ is the way to go now ... blah". In the end this does
not work or that is not supported yet and one has to code around it. It
just gets in the way. "Oh **** ... pipes not supported yet ... or they are
supported but do not work on some system, so back to recoding class X ... but
taking care of not breaking it". Hey, I want BSD signal semantics on this
system ... "sorry, SYSV support only" ... oh, thank you very much.
Quite a lot is available already, iostream, the STL (I love it), well done
but take the STL as an example. It is extensible just because it is not just
a wrapper around existing stuff.
Just the to be ignored 0.05,
Juergen
--
\ Real name : Jürgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
\ Phone Private : +44 181-332 0750 \ /
------------------------------
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: Mon, 15 Mar 1999 10:19:36 +0000
Reply-To: [EMAIL PROTECTED]
Jeff Szarka wrote:
>
> is so hard about making a simple gui ? Even nt 3.51 has a MUCH better
> montior/video setup then linux.
>
> The other thing that annoyed me about linux was the way windows went
> off the screen, making it impossible to close them or move them.
This is not a fault of Linux. The OS itself has absolutely nothing to do
with the problem you described. Why don't people get this straight? The
concept is not that hard.
------------------------------
From: [EMAIL PROTECTED] (Justin The Cynical)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 15 Mar 1999 12:00:06 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 13 Mar 1999 13:53:23 -0600, Rupert K. Snoopowitz
<[EMAIL PROTECTED]> wrote:
[snip]
->I am a long time NT user and fan, and before that a big Mac guy -- ever
I have come from a Commodore VIC 20, then a 64, then a 128, and played
with the CPM that come with the 128. MS-DOS 3.3 and MS Windows 2.x
[snip]
->But Unix is not a modern OS. It is an extension of 20 year old
->philosophies when it comes to computing and UI, and this is one of the
Define modern. If you are talking about a nice shiny clicky-clicky
interface, then you are incorrect. Linux, and virtually and *NIX-like system,
have many of the things that 'modern' OS's have. And as others have said, the
UI is not the OS.
->reasons NT (as bad as it may be) has taken such a huge bite out of the
->Unix market.
This point we disagree on. M$ has market share due to it's *very*
aggressive marketing department.
->This is not to say Unix sucks. At the core, it is a great OS -- very
->reliable, fast, and powerful. But it cannot be reasonably approached by
->anyone but the most savvy and even still, takes considerable time to
->become educated on and gain a reasonable working ability with.
Not really. My first taste of Linux was an old Slackware distro.
The March 1995 Infomagic distro to be exact. I played with it for a while,
then removed it from my drive. I did not have any contact with it for some
years, but still read everything I could on how *NIX works and the 'tweaks'
that made Linux different. I obtained a drive for my system, and installed
Slackware 3.5 on it. This was a few months ago. In fact, Slackware 3.6 came
out very shortly after I installed 3.5. I was able to set up the OS and get
most of everything running within a few days. The things that are not working
like I would like them (MIDI using the wavetable on my AWE64, for example) are
things that I don't place a high importance on and have not bothered to get
working as of yet. It's not from a lack of documentation, it's from a lack of
getting around to it. Now, it is not easy to get a 'working ability' with
something when one has no actuall contact with it, especially with a moving
target like Linux. However, I was able to make it work. Perhaps you were
trying to install the 'wrong' distro?
->Lets keep what happens in the sausage factory out of sight of the
->customers, OK? I should not have to figure out how to use VI, where some
->strange configuration file is, blah blah just to get my system to work.
And why not? A computer is not an appliance, it is a tool. You
wouldn't expect someone to just plug in an electric chainsaw without some
kind of understanding of how it works.
->I shouldn't ever need to know what a Kernel even IS, unless I was
->directly interested in how my OS works under the hood. I should be able
So, does this apply to Win 95 as well? Don't forget, there is multiple
versions of 95, with various problems of 'compatibility' between them. So, if
a person wants to install X piece of hardware, they should use any instructions
that come with the hardware, never mind that there usually is two lists of
instructions for installing under Win95... Retail and OSR2.
->to point, click click click and have my system up and running as quickly
->as possible. I should not have to manually adjust my monitor, being
->constantly warned that "improper use may result in damaging your
->monitor". I should be able to select 1024x768 @ 70 hz, 24 bit color from
->a simple control panel (without fear). I should not have to figure out
I'd rather have it warn me that it _might_ happen than have the Win
version that doesn't give me any warning at all what might happen if I choose
the wrong settings. Now, Win doesn't have any way for a person to overdrive
a monitor, _provided the correct video card and monitor combo is chosen_!
I can't remember the number of Win systems I've seen that either have the
wrong monitor chosen, or don't have one at all (unknown monitor)! That
situation does leave the door open for overdriving a monitor.
->how to use a shell unless I feel the need that I have to. I should not
->have to spend hours pouring through documentation just to figure out how
->my OS wants its hard drive partitioned. I should not have to know
->anything about hard drive cylinders to tell my OS "i want a 2 gig
->partition here and a 1 gig partition there".
Really? Then you haven't tried to set up Win95/98, or to a lesser
degree NT, from a clean, blank disk, have you? You do have to know how
to partition a drive. So take your agrument to Microsoft as well.
--
"NT disk, meet Mr. Microwave."
David Parsons in comp.os.linux.advocacy (e-mail addy deleted for spam reasons)
Justin The Cynical - [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Linux programming jobs?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 15 Mar 1999 12:01:36 GMT
Glen Wiley <[EMAIL PROTECTED]> writes:
>Have you looked at the HUGE number of UNIX only jobs in the US. There
>is a severe shortage of engineers that can work with UNIX but can't
>spell Microsoft.
Darn! My superior education trips me up again. Oh, if only I had never
learned how to spell Macrosoft! Uhm, that Mircosoft. I mean Microfrost.
Damn, Miocrosft.
Well, anyway --- how do those jobs pay?
Bernie
--
============================================================================
"It's a magical world, Hobbes ol' buddy...
...let's go exploring"
Calvin's final words, on December 31st, 1995
------------------------------
** 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
******************************
