Linux-Development-Sys Digest #218, Volume #8 Mon, 16 Oct 00 03:13:10 EDT
Contents:
basic question(s) on libc5 vs. libc6 (Steve Summit)
75E48FC8 Visio for Linux ([EMAIL PROTECTED])
Re: basic question(s) on libc5 vs. libc6 ([EMAIL PROTECTED])
Re: HOWTO? Boundary aligned memory allocation (for PCI device driver) (Joe Pfeiffer)
Re: Driver Loading FPGA Device ("Marius Petrescu, YO2LOJ")
broadcast of ifconfig on Linux ("Bin Zhou")
Re: basic question(s) on libc5 vs. libc6 ([EMAIL PROTECTED])
Re: to sync or not to sync ("St. Otto")
Re: Question About Kernel 2.4.0 Beta's, When Do You Think It will be a Stable
Release? (Ronald Cole)
Re: A new directory hierarchy standard - need opinions ([EMAIL PROTECTED])
Re: basic question(s) on libc5 vs. libc6 (Paul Kimoto)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Steve Summit)
Subject: basic question(s) on libc5 vs. libc6
Date: 16 Oct 2000 02:13:25 GMT
First, apologies if this isn't a Linux question per se.
If it's not, feel free to ignore the rest of this, or let me
know what kind of a question it really is.
I keep hearing references to significant compatibility problems
between two things called "libc5" and "libc6". I've got a few
inklings as to what's going on, but I'd like to know the full
story. I'll start with the (overly comprehensive) questions,
then mention what I think I know.
What are libc5 and libc6? Do they correspond to
particular versions of GNU libc?
What major change was it that precipitated so many
problems? Does it have anything to do with the
rewrite of the stdio portions of libc to integrate
them with C++ iostreams?
What are the compatibility problems? Why doesn't the
normal .so file version number mechanism take care of them?
What does it take to get a "libc5 program" to work on a
"libc6 system", or vice versa? Do some programs require
relinking? Recompilation? Rewriting?
I think I've heard that Linux libc6 is GNU libc version 2.
I gather that it's possible for libc5 and libc6 binaries to
coexist on the same system, but that it isn't automatic or
trivial.
I'm puzzled as to why the compatibility problems were so severe.
(Normally I associate these traumatic, user-visible sea changes --
"Sorry, new world order time; you'll have to throw out all your
old apps and get new ones" -- with that other PC OS vendor.)
I assume that one or more key data structures -- perhaps FILE
in <stdio.h> -- changed significantly, such that programs
compiled/linked for one version of the structure get major
gastric distress if a libc.so comes along that uses a different
structure. (But I'm not at all sure, and this is the part of
the question I'm most curious about.)
Thanks for any information (or pointers to web pages) anyone can
provide.
Steve Summit
[EMAIL PROTECTED]
--
Programming Challenge #6: Don't just fix the bug.
See http://www.eskimo.com/~scs/challenge/.
------------------------------
From: [EMAIL PROTECTED]
Subject: 75E48FC8 Visio for Linux
Date: Sun,15 Oct 2000 21:52:18+2000
Announcing complete new universal drafting program for Linux, FreeBSD, and Sun
Solaris.
LinuxCAD release for FreeBSD, a native FreeBSD build , not an emulation !!!
the details to be found on
WWW.LINUXCAD.COM
Now version 2.26 that has many added features is ready to ship and download.
Useful for preparing any kind of visual diagramming presentation
for any industry or knowledge field, creation of illustrations for books
and reports.
LinuxCAD is more Visual Language for Business then Microsoft Visio ever was !!!
Initially introduced in 1995 LinuxCAD today is very powerful and rock stable
application program for Linux.
The software comes with more than 1500
symbols that allows to use L i n u x C A D as a replacement for such diagramming
tool as Microsoft Visio. That is absolutely right LinuxCAD is more convenient then
Visio
and can be used to replace Microsoft Power Point as well.
LinuxCAD provides features of such programs as AutoCAD, Visio, Power Point
and Corel Draw in a single program for Linux.
linux cad can be used in:
organizational charts ,
business process diagramms,
information network and computer system diagrams,
--> software development flowcharting ,
--> entity relationship diagramming,
network planning,
system administration diagramming and you actually can start
your sysadmin tasks from inside linux cad,
--> mechanical engineering drafting,
pcb and schematic design ( easily integrated with routing programs ),
geographicsl information systems,
any kind of drafting where integration with database is important,
floor plans for buildings and facilities,
--> architectural drafting,
front end for programmable rendering systems like opengl,
--> front end for any software that may require graphics editor functions,
can be used to replace acad in every application later is used !!!
can be used to replace visio diagramming tool in every application later is
used !!!
This message posted in single instance and it is not a spam.
Software Forge Inc.
( developers of the most advanced application software for Linux OS ).
847 891 5971
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: basic question(s) on libc5 vs. libc6
Date: Mon, 16 Oct 2000 04:01:24 GMT
Steve Summit <[EMAIL PROTECTED]> wrote:
> What are libc5 and libc6? Do they correspond to
> particular versions of GNU libc?
glibc 2 is libc6. The previous version of libc was libc5. (ie, they
restarted the numbers when they changed from calling it libc to glibc)
> What major change was it that precipitated so many
> problems? Does it have anything to do with the
> rewrite of the stdio portions of libc to integrate
> them with C++ iostreams?
Most of the pain I suffered was the "death of a thousand cuts." Glibc
added a significant amount of features, and changed a significant
amount of others. That led to breaking large numbers of programs in
little ways.
I should also point out that the first widely used releases of glibc
were pretty bug-prone. Unfortunatly, the benefits it provided over the
existing libc that many vendors moved to it anyway.
> What are the compatibility problems? Why doesn't the
> normal .so file version number mechanism take care of them?
> What does it take to get a "libc5 program" to work on a
> "libc6 system", or vice versa? Do some programs require
> relinking? Recompilation? Rewriting?
The normal version number mechanism actually does. Binaries linked
against libc5 will work fine on libc6 systems, provided libc5 is
present. It's undesireable, however, because of the increased memory
consumption.
Going the other way shouldn't be impossible either, but it's currently
easier to just upgrade the entire machine.
> I'm puzzled as to why the compatibility problems were so severe.
> (Normally I associate these traumatic, user-visible sea changes --
> "Sorry, new world order time; you'll have to throw out all your
> old apps and get new ones" -- with that other PC OS vendor.)
That actually occurs _more_ often on Linux systems than that other OS
you're thinking of. The move from a.out to elf was painful for alot of
users, as was the change in shared libary formats. New kernel releases
also tend to be quite invasive, requiring large portions of the system
to be upgraded.
The other side of that coin, however, is that 'deprecated' features
tend to dissapear much more quickly. It's very unusual now to find a
box that can't run elf binaries for example.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: HOWTO? Boundary aligned memory allocation (for PCI device driver)
Date: 15 Oct 2000 22:38:06 -0600
You need to allocate some extra space, and then adjust the pointer to
be properly aligned. The maximum amount you need to adjust is 2^n-1
(since if you need to adjust by 2^n, you'd already be in the right
place. So the code is something like
mallocptr = malloc(size + (1 << n) - 1);
myptr = (myallocptr + (1 << n) - 1) & ~((1 << n) - 1);
"Jim Fischer" <[EMAIL PROTECTED]> writes:
> I'm working with a board that's running the Linux 2.4.0-test8 kernel, and I
> need to allocate a contiguous block of physical memory whose starting
> address is boundary aligned on a 2^n memory address -- e.g., a 1 MB block of
> physical RAM whose starting address is given by,
>
> m * 0x100000
>
> where 'm' is any non-zero integer (e.g., 0x100000, or 0x200000, or 0xF00000,
> or 0x1200000, etc.). What I'm trying to do is allocate a chunk of physical
> RAM that will ultimately be used as the board's PCI memory space... [FWIW,
> I'm working with an EBSA-285 (i.e., SA110 / 21285 core logic) eval board,
> and I need to associate some physical RAM with the 21285's PCI memory
> address space...] Any suggestions ?
>
>
> Jim
>
>
>
>
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
VL 2000 Homepage: http://www.cs.orst.edu/~burnett/vl2000/
------------------------------
From: "Marius Petrescu, YO2LOJ" <[EMAIL PROTECTED]>
Subject: Re: Driver Loading FPGA Device
Date: Mon, 16 Oct 2000 07:57:57 +0200
> Does anyone have or know of any code that implements
> this?
The YAM driver found in the RH 6.0+ kernel does such thing (FPGA programming
via serial port). Look in the Amateur radio part....
Regards,
Marius Petrescu - YO2LOJ [EMAIL PROTECTED]
------------------------------
From: "Bin Zhou" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,fj.os.linux.networking
Subject: broadcast of ifconfig on Linux
Date: Mon, 16 Oct 2000 14:33:45 +0900
hello there,
Im using Debian GUN/Linux 2.2--with 2.2.16 kernel. It seems to me that, the
/sbin/ifconfig command(version 1.39) performs strange. If I set all IP,MASK
and
broadcast values, everything go OK, but if I only set IP and MASK, not set
the
broadcast, the default broadcast is determinded by the class of the IP,
not the correct value(IP | ^MASK). ex. the broadcast of
172.31.0.1/255.255.255.0
is set to 172.31.255.255, not the 172.31.0.255. Is this the specification or
a bug?
thank you
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: basic question(s) on libc5 vs. libc6
Date: Mon, 16 Oct 2000 05:36:12 -0000
On Mon, 16 Oct 2000 04:01:24 GMT [EMAIL PROTECTED] wrote:
| The normal version number mechanism actually does. Binaries linked
| against libc5 will work fine on libc6 systems, provided libc5 is
| present. It's undesireable, however, because of the increased memory
| consumption.
The memory consumption is finite because both libraries are shared.
If you have 30 processes linked to libc5 and 40 processes linked to
libc6 you have the libraries taking up at most the space of both
just once. That is, as long as everything is shared. We're talking
about less than a meg of memory for libc5, and that isn't a problem
at least on today's machines of 64 meg and larger. Of course if you
are still running on that old 8 meg 386, that's another issue.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: "St. Otto" <[EMAIL PROTECTED]>
Subject: Re: to sync or not to sync
Date: Mon, 16 Oct 2000 07:56:37 +0200
[EMAIL PROTECTED] wrote:
> The compromise I'd like to see is a "soft syncronous". What this would
> do is when a write is requested, the process (or fd for non-blocking I/O)
> would block until the write is STARTED.
Idea: Create an own fileserver (as a background process) and let it do
the filework.
- Send to/get from it the small data packages you need at a special
time in your "real working" process.
- Send some commands to create/read/write/close/remove the needed files
- Request their (the files) status (STARTED WRITE...CLOSED) from this
fileserver.
Regards, St. Otto
------------------------------
From: Ronald Cole <[EMAIL PROTECTED]>
Subject: Re: Question About Kernel 2.4.0 Beta's, When Do You Think It will be a Stable
Release?
Date: 15 Oct 2000 23:14:16 -0700
"Emu" <[EMAIL PROTECTED]> writes:
> I just actually waisted my time asking the question here in the first place.
> I can't understand why this one question returned unforvorable answers.
Because it's a FAQ. You're expected to look at and read the FAQ
before asking questions here to avoid asking one of them for the one
millionth time and getting the response you got.
If you're confused about the concept of a FAQ, I'm sure someone here
will explain it to you.
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.setup
Subject: Re: A new directory hierarchy standard - need opinions
Date: Mon, 16 Oct 2000 06:14:31 -0000
In comp.os.linux.development.system Todd Knarr <[EMAIL PROTECTED]> wrote:
| In comp.os.linux.development.system <[EMAIL PROTECTED]>
|[EMAIL PROTECTED] wrote:
|> When a package has more than a few executeables, or any libraries or
|> data it needs to access, I prefer having the whole package "encapsulated"
|> where I can see where it is, how much space it all takes, remove it all
|> if I want, or tarball it to another machine to run it there.
|
| For viewing, that's what I consider package-management to be for: hold
| all the details on the files in a package no matter where they are on the
| machine. Integrating packages into the regular system also forces me to
| deal with things like library-name conflicts up-front, not later on when
| someone finally decides to use the wrong combination of packages at the
| same time and something blows up.
That has been promoted as one of the features of package management programs.
OTOH, those package management programs have caused me more grief than the
supposed benefit they offer. I've had packages that are incomplete with
the uninstall. And the dependencies get all fouled up when you do have to
install a new version of some package not yet in that package format that
other things depend on (such as the kernel).
|> The disadvantage is that a package may need to have some files shared
|> between many machines and some files separate per machine. Perhaps
|> the best solution would be /usr/opt and /var/opt. Those can either or
|> both be mounted as distinct filesystems as desired.
|
| I usually like /var/{package}, much like /etc/{package} for configuration.
| Why add another level to that directory tree for the same purpose unless
| you need to to avoid name conflicts? Same with /etc. I look at it as being
| that /var and /etc are where files that'll need to be modified by the
| admins go, or where configuration files go, regardless of package. The
| /|/usr|/usr/local division is for stuff related to package management
| issues and whether something's needed during start-up, not writeability
| or access.
That would end up mingling what normally goes in var (things that are not
package names) with package names. What if I name my package "passwd"?
Do I get to have it in /etc/passwd?
How about instead: /var/opt/{packagename} and /etc/opt/{packagename} ?
|> Maybe. See above for /var/opt. But I'll extrapolate into /usr/local/opt.
|> I usually leave /usr mounted read-only and /usr/local mounted writeable.
|
| For normal things, read-only mounting doesn't matter because nobody but
| root should have write access even to /usr/local, let alone /usr ( modulo
| a few exceptions handled via SUID/SGID and proper ownerships ). Any work
| on packages like you describe I do under a regular user, working under
| their own home directory, _then_ port it to system directories when it's
| done via a regular install to confirm that it works right. Keeps down the
| chance of hosing something and forces me to deal with locations and
| permissions without depending on root-specific things.
If nobody but root has write access, then I'd have to be root far more
often than I am now, and then it's even more dangerous, exposing the
system to even more typos. I like to minimize being root. Users in
group "bin" get to write in /usr/* (when mounted r/w) and /usr/local/*
and there are also cases where /usr is network mounted (and then even
more likely to be read-only).
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: basic question(s) on libc5 vs. libc6
Date: 16 Oct 2000 02:30:47 -0500
Reply-To: [EMAIL PROTECTED]
In article <8sdo85$fme$[EMAIL PROTECTED]>, Steve Summit wrote:
> First, apologies if this isn't a Linux question per se.
> If it's not, feel free to ignore the rest of this, or let me
> know what kind of a question it really is.
Here "system" is taken to mean the Linux kernel, so we are off topic, but
anyway ...
> What are libc5 and libc6? Do they correspond to
> particular versions of GNU libc?
libc5 and its predecessors were based on glibc1, apparently considerably
hacked up. libc6 is synonymous with glibc2.
> What are the compatibility problems? Why doesn't the
> normal .so file version number mechanism take care of them?
> What does it take to get a "libc5 program" to work on a
> "libc6 system", or vice versa? Do some programs require
> relinking? Recompilation? Rewriting?
You need either the libc5 (compatibility) libraries, or recompilation.
Some programs require rewriting because it's like porting to a new (but
substantially similar) system.
> I gather that it's possible for libc5 and libc6 binaries to
> coexist on the same system, but that it isn't automatic or
> trivial.
Of course libc5 and libc6 have different sonames. But many problems arose
because many libraries are maintained by others (X, ncurses, ...), and by
convention each of their developers choose the sonames (possibly because
any other convention would require coordination between distributions).
That means that libX11.so.6 on a Linux system could have been built for
libc5 or libc6. Of course, it's unkosher to try to link a libc5-flavored
libX11 into a libc6 binary (et cetera), either at link time or
(dynamically) at runtime.
The dynamic linker system was not built with such a transition in mind, and
so the solutions look rather ad hoc. The person building and installing
each library has the responsibility of indicating whether it's libc5- or
libc6-flavored. One way is to make a notation in /etc/ld.so.conf, which is
propagated into the dynamic-linker cache /etc/ld.so.cache, of which
directories contain libraries of which flavor. The other way is to
explicitly link the shared library (when it's built) to either libc5 or
libc6; the dynamic linker then figures out whether it's allowed to use a
particular shared library at runtime.
(The latter solution, I think, is cleaner. On the other hand, it can lead
to a strange-looking situation if you inadvertently ask ld(1) to link a
wrong-flavored library with libc, since then it complains that you are
trying to link both libc5 and libc6 into the same executable.)
> I'm puzzled as to why the compatibility problems were so severe.
> (Normally I associate these traumatic, user-visible sea changes --
> "Sorry, new world order time; you'll have to throw out all your
> old apps and get new ones" -- with that other PC OS vendor.)
> I assume that one or more key data structures -- perhaps FILE
> in <stdio.h> -- changed significantly, such that programs
> compiled/linked for one version of the structure get major
> gastric distress if a libc.so comes along that uses a different
> structure. (But I'm not at all sure, and this is the part of
> the question I'm most curious about.)
One problem that turned up is that the glibc2 maintainers strongly
discourage application programmers from accessing internal implementations
and such-like undocumented features. Some of these changed between libc5
and glibc-2.0, and others changed between glibc-2.0 and glibc-2.1;
moreover, many items (inadvertently?) exposed to application programmers in
glibc-2.0 were made inaccessable in glibc-2.1.
Among the features introduced in glibc2 is a symbol-versioning system that
reportedly makes it unnecessary ever to increase the libc soname again, and
consequently that old binaries should be able to run with ever new glibc2
versions. It seems that there will always be _some_ binaries that require
rebuilding or rewriting, though.
--
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.
------------------------------
** 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
******************************
