Linux-Development-Sys Digest #555, Volume #6 Wed, 31 Mar 99 10:15:20 EST
Contents:
Re: 2.2.[2,3] cannot mount MO devices (Juergen Koslowski)
Re: Some notes on glibc-2.1 and egcs-1.1.1 (Horst von Brand)
Re: Struct Padding (Larry Blanchard)
Re: CodeWarror for Linux (was: Re: Programming tools for ...) (Donal K. Fellows)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Donal K.
Fellows)
Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC. (Johan Kullstam)
Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0 (Joseph L. Wood, III)
Re: [ANN] CodeWarrior for Red Hat Linux (Sid Boyce)
problems removing linux from my Hard Disk ("David Bryan")
EGCS and Stack? (Andreas Jusek)
Re: x86 PC emulator for x86 PC??? ("Sascha Bohnenkamp")
Re: how to load ram disk from LILO? (Villy Kruse)
lex/flex grief (Tony Scholes)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Juergen Koslowski)
Subject: Re: 2.2.[2,3] cannot mount MO devices
Date: 31 Mar 1999 11:23:18 GMT
As indicated yesterday, it is indeed a software problem that prevents
my CD-ROM drive to find media. It works under 2.2.3, but not under
2.2.4 and 2.2.5. Strangely enough, under 2.2.4, workman started
alright, although data-cds were not recognized. But under 2.2.5,
workman also crashes with the message "no medium found". Below is
the relevant syslogin file, maybe someone can guess which changes in the
latest kernels may be responsible? My CD-writer is not affected at all.
It works under all three kernels, 2.2.3, 2.2.4 and 2.2.5. Strange!
Cheers,
-- J"urgen
Mar 31 00:42:32 localhost kernel: Linux version 2.2.5 (root@joanne) (gcc version
egcs-2.91.60 19981201 (egcs-1.1.1 release)) #47 Mon Mar 29 20:00:23 CEST 1999
Mar 31 00:42:32 localhost kernel: Detected 132634408 Hz processor.
Mar 31 00:42:32 localhost kernel: Console: colour VGA+ 80x25
Mar 31 00:42:32 localhost kernel: Calibrating delay loop... 52.84 BogoMIPS
Mar 31 00:42:32 localhost kernel: Memory: 63308k/65536k available (920k kernel code,
408k reserved, 868k data, 32k init)
Mar 31 00:42:32 localhost kernel: CPU: Intel Pentium 75 - 200 stepping 0b
Mar 31 00:42:32 localhost kernel: POSIX conformance testing by UNIFIX
Mar 31 00:42:32 localhost kernel: PCI: PCI BIOS revision 2.10 entry at 0xfbd20
Mar 31 00:42:32 localhost kernel: PCI: Using configuration type 1
Mar 31 00:42:32 localhost kernel: PCI: Probing PCI hardware
Mar 31 00:42:32 localhost kernel: Starting kswapd v 1.5
Mar 31 00:42:32 localhost kernel: <Sound Blaster 16 (4.13)> at 0x220 irq 5 dma 1,5
Mar 31 00:42:32 localhost kernel: <Sound Blaster 16> at 0x330 irq 5 dma 0
Mar 31 00:42:32 localhost kernel: scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast
SCSI) 5.1.10/3.2.4
Mar 31 00:42:32 localhost kernel: <Adaptec AIC-7880 Ultra SCSI host adapter>
Mar 31 00:42:32 localhost kernel: scsi : 1 host.
Mar 31 00:42:32 localhost kernel: Vendor: FUJITSU Model: M2934Q-512 Rev:
0138
Mar 31 00:42:32 localhost kernel: Type: Direct-Access ANSI
SCSI revision: 02
Mar 31 00:42:32 localhost kernel: Detected scsi disk sda at scsi0, channel 0, id 0,
lun 0
Mar 31 00:42:32 localhost kernel: Vendor: TOSHIBA Model: CD-ROM XM-5401TA Rev:
3605
Mar 31 00:42:32 localhost kernel: Type: CD-ROM ANSI
SCSI revision: 02
Mar 31 00:42:32 localhost kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3,
lun 0
Mar 31 00:42:32 localhost kernel: Vendor: HP Model: HP35480A Rev:
T503
Mar 31 00:42:32 localhost kernel: Type: Sequential-Access ANSI
SCSI revision: 02
Mar 31 00:42:32 localhost kernel: Detected scsi tape st0 at scsi0, channel 0, id 5,
lun 0
Mar 31 00:42:32 localhost kernel: Vendor: TEAC Model: CD-R55S Rev:
1.0K
Mar 31 00:42:32 localhost kernel: Type: CD-ROM ANSI
SCSI revision: 02
Mar 31 00:42:32 localhost kernel: Detected scsi CD-ROM sr1 at scsi0, channel 0, id 6,
lun 0
Mar 31 00:42:32 localhost kernel: scsi : detected 1 SCSI tape 2 SCSI cdroms 1 SCSI
disk total.
Mar 31 00:42:32 localhost kernel: SCSI device sda: hdwr sector= 512 bytes. Sectors=
8506782 [4153 MB] [4.2 GB]
Mar 31 00:42:32 localhost kernel: Partition check:
Mar 31 00:42:32 localhost kernel: sda: sda1 < sda5 sda6 sda7 sda8 sda9 sda10 sda11
sda12 >
Mar 31 00:42:32 localhost kernel: VFS: Mounted root (ext2 filesystem) readonly.
Mar 31 00:42:32 localhost kernel: Freeing unused kernel memory: 32k freed
Mar 31 00:42:32 localhost kernel: sr0: CDROM (ioctl) error, command: 0x00 00 00 00 00
00
Mar 31 00:42:32 localhost kernel: extra data not valid Current error sr00:00: sns = 70
3
Mar 31 00:42:32 localhost kernel: ASC=57 ASCQ= 0
Mar 31 00:42:32 localhost kernel: Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00
0x0a 0x00 0x00 0x00 0x00 0x57 0x00 0x00 0x00
Mar 31 00:42:32 localhost kernel: sr0: CDROM (ioctl) error, command: 0x00 00 00 00 00
00
Mar 31 00:42:32 localhost kernel: extra data not valid Current error sr00:00: sns = 70
3
Mar 31 00:42:32 localhost kernel: ASC=57 ASCQ= 0
Mar 31 00:42:32 localhost kernel: Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00
0x0a 0x00 0x00 0x00 0x00 0x57 0x00 0x00 0x00
Mar 31 00:42:32 localhost kernel: SCSI error: host 0 id 3 lun 0 return code = 28000002
Mar 31 00:42:32 localhost kernel: ^ISense class 7, sense error 0, extended sense 3
Mar 31 00:42:32 localhost kernel: sr0: CDROM (ioctl) error, command: 0x00 00 00 00 00
00
Mar 31 00:42:32 localhost kernel: extra data not valid Current error sr00:00: sns = 70
3
Mar 31 00:42:32 localhost kernel: ASC=57 ASCQ= 0
Mar 31 00:42:32 localhost kernel: Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00
0x0a 0x00 0x00 0x00 0x00 0x57 0x00 0x00 0x00
Mar 31 00:42:32 localhost kernel: sr0: CDROM (ioctl) error, command: 0x00 00 00 00 00
00
Mar 31 00:42:32 localhost kernel: extra data not valid Current error sr00:00: sns = 70
3
Mar 31 00:42:32 localhost kernel: ASC=57 ASCQ= 0
Mar 31 00:42:32 localhost kernel: Raw sense data:0x70 0x00 0x03 0x00 0x00 0x00 0x00
0x0a 0x00 0x00 0x00 0x00 0x57 0x00 0x00 0x00
Mar 31 00:42:32 localhost kernel: SCSI error: host 0 id 3 lun 0 return code = 28000002
Mar 31 00:42:32 localhost kernel: ^ISense class 7, sense error 0, extended sense 3
--
J"urgen Koslowski | If I don't see you no more in this world
| I meet you in the next world
[EMAIL PROTECTED] | and don't be late!
[EMAIL PROTECTED] | Jimi Hendrix (Voodoo Child)
------------------------------
From: [EMAIL PROTECTED] (Horst von Brand)
Subject: Re: Some notes on glibc-2.1 and egcs-1.1.1
Date: 24 Mar 1999 09:26:31 GMT
In article <[EMAIL PROTECTED]>,
Safuat Hamdy wrote:
>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.
[...]
>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
I'm running glibc-2.1 on i586 (originally RedHat-5.0) compiled with an egcs
snapshot (forget which one). No trouble at all, just the (known) issue of
having to recompile ncurses, slang and libstdc++.
Are you using the right binutils (currently 2.9.1.0.22b)? Did you configure
egcs and glibc with --prefix=/usr (you might be picking up some old
libraries that make the programs crash)? Your gdb session sure points that
way (seems it never got to main()). Do your libraries have the correct
permissions (typically -rwxr-xr-x)? Is your /lib/ld-linux.so.2 the right one?
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Viņa del Mar, Chile +56 32 672616
------------------------------
From: Larry Blanchard <[EMAIL PROTECTED]>
Subject: Re: Struct Padding
Date: 29 Mar 1999 19:13:51 PST
Reply-To: [EMAIL PROTECTED]
Brad Dietrich wrote:
>
> How do you keep gcc from padding structs so the elements lie on 4 byte
> boundaries? For example, I have the following struct:
>
> struct foo {
> unsigned short bar1; // this is 2 bytes in size
> unsigned long bar2; // this is 4 bytes in size
> unsigned short bar3; // this is 2 bytes in size
> };
>
> The total desired size of this structure is 8 bytes, but when I compile
> with gcc and do a sizeof(struct foo), it replies with 12 bytes. It is
> badding the two shorts to longs. This is undesireable as I am reading
> this structure from a file, and need the structure to be a total of 8
> bytes. How do I force gcc not to pad this structure?
>
> Thanks in advance.
>
> -Brad
I'm too lazy to go try it, but if you put the two shorts together,
either before or after the long, many compilers will drop the padding.
Some of us went to great lengths to order the variables in our
structures back when compilers weren't very flexible :-).
--
Larry Blanchard - Old roses, old motorcycles, and old trains
Homo Sapiens is a goal, not a description.
------------------------------
From: [EMAIL PROTECTED] (Donal K. Fellows)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: CodeWarror for Linux (was: Re: Programming tools for ...)
Date: 31 Mar 1999 12:05:39 GMT
In article <[EMAIL PROTECTED]>,
Johan Kullstam <[EMAIL PROTECTED]> wrote:
> the advantage of emacs and make are that you can easily adjust them to
> do more than most ides. take make for example, i use make for a lot
> more than just managing my compile. i can have make fire off custom
> parsers which generate C code. i have had make run my program on a
> default parameter set, take the output and pump into gnuplot for
> display. i have used make to manage test vectors - it builds the
> vectors from a custom program and recompiles and links it as needed.
> the tool may seem primitive, but it is exceptionally powerful.
At one time I had a makefile that would build several versions of a
program, regression- and performance-test them all against each other,
plot the results, incorporate the output (both as graphs and in
tabular form) in a LaTeX document and print a copy on a given printer.
Since then, I've moved on to doing much more sophisticated stuff that
is pushing the boundaries of what GNU make will do (large
multi-directory multi-architecture builds with automated optimising
compiler generation and mechanised dependency management.) I'm
almost tempted to write the fix I want and submit it to the FSF...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ [EMAIL PROTECTED]
Department of Computer Science, University of Manchester, U.K. +44-161-275-6137
--
"And remember, evidence is nothing." - Stacy Strock <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Donal K. Fellows)
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
Date: 31 Mar 1999 11:38:33 GMT
In article <[EMAIL PROTECTED]>,
Nix <$}xin{$@esperi.demon.co.uk> wrote:
> [Emacs] cannot do the washing up though[2]. This is irritating, as
> it's the only thing that tears me away from it :)
Yes, the kitchen sink interface is only partially implemented...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ [EMAIL PROTECTED]
Department of Computer Science, University of Manchester, U.K. +44-161-275-6137
--
"And remember, evidence is nothing." - Stacy Strock <[EMAIL PROTECTED]>
------------------------------
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.help,comp.unix.programmer
Subject: Re: Programming tools for Linux/Unix: Editor, IDE, Frontend to GCC.
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 31 Mar 1999 06:50:54 -0500
"Martin Ozolins" <[EMAIL PROTECTED]> writes:
> There are several ports of vi to DOS and NT, command.com and
> cmd.exe, both support stdin, stdout and stderr <stdio.h> so why
> wouldn't it be portable?
it's either a clone (which is perfectly ok) or it really *is* vi
(which seems to be a bit of a stretch).
> Johan Kullstam wrote in message ...
> >[EMAIL PROTECTED] (Victor Wagner) writes:
> >
> >> Note that one of the best C compiliers for DOS/Novell is Watcom, and it
> >> comes with editor, which is called vi, and really _is_ vi.
> >
> >it is? how does it run in dos? i thought the real bill joy vi
> >required termcap, /bin/ed and /usr/bin/ex. last time i looked at the
> >source it did.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: [EMAIL PROTECTED] (Joseph L. Wood, III)
Crossposted-To:
comp.os.linux.misc,linux.redhat.misc,alt.linux,alt.os.linux,comp.os.linux.hardware
Subject: Re: Idea: Make a seperate "i686" tree for Redhat Linux 6.0
Date: 31 Mar 1999 12:33:56 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
David Fox <d s f o x @ c o g s c i . u c s d . e d u> wrote:
> "Idea Man" <[EMAIL PROTECTED]> writes:
>
> > Does anyone else think this would be a good idea? Keep the i386 tree, and
> > add an i686 tree that is optimized for P-II/Celeron/P-III processors.
> >
> > This might be a pain in the butt for the mirrors (more hard drive space
> > used), but for some mirrors this would be just fine. This would also make
> > Linux higher performing for all the people with flashy new Pentium-III
> > machines...
>
> How much performance improvement would there be?
Probably none. If the compilers don't emit the new instructions, there is
no gain. In fact MHz for MHz some of the older processors might be faster
for LINUX. This is especially the case for the 500Kb cache Pentium PRO
versus the Pentium MMX or Pentium II. There were probably microcode
improvements made between the PII and the PIII, but these would be
marginal.
The original case for RISC processors was an observation of that code
the Ritchie C compiler of the '70s produced. The argument was to use
the available real estate on the chip for cache and registers as opposed
to fancy instructions which were seldom used even by the most sophisitcated
compilers. Therefore, in order to take advantage of the instruction
you have to jump to an assembler routine and most of your advantage is lost.
Anyway operating systems hardly ever use floating point or graphics
instructions like bitblt, bit-block transfer. All the fancy graphics
stuff is done in user level applications code like X or in games.
Joe Wood
------------------------------
From: Sid Boyce <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: [ANN] CodeWarrior for Red Hat Linux
Date: Wed, 31 Mar 1999 12:36:49 +0000
Thanks for your reply, it's a hard circle to square, but perhaps after
the initial release, thought will be given to trying CodeWarrior on
other distributions if that is legally possible, meaning that RedHat may
feel agrieved if they do not get some advantage for their investment,
totally understandable. If verification is not done on other
distributions, I appreciate that you would find it difficult to support
your product on some other setup you are unfamiliar with. As it's Linux,
the layout for installing, getting to know the slight differences in
setup for the still vey few popular distributions would not be a
difficulty and would certainly pay handsomely for the effort.
My major concern, which needs to be addressed in some way, is that
there is no incompatibility between distributions, though they may have
differences in setup and layout, these differences being insignificant.
I happily use many applications slated for some distribution on a
slackware base, the reason I started with a slackware base was that a
rogue controller on a previous motherboard was mangling my filesystem
and I did a quick copy of a friend's hard drive, then copied over some
critical stuff I had backed up and now I'm back to upgrading from the
net, using sources or binaries, debian, RedHat, Suse and whatever I see
and want. My original setup was the very first version of Linux
downloaded hotly after Linus put it up and with few problems, I have 2
machines running 24x7. Quite often you see newsgroup questions as to
whether a package for XXX will run on my XXX and invariably the answer
is yes.
I usually point out the facts to columnists, but perhaps it needs
people who are very prominent and often quoted by journalists to go on
the offensive on this one point.
Regards..Sid.
============================================================================
Ron Liechty wrote:
>
> HI Sid,
>
> > I would ly bets that CodeWarrior would run as sweet as a nut on any x86
> >Linux box with any distribution or none.
>
> I would not bet against you. However we do not support this under other
> distributions at this time. This release of CodeWarrior was designed
> for Red Hat Linux and that is all we can support.
>
> I understand your point of view, but we have several reasons for doing a
> Red Hat release now and a CW for Linux release later.
>
> Ron
>
> CodeWarrior Advances Every Platform
> http://www.next-generation.com/jsmid/news/6093.html
> --
>
> METROWERKS Ron Liechty
> "Software at Work" [EMAIL PROTECTED]
--
... Sid Boyce...Amdahl(Europe)...44-121 422 0375
Any opinions expressed above are mine and do not necessarily represent
the opinions or policies of Amdahl Corporation.
------------------------------
From: "David Bryan" <[EMAIL PROTECTED]>
Subject: problems removing linux from my Hard Disk
Date: Wed, 31 Mar 1999 13:46:22 +0100
I install linux red hat 2.2 onto my PC.
But now I want to remove all traces of linux.
I remove all partions fine, but I can not get rid of the boot manager it
install
Does any one know how I can remove it??
David Bryan
------------------------------
From: Andreas Jusek <[EMAIL PROTECTED]>
Subject: EGCS and Stack?
Date: 31 Mar 1999 13:35:31 GMT
Hallo all,
We have a problem with EGCS-1.1.2 and the size of the stack in a C++-program.
Does anyone know, how egcs g++ handle the stacksize? Is it possible to
manipulate the size of the stack - especially to increse it?
Best Regards
Andreas Jusek
--
Dr.-Ing Andreas R. Jusek
CE Computer Equipment AG Tel.: +49 (0)521 9318 01
Herforder Str. 155a Fax: +49 (0)521 9318 444
D-33609 Bielefeld Email: [EMAIL PROTECTED]
------------------------------
From: "Sascha Bohnenkamp" <[EMAIL PROTECTED]>
Subject: Re: x86 PC emulator for x86 PC???
Date: Wed, 31 Mar 1999 15:58:21 +0200
>>: I have heard someone was working on this. Any info appreciated.
>>
>>http://www.vmware.com
>>http://www.dosemu.org
>
>No one noted that Bochs, a very complete i386 emulator, is available.
>Very, very cool. I've seen people run lose95 with it.
>
>http://www.bochs.com (not free for commercial use, though -- $25 as is).
well vmware is more expensive, but bochs is slow as hell
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: how to load ram disk from LILO?
Date: 31 Mar 1999 16:47:25 +0200
In article <R_oM2.693$[EMAIL PROTECTED]>,
Phil Howard <[EMAIL PROTECTED]> wrote:
>| Of course using a loopback device it's easy to make a 2880 boot image.
>
>Not with mkdosfs. It complains about a lack of device geometry.
>
That makes sense as the geometry is stored in the first sector of the
dos file system. It is much easier to make an ext2fs or minix file
system on a ramdisk or loop back image, though, so unless it absolutely
need to be a msdos or vfat file system, you cold try the other.
Villy
------------------------------
Date: Wed, 31 Mar 1999 15:27:51 +0200
From: Tony Scholes <[EMAIL PROTECTED]>
Subject: lex/flex grief
Hi
I'm starting to port a whole heap of UNIX C code to RH 5.2 at the mo'
and amongst other things, lex code is giving me grief. I know that
'flex' is the tool that actually converts the lex code to C, and it
works absoluetly fine (no errors, warnings, nowt), but the C code
produced causes 'gcc' to emit many dozens of errors such as :
bitregexp.l: In function `yylex':
bitregexp.l:179: parameter name omitted
bitregexp.l:139: too few arguments to function `yywrap'
bitregexp.l: At top level:
bitregexp.l:446: parse error before `='
bitregexp.l:451: conflicting types for `yy_c_buf_p'
bitregexp.c:219: previous declaration of `yy_c_buf_p'
bitregexp.l:451: warning: initialization makes pointer from integer
without a cast
bitregexp.l:451: initializer element is not constant
blah, blah, blah...
This lex code is extremely portable (been ported to at least a dozen
different UNIX platforms including SunOS over the last 15 years), this
is the only platform we've had trouble on...
I've a few other bits to sort before getting back to this....
In the meantime, any pointers?
Ta
--
Tony Scholes
Technical Manager
===============================================================================
Beacon Computer Services Tel: +44 (0)1582 478888
The Friars, 82 High Street South Fax: +44 (0)1582 478810
Dunstable, Beds. UK Email: [EMAIL PROTECTED]
LU6 3HD Compuserve: 72660,207
===============================================================================
------------------------------
** 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
******************************
