Linux-Development-Sys Digest #320, Volume #8 Mon, 4 Dec 00 03:13:09 EST
Contents:
Re: Module Compilation Problems ("Peter T. Breuer")
Re: kernal image ("Peter T. Breuer")
Toronto, Kylix is coming! ("TDUG")
[Q] Building PMON ? ("Tae-sung Kim")
Hayes compatiple modem driver (Brian Liedtke)
Re: CIFS.. (Volker Kuhlmann)
Re: Module Compilation Problems (Paul Kimoto)
Re: Hayes compatiple modem driver (Glitch)
Re: how to rebuild tcp code (peter@nospam)
Re: Need library reference (Mark Healey)
A challenging problem... (Kaelin Colclasure)
Re: kernal image (Josef Moellers)
----------------------------------------------------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Module Compilation Problems
Date: Mon, 4 Dec 2000 02:13:24 +0100
[EMAIL PROTECTED] wrote:
> 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.
Why should linus recommend so? I imagine he simply doesn't want kernel
headers at all in the include hierarchy, thus decoupling kernel and
libraries completely. That's an OK goal. But ...
.. unfortunately, they're not entirely decouplable yet. That means that
distros have to put some headers back in order to make include work.
That in turn means that when you change the kernel sources, the kernel
.c files start being compiled by default with the wrong .h files. This
can be coped with OK if you get people to use the kernel makefiles, which
compensate appropriately. But it plays havoc with compilations of third
party kernel modules.
So I say "no". There was nothing wrong with putting in links to the
kernel sources for all these years.
>> 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.
But apparently the problems caused for people who now can't compile
their third party modules aren't? Yet another instance of "if you're on
redhat, you can't compile"? No thank you. Gimme the symlink.
Peter
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: kernal image
Date: Mon, 4 Dec 2000 02:17:34 +0100
[EMAIL PROTECTED] wrote:
> On Thu, 30 Nov 2000 08:33:34 +0100 Josef Moellers
><[EMAIL PROTECTED]> wrote:
> | Yeung Ming wrote:
> |> i want to know how many kernel images for a computer that have 4 CPUs? I
> |> think it is one only because it ctrls all CPUs
> | There is only one kernel image, but there are four "threads of execution".
> | Compare it to four cooks working in a kitchen with only a single cooking
> | book.
> And most of the time the four cooks know what they are cooking and only
> occasionally need to consult the cookbook. This is the CPU cache.
Ummm .. who ordered the meal? And how many ovens do they have, come to that?
;.)
Peter
------------------------------
From: "TDUG" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development,comp.os.linux.development.apps
Subject: Toronto, Kylix is coming!
Date: Mon, 04 Dec 2000 01:58:55 GMT
Hello,
Kylix* is coming! And you probably have questions about the exciting new
Borland Linux development tool that combines the Rapid Application
Development (RAD) benefits of visual component based design, with the power
of an optimizing native code compiler. No such application development tool
exists for Linux today, and there is a tremendous demand for Kylix both from
the Linux development community and millions of developers on Windows today
who wish to develop for Linux.
Join the Toronto Delphi Users Group (TDUG) on December 4th where you will
have the opportunity to be among the few world wide to get a sneak peek of
Kylix! We will have a Borland representative on hand to demo Kylix and
answer your questions. Also enter to win door prizes!
The purpose of the group is to help Delphi developers by providing a forum
to meet and discuss development issues with other Delphi developers and to
learn new Delphi development techniques. Please drop by and feel free to
bring your developer friends with you.
Date: Monday Dec 4th
Time: 7-10pm
Location: North York Public Library. Yonge and Park Home Ave., North of
the 401 between Sheppard and Finch.
Cost: Free
For more information: please visit TDUG at www.tdug.com
See you there!!
*About Kylix
Kylix is intended to be the first high performance rapid application
development (RAD) platform for the Linux platform. Kylix is a component
based development environment for two way visual development of graphical
user interface (GUI), Internet, database and server applications. Kylix
will be powered by a new high-speed native Delphi/C/C++ compiler for Linux
and will implement a native Linux, and cross platform version of the Borland
VCL (Visual Component Library) architecture called CLX. CLX is designed to
radically speed native Linux application development and simplify the
porting of Delphi and C++ Builder applications between Windows� and Linux
operating systems.
------------------------------
From: "Tae-sung Kim" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded
Subject: [Q] Building PMON ?
Date: Mon, 4 Dec 2000 11:45:58 +0900
I'm trying to build PMON(boot loader for MIPS processor) on Linux box.
To do that, I have installed SDE-MIPS 4.0 cross compiler.
As far as I know, there are two phases in building PMON.
In first phase, it compiles host tools and in seconde phase it
builds PMON for mips processor.
I got a probelm in the first phase and had error message like below.
### tools
make[1]: Entering directory `/home/mips/pmon/tools'
gcc -DLANGUAGE_C -o pmcc misc.o
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
misc.o: In function `Malloc':
misc.o(.text+0x23): undefined reference to `_iob'
misc.o: In function `appendFile':
misc.o(.text+0x55): undefined reference to `vflag'
misc.o(.text+0x6a): undefined reference to `_iob'
misc.o(.text+0x9c): undefined reference to `_iob'
misc.o(.text+0xab): undefined reference to `Exit'
.
.
.
.
.
.
.
In above error message, the main function is missed in misc.o and it looks
like caused by broken makefile.
But, I guess there are some mistakes in setting environment variables for
compiler toolset.
Are there anybody having experience like this?
Thanks in advance.
My environment is
-Red Hat release 6.1
-gcc version egcs-2.91.66 19990341/Linux (egcs-1.1.2 release)
============================
Tae-sung Kim
R&D Department
MEDIALINCS Co., Ltd.
Keopyung B-Town, 203,Nonhyun-dong, Kangnam-gu, Seoul ,135-010, Korea
email : [EMAIL PROTECTED]
AOL : corba20
ICQ : 11913444
http://www.medialincs.com
------------------------------
From: Brian Liedtke <[EMAIL PROTECTED]>
Subject: Hayes compatiple modem driver
Date: Mon, 04 Dec 2000 03:02:43 GMT
I've been looking for a driver for a Hayes compatable V.34 modem.
Anybody here have any ideas?
Brian Liedtke
------------------------------
From: [EMAIL PROTECTED] (Volker Kuhlmann)
Subject: Re: CIFS..
Date: 4 Dec 2000 05:00:23 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Lew Pitcher) writes:
>>The linux smbfs seems to work now, but the dates and times it displays
>>for files are completely shot (the linux fat fs is buggy too - where do
>>I report this to?).
>
> It could be your setup rather than smbfs and msdos support. If you
> don't have timezones and your clock properly configured, the MSDOS
> file dates look screwy.
I don't think there's any linux distribution these days which does not
set up the timezone. What specifically can be done wrong there?
My /etc/localtime is a copy of /usr/share/zoneinfo/NZ. Environment
variable TZ is unset. My fat fs is compiled into the kernel. Is that
not enough?
It is a very common bug to
1) subtract rather than add time zone offsets (e.g. mkisofs, isofs)
2) Assume time zone offsets are identical for each file on the file system
(e.g. mkisofs, sharity <= 2.3)
On top of at least one of those, the minutes are stuffed with fat fs in
some cases.
Volker
--
Volker Kuhlmann ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Module Compilation Problems
Date: 4 Dec 2000 00:34:38 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Peter T. Breuer wrote:
>[EMAIL PROTECTED] wrote:
> .. unfortunately, they're not entirely decouplable yet. That means that
> distros have to put some headers back in order to make include work.
> That in turn means that when you change the kernel sources, the kernel
> .c files start being compiled by default with the wrong .h files. This
> can be coped with OK if you get people to use the kernel makefiles, which
> compensate appropriately. But it plays havoc with compilations of third
> party kernel modules.
>
> So I say "no". There was nothing wrong with putting in links to the
> kernel sources for all these years.
Isn't this the reason for the /lib/modules/$(uname -r)/build symlink in
2.4.*?
> But apparently the problems caused for people who now can't compile
> their third party modules aren't? Yet another instance of "if you're on
> redhat, you can't compile"? No thank you. Gimme the symlink.
Or Debian.
$ zcat /usr/share/doc/libc6/README.Debian.gz
Q1: Why does the Debian libc6-dev package create /usr/include/linux and
/usr/include/asm directories containing header files from a specific
kernel, instead of using the "established" convention of making those
directories into symlinks pointing to the currently installed kernel?
A1: Occasionally, changes in the kernel headers cause problems with
the compilation of libc and of programs that use libc. To ensure that
users are not affected by these problems, we configure libc to use the
headers from a kernel that is known to work with libc and the programs
that depend on stable kernel headers.
Q2: What if I want to compile a program that needs a feature from a
later kernel than is used by libc?
A2: In practice, most programs will not have this problem. However,
depending on the scope of the problem you have several options available:
If the situation is one like "kernel driver development", where all use
of the machine for development is expected to be against a different set
of kernel headers than are supplied with the "stock" libc6-dev, rebuilding
the glibc packages against that particular kernel will create a full set of
libc6 packages that are "compliant" with the new kernel. All development
done on machines with these packages installed will be done against the
new kernel. To build libc6-dev against your particular kernel, export the
environment variable ksource, set to the path to that particular kernel and
build the package.
If you want this new glibc package to stick against further upgrades, simply
use dselect and place the packages on HOLD. This will keep them from being
upgraded against your wishes.
If there is just one particular program/package that needs different headers,
and your kernel of choice is installed in the usual place, you can use the
-I/usr/src/linux/include option on the gcc command line, when compiling that
specific program.
--
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: Mon, 04 Dec 2000 01:05:56 -0500
From: Glitch <[EMAIL PROTECTED]>
Subject: Re: Hayes compatiple modem driver
a real modem doesn't neeed a driver. if your modem isnt' a winmodem u
dont need a driver, just plug it in and tell linux what Com it's using.
Brian Liedtke wrote:
>
> I've been looking for a driver for a Hayes compatable V.34 modem.
>
> Anybody here have any ideas?
>
> Brian Liedtke
------------------------------
From: peter@nospam <[EMAIL PROTECTED]>
Subject: Re: how to rebuild tcp code
Date: 3 Dec 2000 21:21:39 -0800
In article <[EMAIL PROTECTED]>, Rex says...
>to set
>echo 42 > /proc/sys/net/ipv4/tcp_retries2
>
Rex,
does one need to re-start the network on linux after modifying
those parameters for them to take effect?
thanks,
peter
------------------------------
From: [EMAIL PROTECTED] (Mark Healey)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Need library reference
Date: Mon, 04 Dec 2000 07:28:20 GMT
On Sun, 3 Dec 2000 11:03:32, "Robert J. Hansen" <[EMAIL PROTECTED]>
wrote:
> > I'm really new to linux and only marginaly familiar with C.
>
> Pick up a copy of _The C Programming Language_ if you want to learn C. It's
> a little dense going, but plenty worth it. Barring that, O'Reilly Press has
> some good books on C. Avoid "C for Dummies" and the like at all costs.
I don't think I was clear. I really need a library reference that I
can browse. For instance: I'd like to look at all the functions that
have to do with environmental variables or all the functions that deal
with strings.
> > I probably need a tutorial but for now I'd like a library reference
> > and for the life of me can't find it.
>
> 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.
>
> > Also, is there a IDE type front end for GCC?
>
> Try kdevelop.
Krap, I didn't install it. Is there anything for Gnome?
Mark Healey
marknews(the 'at' thing)healeyonline.com
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.lisp
Subject: A challenging problem...
Date: 03 Dec 2000 23:54:15 -0800
This is going to take a bit of explaining, so let me apologize in
advance for the length of this post.
Assume that a few months from now I've developed a facility for
tracing the execution of a system of arbitrary processes running on a
single Linux host. Ideally, these processes are "trace aware" and
contain embedded diagnostic output routines (hereafter *probes*) which
add application-specific information to the trace data collected.
But certain basic data, like the system calls made, can be collected
even from non-aware processes.
This facility is designed so that any program can readily be made
trace aware -- regardless of what programming language it happens to
be written in. There is (probably) special support for C -- because so
much of Linux is coded in C, and C (being a portable assembler) makes
certain low-level optimizations both desirable and feasible. There is
also special support for (one or more implementations of) Common Lisp
-- because the author of the facility considers Lisp one of the more
useful programming languages. In general, however, any language that
can somehow output a string can arrange to add information to an
ongoing trace.
The tracing facility is controlled using a command called trex. trex
basically behaves like a Unix shell, but processes started under trex
(and their children, and so on) have their probe output collected in a
trace[1]. trex also has various commands for interactively controlling
trace aware processes with dynamic probe support. Basically, dynamic
probe support allows trex to attach to an already running process,
selectively enable specific probes, and later (after collecting the
desired trace information) detach -- leaving the process running as
before.
[1] Trace aware processes that are *not* running under trex either
have their probe output discarded, or detect that it would be
discarded and don't produce any probe output at all.
Okay -- snap back to the present. My problem lies in how to implement
dynamic probe support. Solaris' prex has the equivalent of this
feature, but only for C programs. I suspect prex implements it by
scanning the ELF executable files for certain signature data
associated with each embedded probe. I'm pretty sure prex enables and
disables the probes by poking data into the traced processes' data
segment in memory. Not trivial, but not rocket science. But it relies
on the fact that in C it's relatively straightforward to affect the
layout of the processes' text and data segments (e.g. to embed the
probe signatures) in a predictable way.
Now, the question is how best to approach this feature given that I
also want to support dynamic probes for Common Lisp -- and in general
to come up with a technique that can be made to work for languages
that don't allow you to approximate the behavior of an assembler. (Java
would of course be another example.)
There are practical constraints which preclude a solution which is
overly intrusive to traced processes. For this reason, suggestions
involving traditional IPC techniques, specialized event-loops in trace
aware processes, etc. are likely to be dismissed out of hand. My
inclination is to limit trex's interaction with traced processes to
the following mechanisms:
-- the ptrace system call
-- POSIX signals and signal handlers
-- the facilities of a common kernel module (tnf trace buffer
support)
ptrace is necessary to the implementation of some of trex's features
anyway, and all of these mechanisms have one trait in common: they
have nominally *no* impact on a process that trex is not tracing.
I've got a few ideas in mind, but this post is definitely getting
long (and anyway the goal is to fish for suggestions) so I'll limit
myself to a few bullet points:
-- Turn probes on/off by poking into the traced processes' address
space with ptrace, but how to find where to poke? Particularly in
GC'd languages where things move around...
-- Use preprocessors to catalog the probes in an executable? One for
C, one for Common Lisp, one for Java, etc.
-- Devise a probe signature that can be embedded in some sort of
string constant, and scan for those using ptrace?
-- Require that probe-aware processes link in a special signal
handler, then use a signal to notify a traced process to read some
sort of probe control block via an ioctl to the /proc/tnf/trace
file descriptor?
Less byzantine suggestions (that still meet the constraints) are
welcome. :-)
-- Kaelin
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: kernal image
Date: Mon, 04 Dec 2000 08:57:43 +0100
"Peter T. Breuer" wrote:
> =
> [EMAIL PROTECTED] wrote:
> > On Thu, 30 Nov 2000 08:33:34 +0100 Josef Moellers <josef.moellers@fuj=
itsu-siemens.com> wrote:
> > | Yeung Ming wrote:
> > |> i want to know how many kernel images for a computer that have 4 C=
PUs? I
> > |> think it is one only because it ctrls all CPUs
> > | There is only one kernel image, but there are four "threads of exec=
ution".
> > | Compare it to four cooks working in a kitchen with only a single co=
oking
> > | book.
> > And most of the time the four cooks know what they are cooking and on=
ly
> > occasionally need to consult the cookbook. This is the CPU cache.
> =
> Ummm .. who ordered the meal? And how many ovens do they have, come to =
that?
The user ordered the meal by selecting from a menu, obviously.
The number of ovens depends on the architecture of the kitchen^WCPU.
There are kitchen^WCPUs that have several ovens^WArithmetic Units that
can work in parallel.
> ;.)
Yes, I know, but the analogy is so straightforward ...
-- =
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
------------------------------
** 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
******************************
