Linux-Development-Sys Digest #971, Volume #6 Sat, 17 Jul 99 08:14:10 EDT
Contents:
Compiling old kernels ([EMAIL PROTECTED])
Re: Bug of GCC (Christopher Browne)
Re: Bug of GCC (Christopher Browne)
Re: undefined reference to `crypt' (john lucian)
Re: Bug of GCC (Ross Smith)
Re: MICROSOFT LINUX DISTRIBUTION (Jan Andres)
Re: MICROSOFT LINUX DISTRIBUTION (PeterKeane)
Re: read/write and down() (Andi Kleen)
Re: when will Linux support > 2GB file size??? (Peter Samuelson)
Re: new modem ...new problem (Peter Samuelson)
Re: Where is IDE UDMA source? (Peter Samuelson)
Re: Why we are still holding on to X Windows (Philip Brown)
Re: Help - Need to shift memeory over to /var ASAP. (Peter Samuelson)
Re: Bug of GCC (Scott Lanning)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Compiling old kernels
Date: Sat, 17 Jul 1999 04:08:55 GMT
I'm trying to compile linux 2.0.1 under RedHat 5.2. At the end of the
compile, I get the error below. Why? If it's a stupid binutil thing,
how can i fix it?
-Hopeful
-Randy
d -qmagic -Ttext 0xfffe0 arch/i386/kernel/head.o init/main.o
init/version.o \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
mm/mm.o fs/f s.o ipc/ipc.o net/network.a \
fs/filesystems.a \
drivers/block/block.a drivers/char/char.a drivers/net/net.a
drivers/pci/ pci.a \
/home/randy/LinuxHistoryPaper/linux-2.0.1/arch/i386/lib/lib.a
/home/randy/LinuxHistoryPaper/linux-2.0.1/lib/lib.a
/home/randy/LinuxHistoryPaper/linux-2. 0.1/arch/i386/lib/lib.a
-o vmlinux
ld: warning: cannot find entry symbol _start; defaulting to 000fffe0
nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( a \)' | sort >
System.map
make[1]: Entering directory
`/home/randy/LinuxHistoryPaper/linux-2.0.1/arch/i386 /boot'
make[2]: Entering directory
`/home/randy/LinuxHistoryPaper/linux-2.0.1/arch/i386 /boot/compressed'
./xtract /home/randy/LinuxHistoryPaper/linux-2.0.1/vmlinux | gzip -9 |
./piggyba ck > piggy.o
Non-GCC header of 'system'
Compressed size 20.
ld -qmagic -Ttext 0xfe0 -o vmlinux head.o misc.o piggy.o
ld: warning: cannot find entry symbol _start; defaulting to 00000fe0
misc.o: In function `fill_inbuf': misc.o(.text+0x1bd8): undefined
reference to `input_data'
misc.o(.text+0x1bdd): undefined reference to `input_len'
misc.o(.text+0x1bf3): undefined reference to `input_data'
make[2]: *** [vmlinux] Error 1
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Bug of GCC
Reply-To: [EMAIL PROTECTED]
Date: Sat, 17 Jul 1999 03:59:12 GMT
On 16 Jul 1999 19:43:49 GMT, Scott Lanning <[EMAIL PROTECTED]> wrote:
>Paul D. Smith ([EMAIL PROTECTED]) wrote:
>: "Fixing" this would likely involve some gross, unclean hacks, and no
>: one likes a gross, unclean hack. Much simpler to just follow the
>: standard and spit an error. After all, the code really _IS_ in error.
>
>Agreed. And they should remove all other instances in which they
>do not follow the standard.
There's a severe semantic problem there.
"Removing all other instances of nonstandard behaviour" is kind of
like taking a piece of stone and "removing everything that doesn't
look like an elephant."
Which is to say that "removing nonstandard behaviour" could consist of
such diverse things as:
- Deleting code
- Adding code
- Changing code
- Redesigning some portion of the system.
There does exist a "-pedantic" option for GCC where it tries to behave
more strictly like ANSI C; to what extent this will be acceptable is
questionable.
Furthermore, it is not simply a pedantic question to ask which
standard you're referring to. I think that ISO and ANSI have both
declared standards; there have been revisions to those standards;
there also is an imminent C9X standard, which adds considerable
ambiguity to the issue of "what is the standard?"
GCC seems to be rather more compliant with standards than many other
compilers; where it's not, this has been known to result from such
things as:
- Useful extensions that the standards do not preclude;
- Choosing one side or another when the standard is ambiguous;
- A small number of cases of the attitude that "the standard did
something we feel is extremely inelegant" (e.g. - trigraphs)
Should you prefer to hold a staunchly anti-FSF position, as some do, I
suppose it's practical to be strident against *any* situations where
they haven't followed slavishly after the standards.
--
The Three Laws of Thermodynamics:
1) You can't win, only lose or break even.
2) You can only break even at absolute zero.
3) You can't get to absolute zero.
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Bug of GCC
Reply-To: [EMAIL PROTECTED]
Date: Sat, 17 Jul 1999 03:59:22 GMT
On 16 Jul 1999 13:21:01 GMT, Scott Lanning <[EMAIL PROTECTED]> wrote:
>Peter Allen ([EMAIL PROTECTED]) wrote:
>: Scott Lanning wrote:
>: > Then it says, "In fact, you can put anything at all after the
>: > `#endif' and it will be ignored by the GNU C preprocessor, but
>: > only comments are acceptable in ANSI Standard C." So, please
>: > don't give arguments based on the high moral ground of the GNU C
>: > preprocessor because it conforms to "standard" C.
>:
>: As the standard is there it is best to comply to it in case anyone
>: wants to port your code. Have you ever ported something which has
>: _loads_ of errors about one thing like that that all need to be
>: changed, when if the original author had just followed the standard
>: everything would be fine.
>
>I understand your concerns, Mr. Allen, and I do wish people would
>code more cleanly, however my argument is not about whether one
>should conform to standard C. I agree with that, in general.
>
>Okay, let me recapitulate...
>
>1) Cute Panda wondered why the GNU C preprocessor doesn't allow
> you put an apostrophe inside an #if 0 .. #endif.
>
>2) The reply was based on the premise that, it is not allowed
> by standard C.
>
>3) I argued with that premise, giving examples in which the
> GNU C preprocessor doesn't conform to standard C.
I do not recall the name of this syllogism, but a more generic
representation is thus:
1. Person asked why GCC flagged a particular nonconformance with ANSI
C as an error.
2. The response was that this represents an error.
3. You argued with that premise, indicating that GCC permits some
nonstandard constructs.
Are you arguing by this:
a) That the GCC implementors should, in future, not bother conforming
with ANSI standards, thereby making 1 no longer true?
b) That the ANSI C standard should be modified so that this error (e.g
2) is no longer an error?
c) That GCC should be fixed to conform with the ANSI C standard, so
that 3 would no longer be true?
--
If you have nothing to say on a subject, replying with a line such as,
"I agree with this." puts you in the TO:'s for all future messages, and
establishes you as "one who really cares", if not an actual expert, on
the topic at hand.
-- from the Symbolics Guidelines for Sending Mail
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/langc.html>
------------------------------
From: john lucian <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer
Subject: Re: undefined reference to `crypt'
Date: 17 Jul 1999 04:46:02 GMT
In comp.os.linux.development.system Mark Tranchant <[EMAIL PROTECTED]> wrote:
>You need to add -lcrypt to the gcc line, and ensure libcrypt exists on
>your system.
Hey, anyone know what library needs to be included in order to avoid getting
an undefined reference on server_login() ?
Any help would be most appreciated.
jl.
--
[ [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: Ross Smith <[EMAIL PROTECTED]>
Subject: Re: Bug of GCC
Date: Sat, 17 Jul 1999 17:51:41 +1300
Cute Panda wrote:
>
> If it's the way ANSI C is specified, then why the other preprocessor
> don't suffer this
> problem ? they don't meet the ANSCI standard, right ?
Wrong. The standard (well, the C++ standard, I don't have the C standard
but I assume the preprocessor hasn't changed) explicitly says that this
is *undefined*. *Any* behaviour in this situation meets the standard.
> Many books talk about this code and say it's a simple way to make
> comments, and lots of
> programmers write their code like this, well, I think it's very inconvenient
> for some people
> to modify their code just because gcc preprocessor complains about this kind
> of code.
That's ridiculous. Because books written by morons say it's OK, it's
somehow the standard's or the compiler's fault when it turns out not to
be OK?
I suppose if you read a book saying it's safe to jump off a bridge, and
then you got injured doing it, you'd blame the bridge builders instead
of the author of the book?
> if gcc preprocessor is able to recognize "#if 0", then it should know
> that all the following
> code before #endif is not real code and should not be tokenized, why is it
> necessary to break the
> text into tokens ? don't you think tokenizing the text inside #if 0 ...
> #endif is a redundant job ?
And how is it supposed to find the #endif if it's not tokenising the
text?
--
Ross Smith <[EMAIL PROTECTED]> The Internet Group, Auckland, New Zealand
========================================================================
The good news, according to the FCC, is that television viewing won't be
interrupted by the Y2K problem. The bad news, according to the rest of
us, is that television viewing won't be interrupted by the Y2K problem.
-- Jonathan Erickson in Dr Dobb's Journal
------------------------------
From: [EMAIL PROTECTED] (Jan Andres)
Subject: Re: MICROSOFT LINUX DISTRIBUTION
Date: 16 Jul 1999 17:20:27 GMT
In article <7mdp08$2t9s$[EMAIL PROTECTED]>, bill davidsen wrote:
>In article <7mar6f$otr$[EMAIL PROTECTED]>,
>Captain Insano <[EMAIL PROTECTED]> wrote:
>
>| I don't think MS has plans for Linux just yet, although I'm sure
>| someone there has given it a little thought. However, if they did
>| produce a Linux version of Office 2000, I would not be surprised at
>| all if it shipped with IE as the desktop/window manager.
>
>IE isn't a window manager. The Linux version of IE runs on X.
All window managers run on X.
--
Jan Andres
[EMAIL PROTECTED]
Ham radio: DH2JAN
------------------------------
From: [EMAIL PROTECTED] (PeterKeane)
Subject: Re: MICROSOFT LINUX DISTRIBUTION
Date: 17 Jul 1999 07:21:31 GMT
>The LDC should then put
>some effort into a _Windows_ program that; determines all hardware on the
>user's system, sets up an RH kickstart (or similar) install using that
>knowledge, and walks the user through repartitioning the drive, followed by
>the FTP install.
Sounds a lot like the Linux equivalent of
InstallShield(tm). I think, thought, that
Unix guru's are too tied to their shell
scripts to do anything as comprehensible
as a simple install program. Besides how
are you going to tear them away from
their papers on AI long enough to code
drivers for winmodems which would turn
them into Linmodems and allow this
FTP install. :-)
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: read/write and down()
Date: 17 Jul 1999 00:48:16 +0200
David Grothe <[EMAIL PROTECTED]> writes:
> Does anyone know why it is that in the Linux kernel sys_write does a
> down() on the inode semaphore of the file and sys_read does not?
>
> This results in "one at a time" in the file system's write handler but
> multiple entries allowed in the read handler.
Because POSIX requires "atomic writes", but not "atomic reads" ?
I believe there are also less races in the read case, which would
require locking.
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 17 Jul 1999 03:11:25 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Byron Jeff <[EMAIL PROTECTED]>]
> > Because switching all the file pointer computations to 64 bit will
> > slow each and every reference to the file system down on a 32 bit
> > machine.
[Robert Krawitz <[EMAIL PROTECTED]>]
> Or you could do the Solaris/AIX thing of having alternate system
> calls for handling big files; you can use either system call for
> handling small files. There's a compile-time macro that can be set
> for recompiling old code with the new routines.
Great for userspace, but I think the performance hit that's being
talked about is kernel-side. The kernel suddenly has to use 64-bit
arithmetic for *all* open file dealings, whether or not the files are
big or the user is using the long long calls.
Those who say the performance hit will be noise compared to normal I/O
times would definitely be right in a single-tasking environment
without buffering, but without a reference implementation and a
benchmark we probably won't ever really know what the performance hit
is for the multitasking case. It may all still be noise, but remember
that not all kernel file manipulation is syscall-driven, and not all
kernel file manipulation touches the disk.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: new modem ...new problem
Date: 17 Jul 1999 03:50:54 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Ranger <[EMAIL PROTECTED]>]
> I got it set on com 2 in windoze and on dev/tty1 on Mandrake linux
That's your problem. Use /dev/ttyS1, not /dev/tty1. The S stands for
"serial".
... Though there is an old theory that `ttyS0' is actually a mangled
form of `tytso' as in Ted T'so <[EMAIL PROTECTED]>, one of the kernel
gurus who has done a lot of the serial controller stuff.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Where is IDE UDMA source?
Date: 17 Jul 1999 04:14:27 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Philip Brown <[EMAIL PROTECTED]>]
> Okay, I'm not a linux kernel guru. Could someone tell me whereabouts
> to get the part of the kernel source that handles UDMA disk
> transfers?
Grep around drivers/block/.
You might be especially interested in ide-dma.c and some of the
specific IDE controller drivers such as pdc4030.c.
Did you do *any* looking around your kernel tree before posting this
question? The location is not what I would call obscure.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Reply-To: [EMAIL PROTECTED]
Date: 17 Jul 1999 09:34:38 GMT
On Fri, 16 Jul 1999 10:31:24 +0200, [EMAIL PROTECTED] wrote:
>Philip Brown wrote:
>> you just contradicted yourself.
>>
>> The app can say "Add this font server to the font path"
>> The app can ALSO open a port and act as a font server.
>
>Yes, there are ways; but there is no *simple* X or Xt API for that;
>[...]
>
>In Windoze, one can pass data to the "rendering subsystem" (deliberately
>vague term) and say "This is the font to be used for this string".
If we want to reduce things to WIndoze terms, then tehre is STILL a
"Simple X API for that"
If we are comparing to windoze, then you assume everything is local.
If you assume everything is local, then the software knows the path
that it is installed on, and that path is local to the server.
In which case, it can just say "Hey, here's another font directory"
"Now load my custom font, and use it for this string"
You don't get much simpler than that.
ANd its better than windowz, cause the user can add a program like this
without requiring "superuser" access, and potentially being able to
nuke all fonts on the system.
--
[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: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Help - Need to shift memeory over to /var ASAP.
Date: 17 Jul 1999 04:21:53 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Posted and mailed per request]
[Nico Zigouras <[EMAIL PROTECTED]>]
> I run a server running RedHat 5.2 with A LOT of mail in /var and it
> is maxing out as we speak. I need to do an emergency allocation of
> memory to it this weekend because I can't have my ISP put more mem
> on the server until Monday. Any suggestions?
Your post is more than a little confusing. By "memory" do you mean
disk space? If so, the best option to do on a temporary basis is to
"borrow" another filesystem. Typically you might have extra space in
/usr. So, create a directory under /usr:
mkdir /usr/var-tmp
Determine who is using space in /var:
du -sk /var/*/*
Pick candidate directories to move over into /usr. Now move them:
cp -a /var/foo/bar /usr/var-tmp/bar
mv /var/foo/bar /var/foo/bar-orig
ln -s /usr/var-tmp/bar /var/foo/bar
rm -fr /var/foo/bar-orig
This could conceivably cause a minor upset to whatever system daemons
might be depending on the contents of whatever directories you move.
If necessary, restart said daemons. HTH.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: Bug of GCC
Date: 17 Jul 1999 11:33:57 GMT
Ross Smith ([EMAIL PROTECTED]) wrote:
: Cute Panda wrote:
: > Many books talk about this code and say it's a simple way
: > to make comments, and lots of programmers write their code
:
: That's ridiculous. Because books written by morons say it's OK,
: it's somehow the standard's or the compiler's fault when it
: turns out not to be OK?
In the original GNU C preprocessor manual, it at least doesn't
warn against it, though it does point out that it's okay to use
nested #if #endif. However, in recent verions of that manual,
they have modified it, giving the reason that it must consist of
complete tokens. The original manual was written by Stallman, and
surely he is not a moron.
: I suppose if you read a book saying it's safe to jump off a
: bridge, and then you got injured doing it, you'd blame the
: bridge builders instead of the author of the book?
This kind of thing is basically the only reason I argued the
point. I thought it was a perfectly reasonable question to ask
but knew that it would be ridiculed. I personally don't care if
unmatched quotes are allowed within the false conditional, but
I do care when people get attacked for asking reasonable questions.
It is the kind of action that causes people to stop asking
questions and follow what they read in "books written by morons".
: And how is it supposed to find the #endif if it's not tokenising
: the text?
The same way all the other compilers do..? The Irix one is able
to perform this apparent miracle. Besides, it wouldn't break any
code if it did that. (Please note that I'm not suggesting that
the GNU C preprocessor should in fact change its behavior, but
merely suggesting that it is possible to do so, contrary to what
the above response seems to indicate.)
I don't want to continue this argument. I won't reply unless
someone starts "bocking" and calls me chicken.
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
"I'm going to have fun telling you about this absurdity, because I
find it delightful." --Richard Feynman
------------------------------
** 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
******************************
