Linux-Development-Sys Digest #319, Volume #8 Sun, 3 Dec 00 20:13:06 EST
Contents:
Re: Need library reference (Paul Kimoto)
How to tell version of glibc? ("Duke")
Re: How to tell version of glibc? ("John E. Garrott Sr")
Re: How to tell version of glibc? (Paul Kimoto)
Re: Need help understanding /proc/pid/stat file (Mike Hall)
Re: Secret to depmod / modprobe ??? ("Hung Hin Lik, Shell")
Re: Secret to depmod / modprobe ??? (Kaelin Colclasure)
Re: Need library reference (Donovan Rebbechi)
fh_verify: permission failures (Conrad Mukai)
RAD environments ("Guy Dillen")
Re: DLL's etc ("D. Stimits")
Re: Search order for shared libraries (ld-linux.so and ldconfig) (Nix)
Re: Module Compilation Problems ("Peter T. Breuer")
Re: Module Compilation Problems ("Peter T. Breuer")
Re: How to tell version of glibc? (John Reiser)
Re: Module Compilation Problems ([EMAIL PROTECTED])
Re: Need help understanding /proc/pid/stat file ([EMAIL PROTECTED])
Inode (Liam Moy)
Re: fh_verify: permission failures ("Karl Heyes")
Re: fh_verify: permission failures (Kaz Kylheku)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Need library reference
Date: 3 Dec 2000 10:59:56 -0500
Reply-To: [EMAIL PROTECTED]
In article <8MpW5.41080$[EMAIL PROTECTED]>,
Robert J. Hansen wrote:
> You mean electronic or paper? The electronic version of a library reference
> is called `man'. Type `man <functionname>' and, more often than not, you'll
> get a quick overview of it. Try `man strlen', if you like.
strlen() is a (g)libc function, and that is documented more thoroughly
in (tex)info pages.
--
Paul Kimoto
This message was originally posted on Usenet in plain text. Any images,
hyperlinks, or the like shown here have been added without my consent,
and may be a violation of international copyright law.
------------------------------
From: "Duke" <[EMAIL PROTECTED]>
Subject: How to tell version of glibc?
Date: Sun, 3 Dec 2000 11:44:22 -0500
I am looking for _the_ authoritative way to determining the installed
version of glibc on a linux system. The way I am doing it now is by writing
a hello world program, compile it and run ldd -v on it. This doesn't seem
right :)
------------------------------
From: "John E. Garrott Sr" <[EMAIL PROTECTED]>
Subject: Re: How to tell version of glibc?
Date: Sat, 02 Dec 2000 20:46:56 -0800
Duke wrote:
>
> I am looking for _the_ authoritative way to determining the installed
> version of glibc on a linux system. The way I am doing it now is by writing
> a hello world program, compile it and run ldd -v on it. This doesn't seem
> right :)
ls /lib/libc*
Good luck,
John
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: How to tell version of glibc?
Date: 3 Dec 2000 12:01:01 -0500
Reply-To: [EMAIL PROTECTED]
In article <3LuW5.2154$[EMAIL PROTECTED]>, Duke wrote:
> I am looking for _the_ authoritative way to determining the installed
> version of glibc on a linux system. The way I am doing it now is by writing
> a hello world program, compile it and run ldd -v on it. This doesn't seem
> right :)
Run /lib/libc.so.6 itself. (This doesn't work for [some versions of?]
glibc-2.0.*, but that is informative too ...)
$ /lib/libc.so.6
GNU C Library stable release version 2.1.3, by Roland McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc.
[etc.]
--
Paul Kimoto
This message was originally posted on Usenet in plain text. Any images,
hyperlinks, or the like shown here have been added without my consent,
and may be a violation of international copyright law.
------------------------------
From: Mike Hall <[EMAIL PROTECTED]>
Subject: Re: Need help understanding /proc/pid/stat file
Date: Sun, 03 Dec 2000 11:45:08 -0600
[EMAIL PROTECTED] wrote:
> Could someone tell me where I can find a precise explanation of what's
> what in /proc/pid/stat?
> I'm trying to understand which among these corresponds to cmajflt. Is
> there any documentation that describes this exactly?
The routine "static int get_stat(int pid, char * buffer)"
in /usr/src/linux/fs/proc/array.c should explain it all! :-)
------------------------------
From: "Hung Hin Lik, Shell" <[EMAIL PROTECTED]>
Subject: Re: Secret to depmod / modprobe ???
Date: Mon, 04 Dec 2000 01:51:45 +0700
> Oh, and of course there's no modules.conf man page. And there are
> cross references to a modules(2) man page -- but it doesn't exist on
> my system either. Sigh.
>
There're 'modules.conf(5)' in my system...
Slackware 7.1
I sent a email to you which attach the modules.conf man page..
--
Best Regards,
Shell Hung
mailto:[EMAIL PROTECTED]
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: Secret to depmod / modprobe ???
Date: 03 Dec 2000 10:30:41 -0800
"Hung Hin Lik, Shell" <[EMAIL PROTECTED]> writes:
> > Oh, and of course there's no modules.conf man page. And there are
> > cross references to a modules(2) man page -- but it doesn't exist on
> > my system either. Sigh.
> >
> There're 'modules.conf(5)' in my system...
>
> Slackware 7.1
Ugh, sigh. [Slaps forehead...] It's there on my Redhat system, too. I
must have fat-fingered the spelling when I first tried looking for it.
> I sent a email to you which attach the modules.conf man page..
And (again) I thank you. This was indeed THE man page I needed to
reference for what I'm trying to accomplish.
-- Kaelin
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Need library reference
Date: 3 Dec 2000 18:42:16 GMT
On Sun, 03 Dec 2000 08:27:06 GMT, Mark Healey wrote:
>I'm really new to linux and only marginaly familiar with C.
>
>I probably need a tutorial but for now I'd like a library reference
>and for the life of me can't find it.
>
>Where is it?
The manpages are a concise reference. For documentation which includes
more in the way of explanations, see the info docs. For graphical info
browsers, try kdehelp or tkinfo.
For good books on programming with Linux, check out "Beginning Linux
Programming" and "Professional Linux programming".
For short tutorials on a bunch of things, take a look at my website
HTH
--
Donovan Rebbechi * http://pegasus.rutgers.edu/~elflord/ *
elflord at panix dot com
------------------------------
From: Conrad Mukai <[EMAIL PROTECTED]>
Subject: fh_verify: permission failures
Date: Sun, 03 Dec 2000 19:07:03 +0000
I posted this on comp.os.linux.networking earlier, but after tracking
down the place in the source where the error message was coming from,
this may be a better place to seek an answer.
-- start previously posted message --
We have recently set up an NIS/NFS server with the Mandrake 7.2
distribution. Users mount their home drives with autofs. Everything
seems to be fine except that the console on the server has the following
error messages:
fh_verify: fonts/override permission failure, acc=1, error=13
fh_verify: share/fonts permission failure, acc=1 error=13
-- end previously posted message --
I found that the fh_verify subroutine is in nfsd (specifically in
nfsfh.c written by Olaf Kirch). It appears that the routine checks
permissions for file handles. nfsd runs on the server as root, so it
would seem that the permissions being checked are for the remote client.
Is this yet another tcp_wrapper permission that needs to be set in
/etc/hosts.allow? The man page makes no reference to this as it did for
ypserv and mountd. Any help would be appreciated. Thanks in advance.
--
************************************************************
* Conrad Mukai "Consistency is the last resort of *
* [EMAIL PROTECTED] the unimaginative." - Oscar Wilde *
************************************************************
------------------------------
From: "Guy Dillen" <[EMAIL PROTECTED]>
Subject: RAD environments
Date: Sun, 3 Dec 2000 20:34:06 +0100
I'm going to develop an administrative-realtime application with a frontend
consisting of Windows CE based Palm/Pocket/Handheld PC's (or does there
already exists an embedded or tiny Linux for these kind of machines???) and
a backend consisting of a Linux box.
The choice for Linux as backoffice/backend is for several reasons:
realibility, stability, and also $$$.
My questions:
1) What is/are the best RAD environment(s) for this kind of application
(administrative)? Do this/these RAD environment(s) run in client/server,
host-based or both modes?
2) What is the best (O)RDBMS (not only but also relating to $$$) for my
Linux box (MySQL, Postgress, ...???)?
3) What is a good emulator to Linux for a Windows 2000/NT/98 client?
Thanks in advance for your suggestions.
Best regards,
Guy Dillen
E-mail: [EMAIL PROTECTED]
------------------------------
Date: Sun, 03 Dec 2000 13:02:49 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: DLL's etc
Rajagopalan Srinivasan wrote:
>
> folks,
>
> I am looking for some reference on the API for performing operations like :
>
> - what dynamic libraries any process is mapped to
> - given an executable what dynamic libraries are required to run the exec
> - any version info wrt the dynamic library etc
> - also the symbol table (debugging info) inside the exec etc.
>
> Can someone please point me in the right direction?
>
> regards
>
> srini
You can find out who is using a file with lsof <full path of filename>.
You can see what an executable wants (not shell scripts though) via ldd
<full path to file of executable>.
You can print the system's current idea of library versions available
with ldconfig -p.
You can view the symbols in a given lib file with nm.
If you need to demangle C++ symbols in a C++ lib, you can use c++filt as
the pipe destination of nm.
You will find kernel-related symbols in your System.map file (location
varies, usually /proc/).
For your own special dynamic loading, outside of the normal linker path
of your system, see dlopen() and family.
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Search order for shared libraries (ld-linux.so and ldconfig)
Date: 03 Dec 2000 20:47:17 +0000
[EMAIL PROTECTED] writes:
> | I have had a long trawl through glibc (elf sub-dir) sources and cannot
> | find the code specifically defining the search order. If anyone happens
> | to know the piece of code, I'd be interested to know where it is.
>
> My guess is the search order would be built in to ld.so in the linker tools.
> Or is that the bin tools? The naming of those packages is far more confusing
> than library search order is.
The search order for ld(1) is specified by a number of SEARCH_DIRs in
the linker script; by default with H.J.'s binutils this is
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib);
SEARCH_DIR(/usr/i586-pc-linux-gnu/lib);
> | The ldconfig man page isn't precise, but states that in building the
> | cache (/etc/ld.so.cache) that it searches for libraries :
I'm using ldconfig from glibc-2.2 here; it is at last providing its own
ldconfig. I'll use that herein.
> | "in the directories specified on the command line, in the file
> | /etc/ld.so.conf, and in the trusted directories /usr/lib and /lib"
> |
> | There is an implied order in this statement, but my testing indicates
> | the order is this
> |
> | 1. Dirs on cmd line
> | 2. /lib
> | 3. /usr/lib
> | 4. Dirs listed in /etc/ld.so.conf
> |
> | Can anyone confirm this (and again pointers to the appropriate point in
> | the source would be handy if anyone has them) or tell me whether it is a
> | configuration issue?
The source (glibc-2.2/elf/ldconfig.c) states
,----[ main() ]
| if (!opt_only_cline)
| {
| /* Always add the standard search paths. */
| add_dir (SLIBDIR);
| if (strcmp (SLIBDIR, LIBDIR))
| add_dir (LIBDIR);
|
| parse_conf (config_file);
| }
`----
(opt_only_cline is the `-n' switch; SLIBDIR and LIBDIR are specified at
configure time, and are /slib and /lib by default. add_dir adds things
to the start of the list.)
What I find interesting is that the new ldconfig appears to be capable of
doing recursive searches below the directories specified in ld.so.conf;
useful for me, with ninety lines in there.
> It does seem inverse to my natural order of thinking to go from things that
> are more dynamic to things that are more static.
That's the way the ld.so.conf crumbles ;)
--
`My head goes prong off his prose.' --- Rebecca Ore
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Module Compilation Problems
Date: Sun, 3 Dec 2000 21:58:15 +0100
Brian <[EMAIL PROTECTED]> wrote:
> The directory /usr/include/linux is a real one containing lots of header
> files in RedHat 7.0. You cannot directly restore the link. I don't know why
> RedHat made this reconstruction, but I think it's better to keep it there.
Why do you think so? It's wrong. The directory is only there to give
you some kernel header files in case you don't have any. But he has
plenty, and he can link to them all. And thus avoid gdoing kernel
compilatuons that don't work because the right sources are mixed with
the wrong headers.
In favour of RH's horrible arrangement, it makes it easier to maintain
several kernel trees at once in an independent manner. But I don't
care, because I always point /usr/src/linux at whichever one I happen
to be compiling at the mo.
Peter
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Module Compilation Problems
Date: Sun, 3 Dec 2000 21:55:24 +0100
Rand Simberg <[EMAIL PROTECTED]> wrote:
> On Thu, 30 Nov 2000 10:52:20 +0800, in a place far, far away, "Brian"
> <[EMAIL PROTECTED]> made the phosphor on my monitor glow in such
>>I think the default search path for include files is /usr/include. In RedHat
>>6.x, there is a link in that directory: linux -> ../src/linux/include/linux,
>>so you don't have to specify the include path in command line. The link no
>>longer exists in RH 7.0.
> Thank you. I'll update the command line in the source...
No. You should put the link back into the /usr/include directory. And
asm too.
Peter
------------------------------
From: John Reiser <[EMAIL PROTECTED]>
Subject: Re: How to tell version of glibc?
Date: Sun, 03 Dec 2000 12:09:58 -0800
> I am looking for _the_ authoritative way to determining the installed
> version of glibc on a linux system.
Run "objdump --private-headers /lib/libc.so.X" and look at:
=====
Version definitions:
1 0x01 0x0865f4e6 libc.so.6
2 0x00 0x0d696910 GLIBC_2.0
3 0x00 0x0d696911 GLIBC_2.1
GLIBC_2.0
4 0x00 0x09691f71 GLIBC_2.1.1
GLIBC_2.1
5 0x00 0x09691f72 GLIBC_2.1.2
GLIBC_2.1.1
6 0x00 0x09691f73 GLIBC_2.1.3
GLIBC_2.1.2
=====
so that was glibc 2.1.3.
--
John Reiser, [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Module Compilation Problems
Date: Sun, 03 Dec 2000 22:39:55 GMT
Peter T. Breuer <[EMAIL PROTECTED]> wrote:
> Brian <[EMAIL PROTECTED]> wrote:
>> The directory /usr/include/linux is a real one containing lots of header
>> files in RedHat 7.0. You cannot directly restore the link. I don't know why
>> RedHat made this reconstruction, but I think it's better to keep it there.
> Why do you think so? It's wrong. The directory is only there to give
> you some kernel header files in case you don't have any. But he has
> plenty, and he can link to them all. And thus avoid gdoing kernel
> compilatuons that don't work because the right sources are mixed with
> the wrong headers.
Of course, the fact that Linus recommends _not_ linking from
/usr/include into the kernel tends to carry alot of weight with most
people.
> In favour of RH's horrible arrangement, it makes it easier to maintain
> several kernel trees at once in an independent manner. But I don't
> care, because I always point /usr/src/linux at whichever one I happen
> to be compiling at the mo.
And again, since in RH 7.0 you have the option of installing either a
2.2 or 2.4 test kernel, multiple trees are an issue.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Need help understanding /proc/pid/stat file
Date: Sun, 03 Dec 2000 23:09:36 GMT
Thanks, amigo!
Pardon my newbiness. I'm still getting used to "bad docs, but open
source"!
:-)
In article <[EMAIL PROTECTED]>,
Mike Hall <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > Could someone tell me where I can find a precise explanation of
what's
> > what in /proc/pid/stat?
>
> > I'm trying to understand which among these corresponds to cmajflt.
Is
> > there any documentation that describes this exactly?
>
> The routine "static int get_stat(int pid, char * buffer)"
> in /usr/src/linux/fs/proc/array.c should explain it all! :-)
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Liam Moy <[EMAIL PROTECTED]>
Subject: Inode
Date: Sun, 03 Dec 2000 18:38:44 -0500
Hey,
When the inode is copied by the kernel, where is that copy and what is
added to it?
Thanx
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: fh_verify: permission failures
Date: Mon, 04 Dec 2000 00:07:35 +0000
In article <[EMAIL PROTECTED]>, "Conrad Mukai"
<[EMAIL PROTECTED]> wrote:
>
> We have recently set up an NIS/NFS server with the Mandrake 7.2
> distribution. Users mount their home drives with autofs. Everything
> seems to be fine except that the console on the server has the
> following
>
> error messages:
>
> fh_verify: fonts/override permission failure, acc=1, error=13
> fh_verify: share/fonts permission failure, acc=1 error=13
>
> -- end previously posted message --
>
check nfs.sourceforge.net, look at the setattr bit, I suspect it's
really an NFS-ism that generates this message.
karl
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: fh_verify: permission failures
Reply-To: [EMAIL PROTECTED]
Date: Mon, 04 Dec 2000 00:55:09 GMT
On Sun, 03 Dec 2000 19:07:03 +0000, Conrad Mukai <[EMAIL PROTECTED]> wrote:
>I posted this on comp.os.linux.networking earlier, but after tracking
>down the place in the source where the error message was coming from,
>this may be a better place to seek an answer.
>
>-- start previously posted message --
>
>We have recently set up an NIS/NFS server with the Mandrake 7.2
>distribution. Users mount their home drives with autofs. Everything
>seems to be fine except that the console on the server has the following
>
>error messages:
>
>fh_verify: fonts/override permission failure, acc=1, error=13
>fh_verify: share/fonts permission failure, acc=1 error=13
These are just log entries which tell you that NFS is denying certain requests.
The a very likely reason for this may be that the root user is trying to access
a mounted directory. Normally root has access to every file in a filesystem; on
NFS that is not permitted; accesses from the root user ID are ``squashed'' to
some other user ID like nobody, unless the filesystem is mounted with the
no_root_squash option. So, effectively, the permission check takes place as if
user nobody were trying to do the operation.
This is a common mistake, because when you are fiddling with your NFS client
setup, you are probably at a root shell: you are editing fstab, executing mount
commands and so on. So you type ``mount /my/path'' then CD to it and find that
you can't access anything!
Root squashing allows you to export NFS mounts which contain root-owned
executables without worrying that any old user can just su to root and replace
or modify these executables at will. It does nothing for files not owned by
root (other than perhaps reduce the occurence of accidents) since root can
change ID at will to match the owner ID of the files.
------------------------------
** 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
******************************
