Linux-Development-Sys Digest #729, Volume #7 Sun, 2 Apr 00 18:13:09 EDT
Contents:
Re: How do I make shared libraries? (Paul Kimoto)
Re: compiling an older kernel on a 2.2 kernel machine (Paul Kimoto)
Re: How compatible is Linux with .. Linux (Dr H. T. Leung)
Re: How compatible is Linux with .. Linux (Grant Edwards)
Re: How compatible is Linux with .. Linux (Kaz Kylheku)
Partition Access ("Someone Insignificant")
Re: How compatible is Linux with .. Linux ([EMAIL PROTECTED])
Re: How compatible is Linux with .. Linux (Alexander Viro)
Re: System.map location (Jerry Peters)
Re: How compatible is Linux with .. Linux ("Peter T. Breuer")
Re: How compatible is Linux with .. Linux ("Peter T. Breuer")
Re: How compatible is Linux with .. Linux (Peter Mardahl)
Re: How compatible is Linux with .. Linux (Don Waugaman)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: How do I make shared libraries?
Date: 2 Apr 2000 15:10:05 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Allin Cottrell wrote:
> Why is anyone still using egcs?
Because Alan Cox does not guarantee successful use of gcc-2.95* for 2.2.*
kernels?
So, why does Alan Cox still use egcs?
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: compiling an older kernel on a 2.2 kernel machine
Date: 2 Apr 2000 15:22:49 -0500
Reply-To: [EMAIL PROTECTED]
In article <38e7789e.360708@news>, q_49@hot###mail.com wrote:
>>: On 2 Apr 2000 13:52:50 GMT, "Peter T. Breuer" <[EMAIL PROTECTED]>
>>: wrote:
>>:> Nothing. The running kernel makes no difference.
> How can you relate my questions to me being "dense"? . What I can
> relate is that I can inferr from your reply below that you SEEM to
> have an attitude problem. The question I was asking was how do I set
> up the source tree for my desired kernel within the confines of my
> current linux distro with its 2.2 kernel source tree. This was in
> effect my first question. Your answer was "nothing". Well obviously
> this is not the case. The earlier kernel's source tree has to be set
> up somehow . I was just looking for pointers on how best to go about
> this.
I suppose that PTB was implicitly answering the question, "How does
compiling an earlier kernel differ from compiling a later kernel?"
The answer is, for 2.* kernels and probably back at least to 1.2.*,
"not at all, the running kernel makes no difference."
Now, it should be no surprise that it is possible to compile a later
kernel on a system running an earlier one. So, if you believe PTB's
advice, you can now RTFM and follow the directions therein.
/usr/src/linux/README
http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Dr H. T. Leung)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 2 Apr 2000 20:17:06 GMT
Sorry, I totally agree with the rest of your post about the fact that it is
really just glibc version plus kernel version, plus other shared library
dependency, that is relevant for the compatibility.
But I just want to comment on one thing: Slackware 7 does ship with the rpm
tools; in fact it uses the /usr/src/rpm/{RPMS,SPECS,BUILD,SRPMS}
heirachy rather than the /usr/src/redhat/{} . In fact I have been using the
rpm tools from SW 3.4 (SW didn't ship it with their distribution before 7.0,
but it is still usable). Only two things need to be beared in mind:
(1) Usually it requires "rpm --initdb" to intialise the database before
using it for the first time.
(2) all the dependency checking, etc, doesn't work. most of the time, it
requires "--nodeps" to force an installation of an rpm package.
But I totally agree - the software should be packaged in some non-distro
specific format... and probably come with its own shell script for
dependency checking, etc.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kaz
Kylheku) writes:
<snipped>
|> Slackware 7 does not, for instance. It's reasonable for an
|> installation script to require tar and gunzip; it's not reasonable to
|> require
|> rpm tools.
--
--------------------------------------------------
"What you don't care cannot hurt you." Chap. 7a, AMS-NS
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: Sun, 02 Apr 2000 20:31:58 GMT
In article <8c80ku$482$[EMAIL PROTECTED]>, Peter T. Breuer wrote:
>In comp.os.linux.development.apps q_49@hot###mail.com wrote:
>: Well said Rod. Mr. Breuer also made some unseemly comments in
>: response to a question I asked. His answers are usually condescending
>: and invariably unhelpful. It seems that this is "normal" behavior
>: for him, I pity his co-workers. It is consoling to know that his
>: attitude is in the minority.
>
>What world do you live in? Producing software is a technically difficult
>task. It requires technical expertise, not politeness and good manners!
If you want to work with me, it requires both. But then, maybe I'm odd that
way -- I expect the people I work with to behave in a professional manner.
>Indeed, politeness is culpable homicide in the technical
>area.
That sentence doesn't even make sense. Homicide is an act. Culpable is an
adjective describing a blameworthy person. A person who commits homicide
may be culpable, but the homicide itself isn't
>I recommend you to fly in a plane controlled by a software written by
>a technical incompetent you were too "polite" to tell to go and fix
>his software.
I feel sorry for you if you lack the interpersonal skills required to tell
somebody that their software needs to be fixed without being rude to them.
You must lead a lonely and frustrating life.
Go away and stop back after you've graduated from Jr. High School.
--
Grant Edwards grante Yow! The entire CHINESE
at WOMEN'S VOLLEYBALL TEAM all
visi.com share ONE personality --
and have since BIRTH!!
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Reply-To: [EMAIL PROTECTED]
Date: Sun, 02 Apr 2000 20:35:31 GMT
On 2 Apr 2000 20:17:06 GMT, Dr H. T. Leung <[EMAIL PROTECTED]> wrote:
>
>Sorry, I totally agree with the rest of your post about the fact that it is
>really just glibc version plus kernel version, plus other shared library
>dependency, that is relevant for the compatibility.
Actually it's not *quite* so simple as I implied; there is also the issue of
what compiler was used to build the libraries. Arguably, a glibc-2.1.2 built
with, say, gcc 2.91 is not the same library as glibc-2.1.2 built with, say gcc
2.95, unless shown otherwise.
------------------------------
From: "Someone Insignificant" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development,comp.os.linux.development.apps,linux.dev.c-programming,linux.redhat.development
Subject: Partition Access
Date: Sun, 02 Apr 2000 20:23:36 GMT
Ive been haveing a bit of trouble locateing information on partition access
in Linux. The Linux information scattered throughout the internet has an
abundance of knowledge aimed at users, system administrators, etc, but for a
developer, information is becomming harder to find.
Specifically, what I need to be able to do is:
a) determine the disk drives attached to a system.
b) determine the partitions on those disk drives.
c) seek/read/write blocks on any of the detected partitions.
Im developing an application that needs this level of control, as it is
basically a storage manager for a database system that is not unlike oracle.
So far, I can read partions just by opening the device ( /dev/hda1 ) for
example, however, I cant find the specifications to determine the block size
of the device, the number of blocks on the device. Also, standard calls to
the C library lseek() function are limited to a maximum of 2 gig.
Solutions such as reading the information from the /proc filesystem simply
are not adequate. This would work fine if I were developing a shell script
or simple program, however, this library is part of a much larger system,
and needs fine grained control and as close a route to the source of the
information as possible.
The disk-partition howto does an excellent job of explaining what a
partition is, but provided no information whatsoever on programming api's or
library calls. ( As is the case with most info available on the net these
days. )
Its times like these when I wish I had a nice, cushy cubicle in RedHat, just
down the hall from the fileing cabinet where this type of information is
undoubtedly stored, but, short of that, I am hopeing someone can throw up
specific links to this type of info.
I have posted requests for such information on this in the past, and
received well meaning responses from people who suggested I dont do this, or
develop my application this way. Quite simply, dont bother. This is the way
it needs to be written.
The application in question will be the only application accessing these
partitions, and for now, I have typed them as CP/M, as the chances of
someone out there having a CP/M partition seemed to me to be a rare
circumstance.
In any case, if someone has this info handy, please, toss a link up here,
and educate "the masses."
mike
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How compatible is Linux with .. Linux
Crossposted-To: comp.os.linux.development.apps
Date: Sun, 02 Apr 2000 20:51:26 GMT
In comp.os.linux.development.apps Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> Not very, and it sucks donkey dung anyway for the purpose of software
> installation. It works best for the base packages of a given Linux
> distribution, not as a general installation mechanism. You'd be better off
> creating your own installer which just unpacks compressed tape archives and
> copies things into the right place. As soon as you write some interactive
> installer which has some UI that asks the user questions, the packaging format
> becomes irrelevant. You want to choose a standard one, like gzipped tar, that
> is supported on all the platforms. Not all Linux distributions come with the
> rpm tools: Slackware 7 does not, for instance. It's reasonable for an
> installation script to require tar and gunzip; it's not reasonable to require
> rpm tools.
I disagree. RPM is far and away a better choice than writing a shell
script to ask questions. If a package actually needs that much
configuration, it's probably best to ship a seperate program to
generate the configuration after it's installed.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 2 Apr 2000 16:55:56 -0400
In article <[EMAIL PROTECTED]>,
Grant Edwards <[EMAIL PROTECTED]> wrote:
>I feel sorry for you if you lack the interpersonal skills required to tell
>somebody that their software needs to be fixed without being rude to them.
>You must lead a lonely and frustrating life.
... or have a life beyond soothing the lusers. Take your pick. Had it ever
occured to you that aside of the skills it takes a motivation?
--
All that blue light from Orthanc at night? That was Saruman, trying to
moderate news.admin.palantir-abuse.sightings.
Mike Andrews in the Monastery
------------------------------
From: Jerry Peters <[EMAIL PROTECTED]>
Subject: Re: System.map location
Date: Sun, 02 Apr 2000 21:00:43 GMT
Don't know if this will help, but there's a lilo option which will tell
you IIRC the lilo name for the booted kernel, ie the name you gave to
lilo when asked what kernel to boot. My needs are much simpler, since
I generally keep only multiple versions around, not multiple variations
on the same version.
Jerry
D. Stimits <[EMAIL PROTECTED]> wrote:
> Jerry Peters wrote:
>>
>> D. Stimits <[EMAIL PROTECTED]> wrote:
>> > Moritz Franosch wrote:
>> >>
>> >> "D. Stimits" <[EMAIL PROTECTED]> writes:
>> >>
>> >> > I'm trying to find out where in the kernel it decides that it must
>> >> > read /boot/System.map, so I can create alternate locations and names.
>> >> > I'd like to boot multiple kernels without having to repoint sym links
>> >> > first.
>> >>
>> >> You can call the file System.map-`uname -r` (e.g. System.map-2.2.14).
>> >>
>> >> Moritz
>>
>> > So far this seems to work best. It simply requires compiling the
>> > EXTRAVERSION info into each kernel. My only problem with this is that
>> > all kernels must have different minor versioning added to them. If
>> > System.map could be explicitly stated at one location (each
>> > application using System.map has its own search hierarchy *compiled*
>> > in, rather than using a query from the kernel or a config file),
>> > kernels and System.map files could be stored as pairs, in a more
>> > organized sub directory structure, like /boot/2.2.14/smp/,
>> > /boot/2.2.14/uni/, so on.
>>
>> So, have one of your startup scripts symlink from /boot/whatever/somemore/
>> System.map to /boot/System.map or wherever else you need it.
>>
>> Jerry
> If I use the same kernel name but simply point at different
> subdirectories, how will the script know which kernel was actually
> booted, in order to do the right sym link? I'd be back to creating
> EXTRAVERSION changes for every kernel and thus for every module that
> isn't part of the kernel compile.
> It isn't a particularly important problem, and most people will never
> need to worry about a dozen kernels, but it is annoying at times when
> needed. I wish there was a *simple* way to specify which System.map to
> use, but it really is more of an issue of the various applications
> that use it, rather than the kernel. On the other hand, it would be
> nice if the kernel had a query_system_map_path() function to return a
> path that could be compiled in to the kernel, directly; unfortunately,
> all the apps would also have to be rewritten to use this.
> Since there is exactly one System.map per kernel, paired to match the
> one kernel, it would make sense for the kernel to have that
> information embedded in it, and for applications to ask the kernel
> which map to use. An entire set of paths could even be used, such as
> "/System.map:/boot/System.map:/usr/src/linux/System.map" being the
> default if there was no manual override.
>>
>> > Admittedly though, this is a bit of nitpicking. I wouldn't have even
>> > noticed it if not for the number of testing configurations I've gone
>> > through lately. Modules that are not part of the kernel require
>> > recompiling for every minor version number, even if the rest of the
>> > changes in the kernel are irrelevant to the module.
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 2 Apr 2000 21:35:28 GMT
In comp.os.linux.development.system Grant Edwards <[EMAIL PROTECTED]> wrote:
:>Indeed, politeness is culpable homicide in the technical
:>area.
: That sentence doesn't even make sense. Homicide is an act. Culpable is an
: adjective describing a blameworthy person. A person who commits homicide
: may be culpable, but the homicide itself isn't
Well, (1) it's a tautology, and (2) culpable decribes a quality of the
act, and (3) I was indicating the gravity of the technical offense.
Indeed, homicide can be a consequence of poor software, given that
software controls our lives. I had this sensation the other day when I
saw the votes for the general election being counted electronically. I
couldn't help but wonder which bug they hadn't caught, and what it was
doing. You _know_ that every piece of software contains bugs.
:>I recommend you to fly in a plane controlled by a software written by
:>a technical incompetent you were too "polite" to tell to go and fix
:>his software.
: I feel sorry for you if you lack the interpersonal skills required to tell
: somebody that their software needs to be fixed without being rude to them.
: You must lead a lonely and frustrating life.
:-). If you do have the technical skill, then you'll know that one
doesn't have to be rude. If they have pride in what they are doing,
the truth, or a close approximation is enough. If they don't have
pride, then yes, you have to be rude and blunt. It's exactly as
though you were dealing with a laboror hired to build you a new
kitchen. If you don't insist, they'll give you what they feel like
giving you, instead of what you need or want.
: Go away and stop back after you've graduated from Jr. High School.
Oh, I graduated, alright.
Peter
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 2 Apr 2000 21:39:14 GMT
In comp.os.linux.development.system Kaz Kylheku <[EMAIL PROTECTED]> wrote:
: On 2 Apr 2000 20:17:06 GMT, Dr H. T. Leung <[EMAIL PROTECTED]> wrote:
:>
:>Sorry, I totally agree with the rest of your post about the fact that it is
:>really just glibc version plus kernel version, plus other shared library
:>dependency, that is relevant for the compatibility.
: Actually it's not *quite* so simple as I implied; there is also the issue of
: what compiler was used to build the libraries. Arguably, a glibc-2.1.2 built
: with, say, gcc 2.91 is not the same library as glibc-2.1.2 built with, say gcc
: 2.95, unless shown otherwise.
There's also the horrible issue of C++ binary compatibility. Same
libraries different compiler can ruin your day.
And then we get onto minor version differences (aka bugs). I'm having
a wonderful time trying to get jdk 1.2 work with anything on
everything. I can get it 95% of the way, then ld.so, glibc minor
version, and crossing your fingers, kicks in as to whether it works or
not.
And as to PATHS, aaaaargh.
Peter
------------------------------
From: [EMAIL PROTECTED] (Peter Mardahl)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 2 Apr 2000 21:50:09 GMT
I think the safest/least effort thing to do is simply to generate a static ELF binary
that works on the 2.2 series of kernels.
That should work with every modern distribution. It's possible it may fail on some
really, really old installations of Linux.
A "better" thing to do might be to dynamically link your executable, BUT also make
available ALL the libraries which may be needed dynamically. If the program finds
itself being installed on a system without the needed libraries, have your installer
put in the needed libraries too.
PeterM
In article <[EMAIL PROTECTED]>,
H. McKame <[EMAIL PROTECTED]> wrote:
>Hi
>
>My company is currently finishing its product on Red Hat 6.1.
>Given the multiplicity of Linux versions, we are worried about
>distributing our product on Linux in general.
>
>You out there that have already gone this route, could you please
>share your experience:
>
>- How compatible are Linux versions between vendors on the executable
>format (a.out), and on the object format (.o) ? On what Linux versions
>will a pre-link on RedHat 6.1 link and execute correctly ?
>- How does one measure this compatibility (egcs version? glibc
>version? xf86 version?)
>- How general is the rpm packaging format for the release?
>
>Our thanks in advance for any answer
>--
>Harry McKame, Paris, France
>mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 2 Apr 2000 14:54:01 -0700
In article <8c80ku$482$[EMAIL PROTECTED]>,
Peter T. Breuer <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.apps q_49@hot###mail.com wrote:
>: Well said Rod. Mr. Breuer also made some unseemly comments in
>: response to a question I asked. His answers are usually condescending
>: and invariably unhelpful. It seems that this is "normal" behavior
>: for him, I pity his co-workers. It is consoling to know that his
>: attitude is in the minority.
>What world do you live in? Producing software is a technically
>difficult task. It requires technical expertise, not politeness and
>good manners! Indeed, politeness is culpable homicide in the technical
>area.
>I recommend you to fly in a plane controlled by a software written by
>a technical incompetent you were too "polite" to tell to go and fix
>his software.
You are equating politeness with inassertiveness. That's a singularly
bad trap to fall into. Technical correction can be done in polite
manner. Being polite in correcting someone does not mean being some
kind of milquetoast. Pointing someone asking for help in the right
direction does not give you free rein to insult their ignorance (which
is *not* the same as a lack of intelligence).
Compare for instance:
"From your question, I'm not sure you have enough of a technical background
on Linux at the moment to be able to do much with the answer I'd have to
give you. Perhaps you should either rephrase the question somewhat, giving
a brief overview of the issues you know about already, or have someone with
a broader technical background ask this question."
with what you wrote. This makes substantially the same point you made in
your initial reply, and cuts no slack by comparison, but is *more* likely
to have a positive response simply because it is *more polite*.
Politeness is the oil that lubricates contact points in any system of two
or more humans. Don't throw sand in the gears just because you think it's
the only way to get your point across - that reflects more on you than on
who you are communicating with.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
It's not hard to meet expenses; they're everywhere.
------------------------------
** 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
******************************
