Linux-Development-Sys Digest #56, Volume #8 Mon, 31 Jul 00 10:13:16 EDT
Contents:
a problem for calling pthread_create (Terry)
Re: a problem for calling pthread_create (Kaz Kylheku)
Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ? (J Wendel)
Re: Multiple Threads and File Locking (Remo Inverardi)
PPPoE ("David Findlay")
Re: exec*() and argv[0] ([EMAIL PROTECTED])
Re: A good IDE (Nix)
Re: A good IDE (Nix)
Re: Programming newbie's question (Nix)
Re: Reproducable crashing linux-2.2.16 (Nix)
Re: device names ([EMAIL PROTECTED])
setsockopt IP_ADD_MEMBERSHIP: no such device ??? (Anes Lihovac)
Re: undefined symbols in modules (F. Heitkamp)
dark colors in ANSI Escape Sequences ([EMAIL PROTECTED])
Re: dark colors in ANSI Escape Sequences (Thomas Dickey)
----------------------------------------------------------------------------
From: Terry <[EMAIL PROTECTED]>
Subject: a problem for calling pthread_create
Date: Mon, 31 Jul 2000 03:19:04 +0800
pthread_t tid;
pthread_create(&tid, NULL, echo_serv, &newsockfd);
where the prototype for the thread start function is:
void *echo_serv(void *sockfd);
When I compile, the following message appears:
undefined reference to `pthread_create'
What is wrong with the above code??
Would anyone tell me ??
Thx,
Terry
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: a problem for calling pthread_create
Reply-To: [EMAIL PROTECTED]
Date: Mon, 31 Jul 2000 02:32:24 GMT
On Mon, 31 Jul 2000 03:19:04 +0800, Terry <[EMAIL PROTECTED]> wrote:
>
>pthread_t tid;
>pthread_create(&tid, NULL, echo_serv, &newsockfd);
Note that this is more of a question for c.o.l.d.apps.
>where the prototype for the thread start function is:
> void *echo_serv(void *sockfd);
>
>When I compile, the following message appears:
> undefined reference to `pthread_create'
That is a linker error; you forgot -pthread on the compiler command line. If
you have an older gcc that doesn't accept -pthread, try adding -D_REENTRANT,
and also -lpthread.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED] (J Wendel)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ?
Date: Mon, 31 Jul 2000 02:50:39 GMT
Dude, 2.4.0-test5 has bad VM problems, your hardware is not the
problem! Drop back to 2.2.x and wait for a more stable 2.4 kernel.
Regards,
John
On Sat, 29 Jul 2000 22:27:02 +0200, Michael Meding
<[EMAIL PROTECTED]> wrote:
>Hi there!
>
>I have problems using gcc 2.95.2 which I bootstrapped on RH6.2.
>System is AMD Duron on VIA KT-133 MSI-6330. LAtest binutils are used,
>kernel is 2.4.0-test5.
>
------------------------------
From: Remo Inverardi <[EMAIL PROTECTED]>
Subject: Re: Multiple Threads and File Locking
Date: Mon, 31 Jul 2000 05:14:46 +0200
> This is wrong; according to POSIX, both threads own the lock
> because they belong to the same process, so the locking should
> not fail.
Well, just don't tell the kernel guys. Hey, there must be some way
to synchronize file access between both different threads and dif-
ferent processes. At least I had some pretty interesting problem
porting my homebrew database to Linux ...
______________________________________________________________________
[ http://public.toilet.ch/ ] "Ich dusche warm!" [ http://www.vbs.ch/ ]
______________________________________________________________________
------------------------------
Reply-To: "David Findlay" <[EMAIL PROTECTED]>
From: "David Findlay" <[EMAIL PROTECTED]>
Subject: PPPoE
Date: Mon, 31 Jul 2000 17:57:33 +1000
Does Linux 2.4 work with PPPoE? I need it for ADSL.
David Findlay
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: exec*() and argv[0]
Date: Mon, 31 Jul 2000 09:27:28 GMT
On Sun, 30 Jul 2000 09:27:01 -0700 John Reiser <[EMAIL PROTECTED]> wrote:
|> If a script makes a reference to a different version
|> of an interpreter by means of a specific path, that interpreter should
|> have, in a convenient and PORTABLE way, the actual path used to invoke
|> it. The interpreter may need access to private libraries or locale
|> data or anything else specific to its function.
|
| Consider the same argument applied to binary format (non-#!) executables.
| They too "may need access to private libraries or locale data ...",
| and this is what the PT_INTERP part of ELF (such as: /lib/ld-linux.so.2),
| the DT_NEEDED list of shared libraries (such as: libc.so.6), and
| environment variables (such as: LD_LIBRARY_PATH and LD_PRELOAD) provide.
This does not take into consideration dynamically loaded libraries that
are selected by the binary program. I'm not referring to libraries the
program will certainly need. Instead, I'm referring to libraries that
the program may need, or may need to choose one from among many. The
path the program would come up with would be the path used by dlopen().
| If you believe that #! script executables deserve something different,
| then why don't you document an existing implementation (apparently
| Solaris x.y), propose it to the appropriate standards body, and _work_
| for its adoption? [Along the way, you might consider why the interpreter
| aspect (both binary format and script format) of exec*() isn't
| nestable to arbitrary depth.]
I'm not saying the script deserves something different. I'm referring to
the interpreter. I already know that the full path is being provided to
a program invoked directorly. I'm asking why the program that is an
interpreter of a script, being invoked via its path on the #! line, needs
to be treated any differently. Note that this is NOT the path normally
given to the script as $0 (by analogy to commonly known scripts, although
any interpreter we could speak of could be for anything needing to be
interpreted or have other things done with it). Even if it was, I would
say it is not the place of the kernel to change what the intrepreter
does when it has to parse and interprete "$0" or the like.
As for standardizing, sure, that is something I will need to consider
doing. But in the case of Linux, the issue is that they specifically
go out of their way to do the path truncation, and only for #! files.
What I want to know is why. I want to see some explanation better than
what I have seen so far.
Why do I have to consider why the interpreter aspect isn't nestable?
That isn't relevant because it is a different issue. I would hope the
kernel is not so dumb as to allow a #! script to be an interpreter,
at least to more than a small finite number of levels (although I don't
see any great use in even allowing it at all, given the complexity that
is likely to be involved in doing it safely).
|> ... The kernel should not cripple a useful facility ...
|
| No such facility is required. You claim it is useful. I believe
| that existing universally-available alternatives, such as environment
| variables, are at least as useful and effective. They even have
| properties, such as transparency and user control, which can be
| beneficial in contrast to relying on an installation path.
More goes into a design decision that revolves around something which
lacks a standard, than just the lack of a standard. It may involve an
anticipated standard. It may involve what is useful. It may involve
what is secure. I'm seeking the answer for this particular case, and
I assume from a lack of response that people in this newsgroup do not
know that answer.
Yes, I believe it is useful. If a standard were to specify it as some
environment variable, that would be fine. The fact is, Linux already
uses argv[0] for non-interpreter programs, just as Solaris already uses
it for all binary programs. Why are intrepreter programs to be treated
any differently. Obviously the Linux developers see it differently than
the Solaris developers, which only hints that it may be a weak argument.
It could be that Solaris has it all wrong. But as yet, I don't see it.
|> But you have utterly failed to justify why the interpreter path should
|> be ignored by the interpreter (however it might manage to get it). ...
|
| I did not attempt to justify anything, just document the actual state,
| and explain some of the significant implications. A #! interpreter
| which tries to derive anything from argv[0] is relying on non-portable,
| non-standardized implementation details.
I'm not trying to justify anything. If I decide to pursue making it be
a standard, of course then I would. If I decide to pursue encouraging
the kernel developers to change this, then again, of course I would.
If I decide to release my own patch to "fix" it, still I would have to
(at least to some degree in this latter case) justify it.
Instead, I'm *ASKING* why does an interpreter binary have to NOT receive
its full path via argv[0] when an ordinary binary does. There may well
be a very convincing argument to justify it. But it appears from your
lack of willingness to state it, that you simply do not know what it is.
OTOH, I cannot rule out that you don't understand what exact point I am
even asking about, or that you are just toying around and being evasive
(which a lot of people in a variety of high tech communities do).
Let me make it clear. I'm NOT asking about what a script should see when
it examimes $0 or whatever might be the equivalent. This value is not
even changed by the kernel anyway since it is passed in whole in the
argument last after the last item from the #! line. And a regular program
does receive its full executed path via argv[0] anyway, so whatever the
issue is, it was not one that they considered relevant to regular binary
programs. What is relevant to the binary interpreter as opposed to either
the script to be intrepreted or a non-interpreter binary?
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: A good IDE
Date: 31 Jul 2000 01:59:38 +0100
[EMAIL PROTECTED] (cLIeNUX user) writes:
> I noodled around briefly with vim's nascent IDE stuff, but even at that
> level the problem I have with such things is they very strongly tend to
> enforce a style. I'm sure emacs is great for writing gdb.
Er, the only `style' Emacs enforces is that you have to know a bit of
Lisp to customize it. Its C autoindentation --- assuming that it what
you are driving at --- is *exceedingly* customizable. There's little it
cannot do, no matter how bizarre.
While, of course, it comes with styles that make it easy to conform to
GNU coding standards (and it *is* great for writing them in ;) ) it
comes with styles for other things, and it's fairly easy to extend in
simple ways. (Extending in complex ways becomes steadily harder, of
course, because you have to treat Lisp as more of a programming language
and less of a cookbook...)
> The only two "IDEs" I know of that don't make any un-toward assumptions
> are Unix itself and Forth. Depends on how unique your code is as to how
> much of a problem that is.
Unix makes plenty of assumptions; so does Emacs; so does any
environment. As long as you agree with the assumptions, all will be
well. The problem with platforms like Windows, DOS &c isn't that they
demand you adapt to them but that the adaptations you have to do are so
bloody bizarre.
--
`I am of the belief that catnip arrived on the planet in the same spaceship
that delivered cats. It is the only thing they have from their home
planet. Tuna, chicken, sparrow-brains, etc., these are all things of our
world that they like, but catnip is crack from home.' --- Bill Cole
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: A good IDE
Date: 31 Jul 2000 02:00:45 +0100
[EMAIL PROTECTED] (cLIeNUX user) writes:
> I use sh scripts instead of make.
*boggle* *splutter*
--
`I am of the belief that catnip arrived on the planet in the same spaceship
that delivered cats. It is the only thing they have from their home
planet. Tuna, chicken, sparrow-brains, etc., these are all things of our
world that they like, but catnip is crack from home.' --- Bill Cole
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Programming newbie's question
Date: 31 Jul 2000 02:08:25 +0100
Andreas Rottmann <[EMAIL PROTECTED]> writes:
> Sunny Han <[EMAIL PROTECTED]> writes:
> > I'm using redhat linux 6.0, I had following errors in compiling example
> > source library.
> > Although I have some experience in linux, I am a novice in programming.
> > Please help me. This is the first day in learning C programing in Unix
> > and Linux.
> >
> [snip]
> > strerror.c:3: conflicting types for `sys_errlist'
> > /usr/include/stdio.h:553: previous declaration of `sys_errlist'
> >
> This error seems pretty obvious to me, but what the FSCK are you
> doing? Looks like you're trying to compile some libc - not a good
> place to start...
It looks like a simple client/server program to me, but the program is
broken as it tries to define things like sys_errlist, when they are
already defined (differently) in the C library.
To fix it, surround the broken declaration on line 3 of strerror.c with
#ifndef __GLIBC__
{offending stuff}
#endif
Note that since glibc already includes a perfectly functioning
strerror(), you probably won't need strerror.c at all.
> Find a good book on C under Linux/Unix and write some little programs
> yourself. That will get you bootstrapped.
Agreed, 100%.
--
`I am of the belief that catnip arrived on the planet in the same spaceship
that delivered cats. It is the only thing they have from their home
planet. Tuna, chicken, sparrow-brains, etc., these are all things of our
world that they like, but catnip is crack from home.' --- Bill Cole
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Reproducable crashing linux-2.2.16
Date: 31 Jul 2000 02:14:43 +0100
[EMAIL PROTECTED] (Martin Kahlert) writes:
> I will ever touch my memory from now on to protect me against this
> misfeature.
It's a feature if you're using things like sparse arrays, or (more
importantly) things like the vector<> in libstdc++, which has to double
its size whenever it expands at all, to satisfy its time complexity
requirements. (I think I got the specific template right. My memory is
fuzzy on this point, it's been several years and it's late and I'm
ill. :) )
--
`I am of the belief that catnip arrived on the planet in the same spaceship
that delivered cats. It is the only thing they have from their home
planet. Tuna, chicken, sparrow-brains, etc., these are all things of our
world that they like, but catnip is crack from home.' --- Bill Cole
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: device names
Date: Mon, 31 Jul 2000 10:36:25 GMT
In article <[EMAIL PROTECTED]>,
Rudi Sluijtman <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > I am trying to relate the disk I/O in /proc/stat with a device name.
> > How can I match that data with the devices?
>
> disk_io: (3,0):(13713,350842,21318,179236) (3,1):
(59543,1126798,48917,506620)
>
> (3,0): 3 is the major devicenumber, 0 is the minor number.
>
> ls -l /dev/hda gives:
> brw-rw---- 1 root disk 3, 0 May 5 1998 hda
>
> So hda has major number 3, minor number 0.
>
> finding a devicename for major/minor number combination could be
> done using awk:
>
> major=3; minor=0 ; ls -l /dev | awk "\$1 ~ /^b/ && \$5 ==
\"$major,\" && \$6==$minor {print \$NF}"
> gives you the block device with major 3 minor 0,
>
> major=3; minor=0 ; ls -l /dev | awk "\$1 ~ /^c/ && \$5 ==
\"$major,\" && \$6==$minor {print \$NF}"
> gives you the character device.
>
> Or you could look for it in /usr/src/linux/Documentation/devices.txt
>
> Or you could do "cat /proc/devices", which gives you ide0 (not a /dev
> entry) for blockdevice major 3. It depends on what you need.
>
> Have fun,
> Rudi Sluijtman,
>
What does this information relate to?
disk_io: (3,0):(13713,350842,21318,179236)
(3,1):(59543,1126798,48917,506620)
Where are you getting these values from i.e. 13713,350842 and then
59543?
The (3,0) looks like it may help.
Thanks,
bborn
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 31 Jul 2000 13:46:08 +0200
From: Anes Lihovac <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: setsockopt IP_ADD_MEMBERSHIP: no such device ???
Hello !
I have an application(vic) which breaks with the message:
setsockopt IP_ADD_MEMBERSHIP: no such device
How can I enable it to run ???
I now that it is an multicast option and I turned the
IP: multicast switch in the Kernel on but it doesn't work.
Hope anybody could help me!
Regards
Anes
------------------------------
From: [EMAIL PROTECTED] (F. Heitkamp)
Date: Mon, 31 Jul 2000 08:22:27
Subject: Re: undefined symbols in modules
Reply-To: [EMAIL PROTECTED]
In message <8m1qdg$n1r$[EMAIL PROTECTED]> - Yu Jaemin
<[EMAIL PROTECTED]> writes:
>
>try to add -O option to gcc.
>
That did it. Thanks!
Fred
>
>Jaemin
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: dark colors in ANSI Escape Sequences
Date: Mon, 31 Jul 2000 13:07:38 GMT
Hi All
(sorry, if this forum is not appropriate, but posting to other forums
failed with a server error)
According to ANSI Escape Sequences, the following switches to
magenta text, default background, non-blinking text and non-light(dark)
text:
\033[35;49;27;22m
I encountered two ways, how light/dark text is represented
first: 16 colors always nonbold
(light blue, dark blue, light red, dark red, ...)
second: 8 colors always in light
(bold blue, non-bold blue, bold red, non-bold red, ...)
How can I make ANSI-colors become displayed in the first style?
I go mad, if I don't get back the dark colors!
please please help me!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Thomas Dickey <[EMAIL PROTECTED]>
Subject: Re: dark colors in ANSI Escape Sequences
Date: 31 Jul 2000 13:24:52 GMT
[EMAIL PROTECTED] wrote:
> I encountered two ways, how light/dark text is represented
> first: 16 colors always nonbold
> (light blue, dark blue, light red, dark red, ...)
> second: 8 colors always in light
> (bold blue, non-bold blue, bold red, non-bold red, ...)
> How can I make ANSI-colors become displayed in the first style?
ANSI (ISO 6429) only defines 8 colors.
Some terminal emulators (aixterm and XFree86 xterm) define escape
sequences which extend this to 16 colors.
--
Thomas E. Dickey <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://dickey.his.com
ftp://dickey.his.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
******************************
