Linux-Development-Sys Digest #55, Volume #8 Sun, 30 Jul 00 22:13:15 EDT
Contents:
Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ? (Michael Meding)
Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ? (Grant Edwards)
undefined symbols in modules (F. Heitkamp)
Re: exec*() and argv[0] (Mario Klebsch)
Re: undefined symbols in modules (Daniel R. Grayson)
Linux memory perfomance is horrible ("S V")
Re: library to implement NFS (phil hunt)
Re: library to implement NFS (phil hunt)
Re: undefined symbols in modules (Yu Jaemin)
Re: Good Basic compiler for linux? (ECStahl)
Re: problem with open files (Alexander Viro)
Re: exec*() and argv[0] (John Reiser)
get_blk vs ext2_getblk ("Pankaj Ratan Lal")
Re: Can i get a MAC address? (Remo Inverardi)
GNU Compiler and Libraries (Remo Inverardi)
Re: pthreads (Remo Inverardi)
Re: GNU Compiler and Libraries (Alexander Viro)
Multiple Threads and File Locking (Remo Inverardi)
Re: Multiple Threads and File Locking (Kaz Kylheku)
Re: GNU Compiler and Libraries (Frank Sweetser)
signal a user space process from interrupt routines ("Peter Huang")
----------------------------------------------------------------------------
From: Michael Meding <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ?
Date: Sun, 30 Jul 2000 07:10:05 +0200
Reply-To: [EMAIL PROTECTED]
Thanks for your answer. I'll check on this.
Thing is though that XF4.01 consistently is a no go.
Mybe I mixed up something in my system also.
Regards
Michael
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: GCC 2.95.2 problems on RedHat 6.2 -- help anyone ?
Date: Sun, 30 Jul 2000 15:56:39 GMT
On Sun, 30 Jul 2000 07:10:05 +0200, Michael Meding <[EMAIL PROTECTED]> wrote:
>Thing is though that XF4.01 consistently is a no go.
Does it always fail in the same place with the same error
messages? If yes, then it's probably not hardware -- you might
have it configured incorrectly.
If it fails "randomly" in different places in different files,
then it's more likely a hardware problem.
--
Grant Edwards grante Yow! Somewhere in Tenafly,
at New Jersey, a chiropractor
visi.com is viewing "Leave it to
Beaver"!
------------------------------
From: [EMAIL PROTECTED] (F. Heitkamp)
Date: Sun, 30 Jul 2000 12:06:25
Subject: undefined symbols in modules
Reply-To: [EMAIL PROTECTED]
I have several kernel projects involving modules.
When I compile my modules using "gcc -c module.c -DMODULE \
-D__KERNEL__ -o module.o" and then use insmod to
insert the module, I get several undefined symbols.
The symbols are various kernel api routines. Why do
I get the undefined symbols, and how can I resolve
them? BTW this is a PowerPC Linux system using the
2.2.10 kernel. insmod is version 2.1.121.
Fred
These are the errors that insmod gives.
53c770.o: unresolved symbol virt_to_phys
53c770.o: unresolved symbol in_be16
53c770.o: unresolved symbol out_8
53c770.o: unresolved symbol in_8
53c770.o: unresolved symbol init_timer
53c770.o: unresolved symbol __fswab32
53c770.o: unresolved symbol virt_to_bus
53c770.o: unresolved symbol out_be32
53c770.o: unresolved symbol __restore_flags
53c770.o: unresolved symbol out_be16
53c770.o: unresolved symbol udelay
dsp56k.o: unresolved symbol __get_user_bad
dsp56k.o: unresolved symbol __put_user_bad
dsp56k.o: unresolved symbol udelay
ser_hypercom4.o: unresolved symbol queue_task
ser_hypercom4.o: unresolved symbol mark_bh
ser_hypercom4.o: unresolved symbol __restore_flags
ser_hypercom4.o: unresolved symbol unregister_serial
ser_hypercom4.o: unresolved symbol register_serial
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Subject: Re: exec*() and argv[0]
Date: Sun, 30 Jul 2000 17:01:59 +0200
[EMAIL PROTECTED] writes:
>If a script makes a reference to a different version of an
>interpreter by means of a specific path, that interpreter should
>have, in a convenient and PORTABLE way, the actual path used to
>invoke it. The interpreter may need access to private libraries or
>locale data or anything else specific to its function.
For many years, there was a wildy used, portable way to do this:
Specify the path at compile time!
I know, especially people converting from DOS/Windows do not liek this
aproach, as it does not work with binary distribution, but binary
distribution is evil, anyway.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
------------------------------
Subject: Re: undefined symbols in modules
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Date: 30 Jul 2000 12:15:23 -0500
For this one, at least, I bet the routine gets inlined by gcc for the other
kernel components, but you are probably not specifying a high enough level of
optimization to get this one inlined in your module.
extern inline void init_timer(struct timer_list * timer)
{
timer->next = NULL;
timer->prev = NULL;
}
=============================================================================
[EMAIL PROTECTED] (F. Heitkamp) writes:
> I have several kernel projects involving modules.
> When I compile my modules using "gcc -c module.c -DMODULE \
> -D__KERNEL__ -o module.o" and then use insmod to
> insert the module, I get several undefined symbols.
> The symbols are various kernel api routines. Why do
> I get the undefined symbols, and how can I resolve
> them? BTW this is a PowerPC Linux system using the
> 2.2.10 kernel. insmod is version 2.1.121.
>
> Fred
>
> These are the errors that insmod gives.
>
> 53c770.o: unresolved symbol virt_to_phys
> 53c770.o: unresolved symbol in_be16
> 53c770.o: unresolved symbol out_8
> 53c770.o: unresolved symbol in_8
> 53c770.o: unresolved symbol init_timer
> 53c770.o: unresolved symbol __fswab32
> 53c770.o: unresolved symbol virt_to_bus
> 53c770.o: unresolved symbol out_be32
> 53c770.o: unresolved symbol __restore_flags
> 53c770.o: unresolved symbol out_be16
> 53c770.o: unresolved symbol udelay
>
> dsp56k.o: unresolved symbol __get_user_bad
> dsp56k.o: unresolved symbol __put_user_bad
> dsp56k.o: unresolved symbol udelay
>
> ser_hypercom4.o: unresolved symbol queue_task
> ser_hypercom4.o: unresolved symbol mark_bh
> ser_hypercom4.o: unresolved symbol __restore_flags
> ser_hypercom4.o: unresolved symbol unregister_serial
> ser_hypercom4.o: unresolved symbol register_serial
------------------------------
From: "S V" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Linux memory perfomance is horrible
Date: Sun, 30 Jul 2000 17:24:11 GMT
there is a little benchmark list compiled at
http://www.phystech.com/download/ubench.html
and it consistently shows Linux memory benchmarks
are 6-7 (!) times lower than FreeBSD or Solaris 8
on the same hardware.
The CPU perfomance seems to be OK compared
to FreeBSD but still lower than Solaris 8.
The seems to be a problem with Linux memory subsystem
or, maybe, glibc memory functions, why would simple
malloc and memcpy be so slow under Linux?
Cordially,
S.V
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: library to implement NFS
Date: Sun, 30 Jul 2000 18:47:13 +0100
On 29 Jul 2000 15:55:03 GMT, J.H.M. Dassen (Ray) <[EMAIL PROTECTED]> wrote:
>J.H.M. Dassen (Ray) <[EMAIL PROTECTED]> wrote:
>>"Pgfs" (Postgres filesystem) is an NFS interface to a PostgreSQL database;
>>unfortunately I don't have a pointer to it handy.
>
>Found it: http://noframes.linuxjournal.com/lj-issues/issue42/1383.html
This says the software can be downloaded from www.wv.com; unfortunately
I can't find it there.
--
***** Phil Hunt *****
The RIAA want to ban Napster -- so boycott the music industry!
Don't buy any CDs during August (especially on Tuesday 1st August).
Spread the word: put this message in your sig, tell all your friends.
See website <http://boycott-riaa.com/>.
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: library to implement NFS
Date: Sun, 30 Jul 2000 19:03:00 +0100
On Sat, 29 Jul 2000 17:50:30 GMT, Kaz Kylheku <[EMAIL PROTECTED]> wrote:
>On Sat, 29 Jul 2000 10:22:01 +0200, J.H.M. Dassen (Ray) <[EMAIL PROTECTED]> wrote:
>>phil hunt <[EMAIL PROTECTED]> wrote:
>>>I'm looking for software that will enable me to implement a filing system
>>>that communicates using the NFS protocol.
>>
>>"Pgfs" (Postgres filesystem) is an NFS interface to a PostgreSQL database;
>>unfortunately I don't have a pointer to it handy.
>
>CFS (cryptographic filesystem) is also software that provides an NFS
>interface, in this case a plaintext view to some encrypted files.
Another is NetKit-A-0.06 which contains nfs-server-2.0, an implementation
of an NFS server (surprise, surprise).
--
***** Phil Hunt *****
The RIAA want to ban Napster -- so boycott the music industry!
Don't buy any CDs during August (especially on Tuesday 1st August).
Spread the word: put this message in your sig, tell all your friends.
See website <http://boycott-riaa.com/>.
------------------------------
From: Yu Jaemin <[EMAIL PROTECTED]>
Subject: Re: undefined symbols in modules
Date: 30 Jul 2000 17:59:12 GMT
F. Heitkamp <[EMAIL PROTECTED]> wrote:
> I have several kernel projects involving modules.
> When I compile my modules using "gcc -c module.c -DMODULE \
> -D__KERNEL__ -o module.o" and then use insmod to
> insert the module, I get several undefined symbols.
> The symbols are various kernel api routines. Why do
> I get the undefined symbols, and how can I resolve
> them? BTW this is a PowerPC Linux system using the
> 2.2.10 kernel. insmod is version 2.1.121.
> Fred
> These are the errors that insmod gives.
> 53c770.o: unresolved symbol virt_to_phys
> 53c770.o: unresolved symbol in_be16
> 53c770.o: unresolved symbol out_8
> 53c770.o: unresolved symbol in_8
> 53c770.o: unresolved symbol init_timer
> 53c770.o: unresolved symbol __fswab32
> 53c770.o: unresolved symbol virt_to_bus
> 53c770.o: unresolved symbol out_be32
> 53c770.o: unresolved symbol __restore_flags
> 53c770.o: unresolved symbol out_be16
> 53c770.o: unresolved symbol udelay
> dsp56k.o: unresolved symbol __get_user_bad
> dsp56k.o: unresolved symbol __put_user_bad
> dsp56k.o: unresolved symbol udelay
> ser_hypercom4.o: unresolved symbol queue_task
> ser_hypercom4.o: unresolved symbol mark_bh
> ser_hypercom4.o: unresolved symbol __restore_flags
> ser_hypercom4.o: unresolved symbol unregister_serial
> ser_hypercom4.o: unresolved symbol register_serial
try to add -O option to gcc.
Jaemin
------------------------------
From: [EMAIL PROTECTED] (ECStahl)
Date: 30 Jul 2000 18:57:23 GMT
Subject: Re: Good Basic compiler for linux?
I missed the start of this thread.
I remember a number of years back receiving a mandate from the VP of our S/W
company to port an existing product to SCO Unix in a manner that would be QB3
compatible. "Say what" I said :-)
To meet the timeline I ended up using an old and discontinued MS 286 Xenix QB3
compatible compiler.
What does that have to do with this query you ask? Well, it was just an
anectdote.
But near that time (pre-LINUX Minix was the curio UNIX of choice at that time)
there was (is?) a company called MAI/BASIC4, and a competing Business BASIC
(BB) company called Basis International in Taos NM.
I know that Basis is still around (I still rcv the occasional flyer) - and it
would not surprise me if their BBx Business BASIC product was available for
LINUX. Their forte was allowing your BB code to port immediately to any system
for which there was a BBx product available - various UNIX's, DOS, VMS??
Others... I think they even considered OS/400 at one point in time. The ability
to *immediately* port was an attention grabber.
Happy Trails,
Eric Stahl
[EMAIL PROTECTED] (Marco van de Voort)
>>>> >
>>>> > I don`t think the person posting the message was ASKING for your
>opinion on
>>>> > BASIC or wished to see a list of your programming conquests.
>>>> >
>>>> > Visual Basic is used by a great number of people & if linux has a
>comparable
>>>> > application it would help it be adopted more in the real world.
>
>If you are interested in the visual aspect, you'll have to wait until Delphi
>comes to Linux in the fall. That is Pascal though. C++ builder will probably
>follow soon after.
>
>Since VB is made by Microsoft, I don't expect a Linux port any soon.
>
>>>There is a program called 'xbasic' which is available
>>>from http://www.maxreason.com/software/xbasic/linux.html
>>>
>>>I don't know if it is in any way compatible with MS VB but it
>>>certainly qualifies as a Linux Basic system.
>>
>>a) It doesn't support ActiveX controls, or OLE, or DCOM, or CORBA.
>
>Delphi will support Corba. The rest is afaik not supported by Linux (in the
>form it is exists on windows)
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: problem with open files
Date: 30 Jul 2000 17:28:44 -0400
In article <[EMAIL PROTECTED]>,
Shankar <[EMAIL PROTECTED]> wrote:
>
>
>hi
>
> I have a 70 GB SCSI HDD. I need to write and consequently delete
> 16 1 GB files four times each.
>
> Now, the code does not close the files before it deletes the files
> (it does this by a system("rm ...")).
So close them.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: John Reiser <[EMAIL PROTECTED]>
Subject: Re: exec*() and argv[0]
Date: Sun, 30 Jul 2000 09:27:01 -0700
> ...
> If a script makes a reference to a different version
> of an interpreter by means of a specific path, that interpreter should
> have, in a convenient and PORTABLE way, the actual path used to invoke
> it. The interpreter may need access to private libraries or locale
> data or anything else specific to its function.
Consider the same argument applied to binary format (non-#!) executables.
They too "may need access to private libraries or locale data ...",
and this is what the PT_INTERP part of ELF (such as: /lib/ld-linux.so.2),
the DT_NEEDED list of shared libraries (such as: libc.so.6), and
environment variables (such as: LD_LIBRARY_PATH and LD_PRELOAD) provide.
If you believe that #! script executables deserve something different,
then why don't you document an existing implementation (apparently
Solaris x.y), propose it to the appropriate standards body, and _work_
for its adoption? [Along the way, you might consider why the interpreter
aspect (both binary format and script format) of exec*() isn't
nestable to arbitrary depth.]
> ... The kernel should not cripple a useful facility ...
No such facility is required. You claim it is useful. I believe
that existing universally-available alternatives, such as environment
variables, are at least as useful and effective. They even have
properties, such as transparency and user control, which can be
beneficial in contrast to relying on an installation path.
> But you have utterly failed to justify why the interpreter path should
> be ignored by the interpreter (however it might manage to get it). ...
I did not attempt to justify anything, just document the actual state,
and explain some of the significant implications. A #! interpreter
which tries to derive anything from argv[0] is relying on non-portable,
non-standardized implementation details.
--
John Reiser, [EMAIL PROTECTED]
------------------------------
From: "Pankaj Ratan Lal" <[EMAIL PROTECTED]>
Subject: get_blk vs ext2_getblk
Date: Mon, 31 Jul 2000 05:36:17 +0530
Hi All,
I have been looking into ext2 code for some time. What is the difference
between the function calls get_blk and ext2_get_blk in Linux/. The ext2 code
makes both calls though had a feel that it should react through only one
interface.
Thanks
Pankaj Ratan Lal
------------------------------
From: Remo Inverardi <[EMAIL PROTECTED]>
Subject: Re: Can i get a MAC address?
Date: Mon, 31 Jul 2000 02:55:04 +0200
Michael,
> I can't think of that. Since the maufacturer takes responsibility
> for the correctness and uniqueness of the mac in the card.
Nada, there are cards which allow you to set MAC addresses by
software commands. Afaik, this is mostly used for fail safe
(redundant) systems where one interface needs to take responsibility
for another interface.
I've seen lots of NICs which allow the MAC address to be changed in
software. I think Compaq's Netflex cards are among them ...
Regards, Remo
______________________________________________________________________
[ http://public.toilet.ch/ ] "Ich dusche warm!" [ http://www.vbs.ch/ ]
______________________________________________________________________
------------------------------
From: Remo Inverardi <[EMAIL PROTECTED]>
Subject: GNU Compiler and Libraries
Date: Mon, 31 Jul 2000 03:01:05 +0200
I was wondering if any of you guys ever understood the GNU Compiler
and Library licences. Our company is selling financial applications
and we don't want to release our code to the public (which is not
the point here, I *do* know about the advantages of open source
software).
Are you required to hand out your source code if you use the GNU
compiler and libraries? Someone told me -- I don't believe it.
Thanks for your time, Remo
______________________________________________________________________
[ http://public.toilet.ch/ ] "Ich dusche warm!" [ http://www.vbs.ch/ ]
______________________________________________________________________
------------------------------
From: Remo Inverardi <[EMAIL PROTECTED]>
Subject: Re: pthreads
Date: Mon, 31 Jul 2000 03:06:28 +0200
> Either way, if the thread is joinable, some other thread must
> call pthread_join to collect it.
You can also free the resources by calling pthread_detach (which
is probably *not* Posix compliant). The thread then frees its own
resources at termination.
Regards, Remo
______________________________________________________________________
[ http://public.toilet.ch/ ] "Ich dusche warm!" [ http://www.vbs.ch/ ]
______________________________________________________________________
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: GNU Compiler and Libraries
Date: 30 Jul 2000 21:14:24 -0400
In article <[EMAIL PROTECTED]>,
Remo Inverardi <[EMAIL PROTECTED]> wrote:
>I was wondering if any of you guys ever understood the GNU Compiler
>and Library licences. Our company is selling financial applications
>and we don't want to release our code to the public (which is not
>the point here, I *do* know about the advantages of open source
>software).
>
>Are you required to hand out your source code if you use the GNU
>compiler and libraries? Someone told me -- I don't believe it.
Compiler - not (if you are using it to complie your code, rather that using its
source in your product, indeed). Libraries - yes, if they are under GPL,
not necessary if they are under LGPL (you are safe if you link dynamically
or provide object files that may be relinked).
And take it out to gnu.misc.discuss, will you?
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Remo Inverardi <[EMAIL PROTECTED]>
Subject: Multiple Threads and File Locking
Date: Mon, 31 Jul 2000 03:23:17 +0200
When using multiple pthreads, working with file locks set with fcntl()
behave odd in my opinion. Say you have two threads which both perform
the following code:
1: open file "/sample/somefile.db"
2: lock bytes 10 to 20; if this fails, goto line 5
3: do something which takes a while
4: unlock bytes
5: close file
6: goto line 1
Lets assume that thread-a is busy executing line 3. Thread-b starts,
tries to lock some bytes in line 2, locking fails and the thread-b
continues execution at line 5, where the file is closed.
After thread-b restarts at line 1, it *can* lock the bytes in line
2, because it closed the file in line 6. So even though thread-a
thinks the bytes are still locked, they are not.
I know this is not a bug, but a well defined behaviour. I just don't
understand *why* whis is solved in what I call a pretty strange way.
If this is about preventing dead-locks, this is probably the wrong
attempt at doing so.
Regards, Remo
______________________________________________________________________
[ http://public.toilet.ch/ ] "Ich dusche warm!" [ http://www.vbs.ch/ ]
______________________________________________________________________
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Multiple Threads and File Locking
Reply-To: [EMAIL PROTECTED]
Date: Mon, 31 Jul 2000 01:35:53 GMT
On Mon, 31 Jul 2000 03:23:17 +0200, Remo Inverardi <[EMAIL PROTECTED]> wrote:
>When using multiple pthreads, working with file locks set with fcntl()
>behave odd in my opinion.
That's right. Linux is does not comply with POSIX in this regard, because
it grants a lock to the calling thread rather than to the ``process''.
Say you have two threads which both perform
>the following code:
>
>1: open file "/sample/somefile.db"
>2: lock bytes 10 to 20; if this fails, goto line 5
>3: do something which takes a while
>4: unlock bytes
>5: close file
>6: goto line 1
>
>Lets assume that thread-a is busy executing line 3. Thread-b starts,
>tries to lock some bytes in line 2, locking fails and the thread-b
>continues execution at line 5, where the file is closed.
This is wrong; according to POSIX, both threads own the lock because
they belong to the same process, so the locking should not fail.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED] (Frank Sweetser)
Subject: Re: GNU Compiler and Libraries
Date: 31 Jul 2000 01:24:32 GMT
Remo Inverardi <[EMAIL PROTECTED]> wrote:
>I was wondering if any of you guys ever understood the GNU Compiler
>and Library licences. Our company is selling financial applications
>and we don't want to release our code to the public (which is not
>the point here, I *do* know about the advantages of open source
>software).
>
>Are you required to hand out your source code if you use the GNU
>compiler and libraries? Someone told me -- I don't believe it.
That shouldn't be the case - you're distributing the output of program
that happens to be under GPL, not using or linking with GPL code.
You can find the full text of the license at www.gnu.org
--
Frank Sweetser rasmusin at wpi.edu, fs at suave.net
Full-time WPI Network Tech, Part time Linux/Perl guy
It's not really a rule--it's more like a trend.
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: "Peter Huang" <[EMAIL PROTECTED]>
Subject: signal a user space process from interrupt routines
Date: Sun, 30 Jul 2000 18:50:27 -0700
Hi all
Can I directly signal a user space process from the interrupt bottom half
routine and if so, how do I do it. If not, can I use the wait queue to wake
up a route such as the "write" or "ioctl" routine that can signal the user
space process. The reason I'm signaling the user space code is because I'm
using mmap and the application program can directly access the share memory.
Peter
------------------------------
** 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
******************************
