Linux-Development-Sys Digest #91, Volume #7 Mon, 23 Aug 99 06:14:08 EDT
Contents:
Re: Adding a non-standard Parallel Port (Peter Samuelson)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Jonas Utterstrom)
Re: Having a problem loggin in, need help (Peter Samuelson)
Re: More kind words from M$. (Peter Samuelson)
gdb trace of GUI apps core dumping on printf's (Dimi Shahbaz)
__this_module??? (Josef Moellers)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(Josh Stern)
Re: Linux assembly, etc (Etienne Lorrain)
Re: More kind words from M$. (Peter Samuelson)
Re: "current" while DMA (Peter Samuelson)
Re: Linux - Memory model / protection scheme (Chris Butler)
printer daemon problem (FIT)
Re: Customizing Shared Lib( *.so) files... (Peter Samuelson)
Re: Can I compile the kernel using a cc other than gcc? (Peter Samuelson)
Re: real-time kernel module (Mogens Dybaek Christensen)
Re: Calling a BIOS interrupt (Etienne Lorrain)
Re: Linux - Memory model / protection scheme (Robert Kaiser)
Re: Shared Libraries: what is the linux equivalent of "dllimport" and "dllexport"
(John Hughes)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Adding a non-standard Parallel Port
Date: 23 Aug 1999 02:54:17 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Norm Dresner]
> > Alas, I'm using the 2.0.36 kernel. Can I still do this?
[Robert McGwier <[EMAIL PROTECTED]>]
> Time to upgrade.
Mmmm, not until Linux 2.2.12 comes out (RSN) and has been tested a
little. Everything since 2.2.7 has been iffy, though I gather 2.2.11
is OK with the three or four patches in the online release notes.
I no longer have 2.0 source installed here (running 2.3.5 until they
fix nfs client in newer 2.3.x...), but IIRC you can look in
drivers/char/lp.c both for changing the source and for seeing if there
are any kernel command-line parameters (i.e. lilo.conf stuff).
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Jonas Utterstrom <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
Date: Mon, 23 Aug 1999 07:54:03 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
[...]
> > >You got me uncertain so I made two shared libraries. No linking
> > >problems, but the function from the first linked library was always
> > >used.
> >
> > by code in both libraries?
>
> The dynamic loader makes note of which symbols are needed as a library
> says it needs it, if it comes across the definition of that symbol in
> the same library or later it will resolve the symbol *and* *remember*
> *it* *for* *later* *resolutions* - If the next library needs the same
> symbol resolved, the dynamic linker sees that it already knows where
to
> find the definition and uses that.
>
> I think you can force non-PIC behaviour for specific symbols when you
> link the second library at compile time, but I'm not sure how.
Mr Tristan Wibberley is correct. I just wanted to add that in my case, I
used functions with different names in the exe. These two functions used
an internal function, with the same name in both libraries. And the
function from the first shared linked library was always used.
/JOnas U
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Having a problem loggin in, need help
Date: 23 Aug 1999 03:43:49 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Advanced one corporation <[EMAIL PROTECTED]>]
> I'm having a problem loggin in. After I have logged in to my
> localhost by typing in root and then my password, this message
> appears:
> [root@localhost /root#
> What does this message mean and what do I type.
It means you are logged in. If you do not know what to do at this
point, you most likely do not want or need Linux.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.misc
Subject: Re: More kind words from M$.
Date: 23 Aug 1999 02:37:17 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Brett Hall <[EMAIL PROTECTED]>]
> Well as long as you don't count all the gobbledy-gook the prepend to
> every word to tell you what kind of word it actually is ;)
LOL!
I have it from reliable sources that the real Hungarian language does
*not* do this.... (:
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Dimi Shahbaz <[EMAIL PROTECTED]>
Crossposted-To: gnu.g++.help,comp.windows.x.kde,linux.dev.c-programming,comp.os.linux.x
Subject: gdb trace of GUI apps core dumping on printf's
Date: Mon, 23 Aug 1999 02:14:34 -0700
OK, I ran kapptemplate (a simple code generator script for creating simple,
empty KDE applications) , and with the resulting code, I added this line to
the testWidget constructor:
testWidget::testWidget(QWidget *parent, const char *name)
: QWidget(parent, name)
{
printf("line 1\nline 2\nline 3\n");
}
This is similar to what I've always done; putting printf's in various
places in my code (even GUI code) is how I like to debug, and it has never
given me problems. Now, however, the line above gets me a core dump
(without the printf, the program runs without problems):
$ ./test
line 1
Segmentation fault (core dumped)
It prints the first line OK, but whenever there are 2 newlines, either in
the same printf, or total in different ones, my programs are now dumping
core. I dont know what could cause this, because it worked before. Here
is a gdb backtrace of the core:
#0 0x5523c08 in ?? ()
#1 0x402627e7 in _IO_new_file_xsputn (f=0x805b3a0, data=0x8059570, n=21)
at fileops.c:822
#2 0x8055e88 in filebuf::xsputn () at testwidget.moc.cpp:57
#3 0x40252980 in _IO_vfprintf (s=0x805b3a0, format=0x8059570 "line 1\nline
2\nline 3\n", ap=0xbffffae4)
at vfprintf.c:1048
#4 0x4025a720 in printf (format=0x8059570 "line 1\nline 2\nline 3\n") at
printf.c:31
#5 0x80516ba in testWidget::testWidget (this=0x80861c8, parent=0x8085a10,
name=0x0) at testwidget.cpp:6
#6 0x805117f in test::test (this=0x8085a10) at test.cpp:14
#7 0x805180d in main (argc=1, argv=0xbffffd14) at main.cpp:15
Seemed at first to be a screwy glibc (in file fileops.c), so I reinstalled
it from the rpm, but same results. If I run:
$ ./test &> ./output
The program runs normally, putting my printf with all 3 lines in the file
'output', as well as running the empty gui app itself, but after I hit exit
in the program, I get a seg fault, and the backtrace there is:
#0 0x8c08055e in ?? ()
#1 0x4022e5e4 in exit (status=0) at exit.c:62
Again, this is glibc (exit.c is in glibc, isnt?) Does anyone have any
ideas as to what this could be? Has anyone experienced anything similar?
RH5.2, x86, qt-1.42, kde-1.1.1, glibc-2.1.1-7, egcs-2.90.29 980515
(egcs-1.0.3 release)
Thank you very much in advance,
Dimi
------------------------------
From: Josef Moellers <[EMAIL PROTECTED]>
Subject: __this_module???
Date: Mon, 23 Aug 1999 10:08:52 +0200
Hi,
I recently stumbeled across the following problem:
After installing and re-configuring a RedHat6.0 system, the system
wouldn't come up.
It would hang when displaying the message "Finding module dependencies".
A further analysis showed that this was a consequence of an undefined
symbol "__this_module" in various modules. The amount of error messages
produced was so big, that the process running depmod was suspended since
the syslog daemon wasn't running yet and the pipe was filling up.
The question is: where is "__this_module" defined? I can't find it in
any include- nor c-source file. Is it some generic name to be defined
external in some Makefile?
Josef
-- =
PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the autor=B4s personal views only!
------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
From: [EMAIL PROTECTED] (Josh Stern)
Date: Mon, 23 Aug 1999 09:07:01 GMT
Jonas Utterstrom <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Josh Stern) wrote:
>> My hypothesis
>> of why Netscape is so big is a) it has a lot of features,
>> and b) it was coded with the priority of minimizing time to market
>> for a complex cross-platform app. Your "explanation" of why
>> the Netscape executable is so big - because C++ shared libraries
>> are much bigger than C shared libraries - was nonsensical bullshit.
>I am a C++ programmer so I am not trying to fuel the C vs C++ flamewar.
>I just compare with the size of Windows dlls. And the fact is that i.e.
>Mozilla is twice as big in Linux.
There is something missing here. I can't figure out if it
is a breakdown in logic, English comprehension, or basic
understanding of what a shared library is. So let's review:
On Linux, with Communicator 4.6, we have the *executable* size, which
*does not* include the shared libraries that it dynamically links
with, coming in at approximately 14 MB. This is big, but it is
*not* measuring the size of any shared libraries. If you want to
see which shared libraries it links with you look at the output
of the command ldd `which netscape`. There you see a bunch of
different libs that do different things, but these libraries
are not distributed with netscape. They perform various other
collections of functions having nothing to do with Netscape,
so their size is irrelevant to the discussion. So the first
question for you to answer is "What size are you talking about?"
and the second question is "If this size is different on
Linux and Windows, how can it be attributed to a difference
between C and C++ dynamic library sizes?" The second question
completely baffles me, not only because the first hasn't
been answered, but also because you haven't described any
reason to believe that different percentages of C and C++
are used in the Linux and Windows versions. So my response
is not about defending C++ - the point is rather that you
are simply not making any sense. Whatever you seem to
be claiming is not only not correct, it's not even
incorrect! There is some kind of failure in the presuppositions
of your whole analysis.
>> The run time performance depends on what gets loaded when.
>> On Linux, resolution of references from a shared library
>> is 'lazy' by default, meaning that they are resolved as
>> needed during execution, so a particular module of code
>> that is not used is likely to remain un-read on disk.
>> Try 'man dlopen'. Or better yet, just adopt an empirical
>> approach to the question and experiment as I suggested
>> previously.
>I do not really see your point here. One of the good things with shared
>libraries is that they aren't loaded until they are actually used. But
>when they are used, also the internal classes used by the public
>interface will be loaded.
Read the man page again. It clearly says that
when lazy evaluation is used (which is the default) then these
references are resolved as needed during execution.
>And they will pollute the global symbol-table
>for the dynamic linker.
The namespace pollution issue is orthogonal to the size
one. In an earlier post I suggested that C++ namespaces
could help with the original poster's problem of avoiding
conflicts and polluting the global namespace. Other
useful suggestions for linker commands were posted by
other people.
- Josh
------------------------------
From: Etienne Lorrain <[EMAIL PROTECTED]>
Subject: Re: Linux assembly, etc
Date: Mon, 23 Aug 1999 09:44:12 +0100
Nix wrote:
> ...
> *shudder* we'd be back in the good old segment world.
>
> (And I wonder how long it'd take for the abortion which was far pointers
> to reappear?)
I wonder if it would be possible to build the "non executable stack"
patch by reducing the maximum addess of segment "cs".
The code segment limit had to be changed at each task switch,
but no INVLPG necessary.
In fact the question is: is it possible to have some
dynamic libraries at a higher address than the stack ?
Comments?
Etienne.
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.misc
Subject: Re: More kind words from M$.
Date: 23 Aug 1999 02:44:52 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Tristan Wibberley <[EMAIL PROTECTED]>]
> Alternatively, he can say
>
> unplea~1 . unpleasa. ntly .
You're forgetting Unicode. It actually becomes
UNPLEA~1 and u^@n^@p^@l^@e^@^O^@�a^@s^@a^@n^@t^@l^@^@^@y^@
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: "current" while DMA
Date: 23 Aug 1999 03:56:52 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Yung-Hsiang Lu <[EMAIL PROTECTED]>]
> I try to classify device activities according to their requesting
> processes and find the processes use a device the most.
It's pretty much impossible to automatically pinpoint a particular
process responsible for a particular run of I/O (including DMA). The
problem is that file I/O and network I/O are both buffered.
What are you *really* trying to do?
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Chris Butler)
Subject: Re: Linux - Memory model / protection scheme
Date: 22 Aug 1999 22:06:15 +0100
[comp.os.linux.development.system - 22 Aug 1999 03:00:51 +0200] * Ulrich wrote *
> Note that on Windows NT, you can also corrupt the KERNEL32 data
> (and on Linux, you can corrupt libc data ...). There, however,
> this only means that *your process* crashes, because every process
> uses its private copy of KERNEL32 (or libc, for that matter).
This is wrong, actually. Every Linux process uses the same copy of libc in
memory. However, processes cannot write to the libc pages, since they are
setup with protections of read/execute only, and a write operation will
cause a processor exception. Linux will receive this and send a SIGSEGV to
the offending process.
Note: This is also how the copy-on-write is implemented in the kernel,
used for read-write shared pages, except the page is copied to the
program's own address space instead of a SIGSEGV being sent.
--
Chris Butler
<[EMAIL PROTECTED]>
------------------------------
From: FIT <[EMAIL PROTECTED]>
Subject: printer daemon problem
Date: Mon, 23 Aug 1999 12:07:23 +0200
Hello,
using a red hat 6.0 GPL distribution I encountered the following problem
which up to now turned out to be too hard for me to crack:
I cannot start the printer (spool) demon lpd, no matter what tricks I
try. I cannot start it from the command line (/etc/rc.d/rc5.d/Sxxlpd
start) nor with an init script (no matter what run level I chose). Even
if lpd is the only service apart from kernel daemon and sys logger at
that run level it is not started. If I want to print using 'lpr' I get
the message 'lpd: connection denied, jobs queued but cannot start
daemon). If I do not start X and thus see more of the boot messages I
notice the error message 'ld 'fx' respawning too fats - suspended for
five minutes'. As I assume this may be causative for later problems I
tried to work on that but no way.
So I should be extremely thankful if somebody would be so kind as to
advise me how too tackle thease problems.
Thank You very much in advance
Arno R. Schleich
--
Functional Imaging Technologies GmbH
Siemensstr. 40/41
12247 Berlin
Germany
fon.: +49 (0)30 76 90 24 80
fax.: +49 (0)30 76 90 24 81
mailto:[EMAIL PROTECTED]
htp://www.functional-imaging.com
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Customizing Shared Lib( *.so) files...
Date: 23 Aug 1999 04:03:14 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[8623805 <[EMAIL PROTECTED]>]
> Are there any utilities that can remove some
> specific components from a shared library(ie. *.so) file ?
No. I don't know enough about how ELF linking works to understand
exactly why not, but shared objects are similar to executables in that
you can't change stuff like that once they're linked.
> For example, if I am sure that all my programs never call
> printf() , I can remove the definition for it from the
> standard C library.
What Debian has done on boot floppies is build a PIC version of libc
statically, then relink *that* into a custom .so at floppy image build
time. Even then you are limited to the granularity of an original
object file.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.portable
Subject: Re: Can I compile the kernel using a cc other than gcc?
Date: 23 Aug 1999 03:14:16 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Kaz Kylheku <[EMAIL PROTECTED]>]
> You have to use GCC because the kernel is written using the
> extensions of GNU C. Taking out those extensions would be a major
> undertaking.
Hmmmm, how many of those extensions are used in arch-independent code,
I wonder? And I know some GNU extensions (__attribute__ comes to mind)
were designed to be easy to dispose of in the preprocessor if needed.
Some (like typeof) obviously are not.
Wasn't Metrowerks at least somewhat interested in implementing enough
GNU extensions so that the kernel could take advantage of their (said
to be superior) CodeWarrior PowerPC compiler?
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Mogens Dybaek Christensen <[EMAIL PROTECTED]>
Subject: Re: real-time kernel module
Date: Mon, 23 Aug 1999 08:06:17 GMT
Take a look at this:
http://www.rt.db.erau.edu/experiments/unix-rt/experiments/Experiment-6.html
It explains how to change scheduling for a process.
See also "Linux kernel module programming guide" from LDP.
The bad news: in my experiment for a driver, a process using SCHED_FIFO
and a nanosleep loop seems to almost monopolize the CPU. - X, telnet and
the like stops, but the machine can be pinged.
Just now I think there may be a bug, since my test-process runs nicer
when I am _not_ nice to the system. i.e. when I remove the nanosleep
call before re-polling an input port.
This is kernel 2.2.6.
In article <01beecaf$17c6f7a0$30ea4e0c@nilrem>,
"Norm Dresner" <[EMAIL PROTECTED]> wrote:
> Have you looked at Real-Time Linux? (IIRC, www.rtlinux.org)
> Norm
>
> Netnoice <[EMAIL PROTECTED] > wrote in article
> <[EMAIL PROTECTED]>...
> > I was reading that with linux we can change the standard scheduler;
> > but I haven't understood if is it possible for a kernel mode module
to
> > became a real time task (I need it to reply quickly to an irq
signal)
> >
> > Thank you
> > Netnoice
> >
>
--
Mogens Dybaek Christensen, mailto:[EMAIL PROTECTED]
Adtranz Signal A/S, Denmark
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Etienne Lorrain <[EMAIL PROTECTED]>
Subject: Re: Calling a BIOS interrupt
Date: Mon, 23 Aug 1999 10:06:16 +0100
Chris Butler wrote:
> So, it looks like it _does_ get HD info from the BIOS. Although it DOES
> also probe the IDE bus directly when the IDE driver initialises. The
> reason for doing it both ways can probably be explained by a kernel
> hacker :-)
IHMO, even if Linux is using LBA when available, it still need
to know the CHS understood by the BIOS, for instance for "fdisk"
to fill in the partition table. Also some BIOS reserves the last
sector/track of a disk for testing purposes, and so reduces
the number of "declared" ones in BIOS.
I am not sure that this is really used in the kernel.
Etienne.
------------------------------
From: [EMAIL PROTECTED] (Robert Kaiser)
Subject: Re: Linux - Memory model / protection scheme
Date: 23 Aug 1999 08:32:02 GMT
In article <7ppoo7$bv9$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Chris Butler) writes:
> [comp.os.linux.development.system - 22 Aug 1999 03:00:51 +0200] * Ulrich wrote *
>> Note that on Windows NT, you can also corrupt the KERNEL32 data
>> (and on Linux, you can corrupt libc data ...). There, however,
>> this only means that *your process* crashes, because every process
>> uses its private copy of KERNEL32 (or libc, for that matter).
>
> This is wrong, actually. Every Linux process uses the same copy of libc in
> memory. However, processes cannot write to the libc pages, since they are
> setup with protections of read/execute only, and a write operation will
> cause a processor exception.
I think he was referring to libc's _data_ section. This has to be
read/write or else libc wouldn't work. What you describe is how the
_code_ section of libc is shared. So you are both right :-)
Rob
================================================================
Robert Kaiser email: rkaiser AT sysgo DOT de
SYSGO RTS GmbH
Mainz / Germany
------------------------------
From: John Hughes <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Shared Libraries: what is the linux equivalent of "dllimport" and
"dllexport"
Date: 23 Aug 1999 11:36:23 +0200
Jonas Utterstrom <[EMAIL PROTECTED]> writes:
> If a library is twice as big, it takes longer to load.
What do you mean by big? ls does not show you how much code/data the
library contains.
Shared libraries are not loaded. The pages that are used are loaded.
Having a large symbol table could slow down the initial lookup of
symbols.
--
John Hughes <[EMAIL PROTECTED]>,
Atlantic Technologies Inc. Tel: +33-1-4313-3131
66 rue du Moulin de la Pointe, Fax: +33-1-4313-3139
75013 PARIS.
------------------------------
** 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
******************************
