Linux-Development-Sys Digest #317, Volume #8 Sat, 2 Dec 00 18:13:09 EST
Contents:
Re: Linux installer ("Andre Weigandt")
DLL's etc ("Rajagopalan Srinivasan")
Problems with (XDR)-Headers (Lavrentios Servissoglou)
Re: DLL's etc ("Karl Heyes")
Re: Search order for shared libraries (ld-linux.so and ldconfig)
([EMAIL PROTECTED])
Re: this sucks! ("Karl Heyes")
front ending libraries (even libc) ([EMAIL PROTECTED])
Autoconfiscating a loadable module (Kaelin Colclasure)
Re: Search order for shared libraries (ld-linux.so and ldconfig) (Paul Kimoto)
Re: front ending libraries (even libc) (Paul Kimoto)
Re: front ending libraries (even libc) ("Arthur H. Gold")
----------------------------------------------------------------------------
From: "Andre Weigandt" <[EMAIL PROTECTED]>
Subject: Re: Linux installer
Date: Sat, 2 Dec 2000 19:15:48 +0100
Thank you for your reply, but creating an RPM-Package is not quite what I
want to do. I probably explained my point misunderstanding:
what I want is to give useres with nacked (!) PC's the opportunity to
install our peace of software, guiding them thru installation process with a
graphical interface
to help them to configure networking, X (server, resoluting, mouse, keyboard
layout etc.) and anything else. What I'm looking for is a tool which does
some
kind of hardware recongnition and configuration without user interaction and
guides him thru installation. Since I don't want to re-invent the wheel, I'm
looking for it out there :)
<[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:xi7W5.29392$[EMAIL PROTECTED]...
> "Andre Weigandt" <[EMAIL PROTECTED]> writes:
> > we have a small project, where we developed an embedded application
> > based on linux, for browsing internet and playing musik: basicaly
> > only kernel, networking, X, browser and some multimedia stuff (MP3),
> > with very low RAM and Harddisk usage and fast boot. Since we had
> > dedicated hardware, there was no need for installer.
>
> > Some PC users came to use and told, that they don't need more
> > functionality too, and want to have our Software on CD to install it
> > on a regular PC. Now we want to add support for some more hardware,
> > wich is not a problem, and an "newbie-ready" installer.
>
> > Do somebody know any installer programms wich we could use? I know
> > RedHat and Co. have nice graphical installares, but do we have to
> > buy a commercial license for them first? Are there some projects on
> > developing installers for linux? Any information or links or
> > everything else will be greatly appreciated.
>
> You're thinking of RPM, no? <http://www.rpm.org/>
>
> RPM, formerly known as the "Red Hat Package Manager," although, these
> days, is apparently known more recursively as the "RPM Package
> Manager," and was originally sponsored by Caldera [which conspicuously
> is _another company_ than Red Hat Software].
>
> Two misunderstandings appear conspicuous:
>
> a) It's _not_ a graphical "install tool;" it requires no participation
> of anything graphical in order to work;
>
> b) Intensive research demonstrates that the licensing is extremely
> liberal; for more details, please see: <a href=
> "http://www.rpm.org/RPM-HOWTO/index.html"> RPM HOWTO </a>
>
> You may want, as well, to extend your research to include third-party
> "RPM-related" software, which includes a variety of graphical tools to
> select packages; see <a href="http://www.rpm.org/software.html"> RPM
> related software </a> for a list thereof. There are ten "graphical
> front ends" listed of varying provenance; none appear to be
> proprietary to Red Hat Software, save, arguably, for the deprecated
> "grpm" package.
>
> --
> (concatenate 'string "cbbrowne" "@hex.net")
<http://www.ntlug.org/~cbbrowne/>
> E.V.A., pod 5, launching...
------------------------------
From: "Rajagopalan Srinivasan" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: DLL's etc
Date: Sat, 02 Dec 2000 18:46:57 GMT
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
------------------------------
From: Lavrentios Servissoglou <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.development
Subject: Problems with (XDR)-Headers
Date: Sat, 2 Dec 2000 20:45:19 +0100
Hello,
I want to use the XDR macros (routines) to "translate" OS specific data
types to OS independent format and vice versa. The problem I have with
Linux is to find the appropriate header files. I've tried it with
"rpc/rpc.h", "rpc/xdr.h" and a lot of other combinations. Every time the
compiler (g++ (egcs)) complains problems with data types defined in theses
header files. Does anyone know the magic sequence and combination of
appropriate header files.
Thank you very much for your help,
Lavrentios Servissoglou
([EMAIL PROTECTED])
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: DLL's etc
Date: Sat, 02 Dec 2000 20:11:47 +0000
In article
<BsbW5.16894$[EMAIL PROTECTED]>,
"Rajagopalan Srinivasan" <[EMAIL PROTECTED]> wrote:
> folks,
>
> I am looking for some reference on the API for performing operations
> like :
>
> - what dynamic libraries any process is mapped to
lsof -p <pid> (it looks under /proc)
> - given an executable what dynamic libraries are required to run
> the
> exec
ldd <program>
> - any version info wrt the dynamic library etc
ldd <program>
> - also the symbol table (debugging info) inside the exec etc.
>
one of the objdump options should suffice.
karl.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Search order for shared libraries (ld-linux.so and ldconfig)
Date: Sat, 02 Dec 2000 20:11:39 -0000
On Sat, 02 Dec 2000 15:00:47 +0100 Michael Kerrisk <[EMAIL PROTECTED]> wrote:
| Two questions about the search order for shared libraries, one to do
| with run-time name resolution, and one to do with ldconfig.
|
| QUESTION 1
|
| According to ld.so(8) man page the dynamic linker searches for shared
| libraries in the following order
|
| 1. Dirs listed in LD_LIBRARY_PATH
|
| 2. Libraries listed in /etc/ld.so.cache
|
| 3. /usr/lib AND THEN /lib
|
| My tests (SuSE 6.4, kernel 2.2.14, glibc 2.1.3) indicate that the last
| of these is wrong - that is, /lib is searched before /usr/lib. (Using
| the dlopen() API, unsurprisingly, gives the same results)
|
| Am I seeing a configuration issue or a documentation bug? A couple of
| things make me think the latter. One is that the linker (ld) seaches
| for libraries in the order /lib and then /usr/lib. The other is that
| the order seems more 'intuitive' - /lib contains the essential libraries
| for startup, and thus seems a more natural place to start the search.
The order /usr/lib then /lib would seem a bit more natural to me, as this
would allow core minimal libraries to be in /lib and replacements for them
with more stuff in /usr/lib. But I don't know if anyone is doing anything
like this anymore.
| 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.
| QUESTION 2 (Closely related to the previous)
|
| The ldconfig man page isn't precise, but states that in building the
| cache (/etc/ld.so.cache) that it searches for libraries :
|
| "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?
It does seem inverse to my natural order of thinking to go from things that
are more dynamic to things that are more static.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: this sucks!
Date: Sat, 02 Dec 2000 20:20:00 +0000
In article <907oo8$ohn$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> Ok, I've asked two really simple questions soo far in this group,
> but haven't received one single answer. I'm new to linux drivers,
> and I really can't figure out exactly WHAT you all Linux geeks
> thinks is soooo good with linux!? I've written drivers for
> Win95/98/ME/CE/NT4/2000 and that is heaven compared with this shit!
>
> Open source - so what!? A good documentation can't be replaced by
> some nerdish source-code comments!
>
Before sounding off, are _you_ prepared to write good documentation wrt
to this?. Nobody has paid for the documentation.
> Will you please do two things right for once?
People will try, but not everybody will know about kernel related
things.
> 1. Tell me how to open a tty device from a kernel model.
If from a process context then you can use sys_open(....), Do you
need to would be a better question.
karl.
------------------------------
From: [EMAIL PROTECTED]
Subject: front ending libraries (even libc)
Date: Sat, 02 Dec 2000 20:38:40 -0000
I'm starting to take a look at what might be needed to do library front
ending. What I mean by that term is this. An existing library, such as
libc, will have a complete set of its own functions. The front ending
library will have a subset of the functions (possibly just a few, maybe
even just one). I want to have, AT RUN TIME, for the front end library
to be preferred over the back end library for dynamic linkage. If the
symbol is defined in the first library found, use that. But if it is
found not in the first, but in the second, use that. There needs to be
not conflict with respect to the fact that the second library also has
the same symbols found in the first. I'm thinking of the first library
as a sort of mask layed over the second, hiding some symbols and having
its own versions of them instead.
The above I think is easy. Here's where it get's tricky.
The first library needs to be able to call the second library, even with
symbols the first library is exporting to the programs being linked to it.
And this needs to be done with no recompiling or relinking of either the
second library or the program being run to use them. I will be root if
I am going to specify anything on LD_LIBRARY_PATH, and usually will be
configuring all this via ld.so.conf, so security for suid programs is not
an issue. I will have full liberty in coding, compiling, and linking the
front end (first) library. And I can modify ld.so if that is needed.
Has anyone already done anything like this, or have in suggestions on how
I should pursue it (other that giving up)?
What is this for?
Just promise that you won't suggest alternatives. I hate when people do
that. I'm specifically asking in this post how to do library front ending
and not the broader question of how to do the following. And I do not
want to patch existing libraries. I know I can, but I have reasons for
not wanting to do it that way, and the reason for not saying what that is,
is because to do so will result in a long and pointless thread that will
do nothing but waste time and bandwidth.
1. Change the behaviour of readdir() to return filenames in sorted order.
2. Change lots of file I/O functions to perform pathname remapping.
3. Change defaults on how certain system functions are called for some
programs.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Autoconfiscating a loadable module
Date: 02 Dec 2000 13:03:57 -0800
Has anyone devised a workable configuration for having a Linux
loadable kernel module compiled and installed using the standard GNU
autoconf tools? I'm in the process of "autoconfiscating" OpenTNF
<http://opentnf.sourceforge.net/>, and even after crawling through a
reasonable chunk of the documentation available I haven't seen any
pointers on this.
I realize that loadable modules are usually build as part of the
kernel source tree; however, this particular kernel module is a horse
of a slightly different color. Its function is to provide a buffering
subsystem at the kernel level in support of a larger system. SO,
logically it makes sense to distribute, compile, and install the whole
shebang as one distribution -- using autoconf, etc.
-- Kaelin
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Search order for shared libraries (ld-linux.so and ldconfig)
Date: 2 Dec 2000 17:11:46 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Michael Kerrisk wrote:
> One is that the linker (ld) seaches
> for libraries in the order /lib and then /usr/lib.
As far as I know, the _documented_ behavior is for ld(1) to look in the
places where it is told to (with -L/some/directory) and the default places
(established at ld-compile time); and in the usual binutils setup, the
default directories include /usr/lib but _not_ /lib.
--
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: [EMAIL PROTECTED] (Paul Kimoto)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: front ending libraries (even libc)
Date: 2 Dec 2000 17:31:10 -0500
Reply-To: [EMAIL PROTECTED]
This is not a c.o.l.d.system (i.e., kernel) matter. Followups redirected.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I'm starting to take a look at what might be needed to do library front
> ending. What I mean by that term is this. An existing library, such as
> libc, will have a complete set of its own functions. The front ending
> library will have a subset of the functions (possibly just a few, maybe
> even just one). I want to have, AT RUN TIME, for the front end library
> to be preferred over the back end library for dynamic linkage. If the
> symbol is defined in the first library found, use that. But if it is
> found not in the first, but in the second, use that. There needs to be
> [no] conflict with respect to the fact that the second library also has
> the same symbols found in the first. I'm thinking of the first library
> as a sort of mask layed over the second, hiding some symbols and having
> its own versions of them instead.
>
> The above I think is easy. Here's where it get's tricky.
I believe that you can just LD_PRELOAD the first library, as long as the
second library's (duplicated) functions are "weak".
> The first library needs to be able to call the second library, even with
> symbols the first library is exporting to the programs being linked to it.
You should be able to call some libc functions by their alternate names,
e.g., open() => __open(), if you want to replace the default open(). It
appears that most libc functions aren't available in the way, however. But
because the common Linux libraries are LGPL, you could just rewrite the
desired functions and put them in your first library, eliminating the need
to call the second library's affected functions.
> And this needs to be done with no recompiling or relinking of either the
> second library or the program being run to use them. I will be root if
> I am going to specify anything on LD_LIBRARY_PATH, and usually will be
> configuring all this via ld.so.conf, so security for suid programs is not
> an issue. I will have full liberty in coding, compiling, and linking the
> front end (first) library. And I can modify ld.so if that is needed.
>
> Has anyone already done anything like this, or have in suggestions on how
> I should pursue it (other that giving up)?
>
> What is this for?
>
> Just promise that you won't suggest alternatives. I hate when people do
> that. I'm specifically asking in this post how to do library front ending
> and not the broader question of how to do the following. And I do not
> want to patch existing libraries. I know I can, but I have reasons for
> not wanting to do it that way, and the reason for not saying what that is,
> is because to do so will result in a long and pointless thread that will
> do nothing but waste time and bandwidth.
>
> 1. Change the behaviour of readdir() to return filenames in sorted order.
>
> 2. Change lots of file I/O functions to perform pathname remapping.
>
> 3. Change defaults on how certain system functions are called for some
> programs.
--
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.
------------------------------
Date: Sat, 02 Dec 2000 16:25:47 -0600
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: Re: front ending libraries (even libc)
[EMAIL PROTECTED] wrote:
>
> I'm starting to take a look at what might be needed to do library front
> ending. What I mean by that term is this. An existing library, such as
> libc, will have a complete set of its own functions. The front ending
> library will have a subset of the functions (possibly just a few, maybe
> even just one). I want to have, AT RUN TIME, for the front end library
> to be preferred over the back end library for dynamic linkage. If the
> symbol is defined in the first library found, use that. But if it is
> found not in the first, but in the second, use that. There needs to be
> not conflict with respect to the fact that the second library also has
> the same symbols found in the first. I'm thinking of the first library
> as a sort of mask layed over the second, hiding some symbols and having
> its own versions of them instead.
>
> The above I think is easy. Here's where it get's tricky.
>
> The first library needs to be able to call the second library, even with
> symbols the first library is exporting to the programs being linked to it.
>
You'd have to use LD_PRELOAD to put the "dispatching
library" in the right place in the link order to do what you
want. You can get access to the underlying library calls
though the use of "dlsym(RTLD_NEXT, symbol_name )".
There are, however, _bunches_ of potential semantic
difficulties, depending upon what other libraries happen to
be linked to a process; pthreads is one example, as it
redefines certain quasi-system calls.
> And this needs to be done with no recompiling or relinking of either the
> second library or the program being run to use them. I will be root if
> I am going to specify anything on LD_LIBRARY_PATH, and usually will be
> configuring all this via ld.so.conf, so security for suid programs is not
> an issue. I will have full liberty in coding, compiling, and linking the
> front end (first) library. And I can modify ld.so if that is needed.
>
> Has anyone already done anything like this, or have in suggestions on how
> I should pursue it (other that giving up)?
As you might guess, I've done most of the research for a
project like this, have the design and some of the code for
a generalized framework to ease development using function
interposition, and a nearly-completed virtual memory tracing
tool that is based (for other reasons -- i.e. the asymmetry
in behavior between pure user level code and system calls --
or, inconsistently, their libc-wrappers -- in the presence
of memory protection) upon this very idea.
>
> What is this for?
>
> Just promise that you won't suggest alternatives. I hate when people do
> that. I'm specifically asking in this post how to do library front ending
> and not the broader question of how to do the following. And I do not
> want to patch existing libraries. I know I can, but I have reasons for
> not wanting to do it that way, and the reason for not saying what that is,
> is because to do so will result in a long and pointless thread that will
> do nothing but waste time and bandwidth.
>
> 1. Change the behaviour of readdir() to return filenames in sorted order.
>
> 2. Change lots of file I/O functions to perform pathname remapping.
>
> 3. Change defaults on how certain system functions are called for some
> programs.
>
In the small sense, it's really pretty easy, especially if
you're limiting yourself to higher-level system calls. Be
aware, however, that much of libc can be somewhat
frustrating, primarily if the functions upon which you want
to interpose are called internally in libc (you'd probably
need to expose some symbols from libc that are not normally
exported -- a fairly simple rebuild).
I'd be happy to take this off-line, if you'd like.
HTH,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account
for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
"Curiousity didn't kill _this_ cat"
-- Studs Terkel, upon being asked what he thinks his epitaph
should be.
------------------------------
** 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
******************************
