Linux-Development-Sys Digest #271, Volume #8 Fri, 10 Nov 00 20:13:14 EST
Contents:
Re: What C++ compiler to use for dev if you don't want to give away source for your
program? ("Ian Bruntlett")
mmap() vs. lseek() on /dev/mem RESOLVED (Gary Parnes)
Re: How to catch stdout of an application ? (denis martinez)
nfssvc: Function not implemented ([EMAIL PROTECTED])
Re: Linux Software RAID problems (Walter van der Schee)
Re: Help! Linux router between two NT networks. (Jamie Walker)
Vectors found! ("Christoper McClan")
Socket accept signedness in G++ ("Christoper McClan")
Re: Socket accept signedness in G++ ("D. Stimits")
Re: building ELF executables on NT system (jwk)
Re: Socket accept signedness in G++ ("Christoper McClan")
Re: Socket accept signedness in G++ (Kaz Kylheku)
Re: Embedded Systems Developer Needed
Re: nfssvc: Function not implemented ("Karl Heyes")
Re: Socket accept signedness in G++ (Juergen Heinzl)
Re: Socket accept signedness in G++ ("Peter T. Breuer")
----------------------------------------------------------------------------
From: "Ian Bruntlett" <Ian [EMAIL PROTECTED]>
Subject: Re: What C++ compiler to use for dev if you don't want to give away source
for your program?
Date: Fri, 10 Nov 2000 16:28:35 -0000
David,
AFAIK, you can write proprietary software using GNU C or C++.
The GNU C and C++ libraries were covered by the GNU LGPL ( LIBRARY GENERAL
PUBLIC LICENSE ).
See http://www.gnu.org/manual/glibc-2.0.6/html_chapter/libc_32.html. But
they might be covered by the GPL these days, I don't know.
Take a look at http://www.gnu.org/philosophy/why-not-lgpl.html) as well.
HTH
Ian
"David Ball" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm looking to develop some small shareware programs for Linux, but I
> don't want to have to give out my source code. What C++ compiler can I
> use? It looks like gcc forces me to release everything under GNU GPL.
> Is that correct?
------------------------------
From: Gary Parnes <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: mmap() vs. lseek() on /dev/mem RESOLVED
Date: Fri, 10 Nov 2000 10:17:11 -0600
The Web is an amazing resource...
While looking for some detailed documentation on the memory mapping
system in Linux 2.2.x, a Google search turned up this little gem:
http://kernelnewbies.org/code/mmap/
It's a handy little driver that allows you to mmap kernel RAM to the
user space. I tested it, and aside from a bug that tripped me up for a
few hours, it works just fine. The bug is in the loop that is used by
2.2.x kernels to reserve the memory buffers. The loop reads:
for (i = MAP_NR(buffer); i <= MAP_NR(buffer + 4095); i++) {
mem_map_reserve(i) ;
}
It should read:
for (i = MAP_NR(buffer); i < MAP_NR(buffer + MMT_BUF_SIZE); i++) {
mem_map_reserve(i) ;
}
Because I'm paranoid about making the assumption that the blocks will be
linear, I modified the loop:
unsigned long p ;
for(p = (unsigned long) buffer; p < (unsigned long) buffer +
MMT_BUF_SIZE; p += PAGE_SIZE) {
mem_map_reserve(MAP_NR(p)) ;
}
The mmap method supplied in the sample code ignores stuff like offsets,
but sufficiently motivated people should be able to fix this... ;^)
--Gary Parnes
[EMAIL PROTECTED]
------------------------------
From: denis martinez <[EMAIL PROTECTED]>
Subject: Re: How to catch stdout of an application ?
Date: Fri, 10 Nov 2000 18:00:54 +0100
Erik Hensema a �crit :
[...]
>
> Another possibility may be the use of 'screen'. I've never tried this
> program, but from what I've heard, this may be what you're looking for.
Thank's for this link!!
'screen' is the soluce i waited for !!!
This work great. Now i can cath many screen applications in one cession.
Thank's again.
--
Denis MARTINEZ <[EMAIL PROTECTED]>
R&D Engineer at Sofrel Telecontrol
Phone +33(0)4 92 08 43 24 Fax +33(0)4 92 08 43 19
------------------------------
From: [EMAIL PROTECTED]
Subject: nfssvc: Function not implemented
Date: Fri, 10 Nov 2000 16:50:32 GMT
Redhat 6.1, kernel 2.2.17, nfs-utils-0.2.1
rpc.nfsd
nfssvc: Function not implemented
I tracked this down to the following function call in
/nfs-utils-0.2.1/support/nfs/nfsctl.c" line 20
int
nfsctl (int cmd, struct nfsctl_arg * argp, union nfsctl_res * resp)
{
return syscall (__NR_nfsctl, cmd, argp, resp);
}
So to me this looks like a kernel issue.
Any help?
I just want to NFS mount a device...
Thank you!
- Andy
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Walter van der Schee <[EMAIL PROTECTED]>
Subject: Re: Linux Software RAID problems
Date: Fri, 10 Nov 2000 18:19:41 +0100
Borries Demeler wrote:
> I'm having a devil of a time trying to get Software RAID to
> work, but no matter what I try, I can't get it to work. I am trying to
> run RAID-0 on 7 identical 1Gig SCSI drives, here is my scenario:
>
> 1. Recompiled kernel (2.2.17, raidtools 0.90), with the following
> options:
>
> CONFIG_BLK_DEV_MD=y
> CONFIG_MD_LINEAR=y
> CONFIG_MD_STRIPED=y
> CONFIG_MD_MIRRORING=y
> CONFIG_MD_RAID5=y
> CONFIG_MD_BOOT=y
>
> Also tried:
>
> CONFIG_BLK_DEV_MD=y
> CONFIG_MD_LINEAR=m
> CONFIG_MD_STRIPED=m
> CONFIG_MD_BOOT=m
>
> 2. deleted all partitions on each drive, and recreated a single
> partition
> of type "fd" spanning the entire disk on each drive.
>
> 3. Set up /etc/raidtab:
>
> raiddev /dev/md0
> raid-level 0
> nr-raid-disks 7
> persistent-superblock 1
> chunk-size 8 (also tried 4)
>
> device /dev/sdc1
> raid-disk 0
> device /dev/sdd1
> raid-disk 1
> device /dev/sde1
> raid-disk 2
> device /dev/sdf1
> raid-disk 3
> device /dev/sdg1
> raid-disk 4
> device /dev/sdh1
> raid-disk 5
> device /dev/sdi1
> raid-disk 6
>
>
> After loading the modules, I got:
>
> /proc/mdstat:
>
>
> Personalities : [2 raid0]
> read_ahead not set
> md0 : inactive
> md1 : inactive
> md2 : inactive
> md3 : inactive
>
> When running monolithically, I get:
>
> Personalities : [1 linear] [2 raid0] [3 raid1] [4 raid5]
> read_ahead not set
> md0 : inactive
> md1 : inactive
> md2 : inactive
> md3 : inactive
>
> When running mkraid /dev/md0, I get:
>
> mkraid /dev/md0
> handling MD device /dev/md0
> analyzing super-block
> disk 0: /dev/sdc1, 1027056kB, raid superblock at 1026944kB
> disk 1: /dev/sdd1, 1027056kB, raid superblock at 1026944kB
> disk 2: /dev/sde1, 1027056kB, raid superblock at 1026944kB
> disk 3: /dev/sdf1, 1027056kB, raid superblock at 1026944kB
> disk 4: /dev/sdg1, 1027056kB, raid superblock at 1026944kB
> disk 5: /dev/sdh1, 1027056kB, raid superblock at 1026944kB
> disk 6: /dev/sdi1, 1027056kB, raid superblock at 1026944kB
> mkraid: aborted, see the syslog and /proc/mdstat for potential clues.
>
> Well, no info is written to /var/log/syslog, and I don't know why it is
> aborting.
>
> I started debugging mkraid to see where the error comes from, and it
> boils down to a failed ioctl call, since I am not a system programmer,
> I really don't know where to go from there. Here is what I have come up
> with so far: I traced the problem to a failed ioctl call in line 46:
>
> ret = ioctl(file, SET_ARRAY_INFO, (unsigned long)&cfg->array.param);
>
> Here are the parameters:
>
> file: 4, SET_ARRAY_INFO: 1078462755, &cfg->array.param: 134547136 ioctl
> returned -1 in line 46: Invalid argument (printing out strerror(errno))
> called in makeOneRaid in line 225 (I think they are supposed to be long
> int's).
>
> Not knowing much about the ioctl call, I can't interpret the int values
> and tell what's wrong about them. Do you have any further clues? Maybe
> I am missing something really obvious - hopefully?
>
> Thanks for any suggestions you may be able to offer, -Borries
>
> P.S. If you could copy your answer to [EMAIL PROTECTED], I
> would really appreciate it
>
I had the same problem. Check your syslog. or use dmesg to check the
version of Software RAID in the kernel modules.
Kernel 2.2.17 comes wih Software RAID, but this is version 0.36, and
your raidtools package is version 0.90.
They are probably out of sync.
go to http://people.redhat.com/mingo/raid-patches/ to download the correct
patches for 2.2.17.
Walter
------------------------------
From: Jamie Walker <[EMAIL PROTECTED]>
Subject: Re: Help! Linux router between two NT networks.
Date: Fri, 10 Nov 2000 17:52:40 +0000
In article <VYRO5.16253$[EMAIL PROTECTED]>, UM
<[EMAIL PROTECTED]> writes
>However, I want the computers to be visible in Network Neighborhood ... ie.
>the NT domain in 2.* should be visible in the 1.* window.
>
>What will that take ?
As your link is only up part of the time, you could set up your router
to forward the NETBIOS broadcast packets as explained in /usr/doc/samba-
doc/NetBIOS.txt.gz:
"Clients can claim names, and therefore offer services on successfully
claimed names, on their broadcast-isolated subnet. One way to get
NetBIOS services (such as browsing: see ftp.microsoft.com/drg/developr/C
IFS/browdiff.txt; and SMB file/print sharing: see cifs4.txt) working on
a LAN or WAN is to make your routers forward all broadcast packets from
TCP/IP ports 137, 138 and 139.
This, however, is not recommended. If you have a large LAN or WAN, you
will find that some of your hosts spend 95 percent of their time dealing
with broadcast traffic. [If you have IPX/SPX on your LAN or WAN, you
will find that this is already happening: a packet analyzer will show,
roughly every twelve minutes, great swathes of broadcast traffic!]."
NB The machines probably won't be visible straight away across the
subnets without reboots, but I'm guessing that the 'every twelve
minutes' refers to the clients checking that their lists are up-to-date.
HTH,
--
Jamie Walker "While there are no known bugs in it, it might
[EMAIL PROTECTED] destroy your filesystems, eat your data and
http://www.sagaxis.co.uk/ start World War III. You have been warned."
------------------------------
From: "Christoper McClan" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: Vectors found!
Date: Fri, 10 Nov 2000 18:18:18 +0000
Thanks for the advice - I donwloaded the libc++??devel rpm, installed
it and vectors + iostream stuff were all there!
Cheers,
CIM
In article <8uf4gk$l6c$[EMAIL PROTECTED]>, "Christoper McClan"
<[EMAIL PROTECTED]> wrote:
>
> I'm running Mandrake 7.1, and am trying to use vector structures. I
> understand that this is possible as it is included in the STL (Standard
> Template Library). However, I don't seem to have "vector.h", I managed
> to get a copy of stl.zip from HP's web site but the include files in
> that wanted "iostream.h" which strangley I don't seem to have either...
>
> What am I missing or doing wrong?
>
> Thanks,
>
> CIM.
------------------------------
From: "Christoper McClan" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: Socket accept signedness in G++
Date: Fri, 10 Nov 2000 18:22:02 +0000
I'm doing some fairly standard socket programming, and one piece of
code contains the line :
client_sockfd = accept(server_sockfd,(struct sockaddr *)&client_address\
, &client_len);
The variables and such are defined as you would expect. It compiles
fine with gcc, but when compiling with g++, I get the following error :
server.c: In function `int main()':
server.c:40: passing `int *' as argument 3 of `accept(int, sockaddr *\
, socklen_t *)' changes signedness
(Obviously I have inserted the '\' character).
Any ideas?
Cheers,
CIM
------------------------------
Date: Fri, 10 Nov 2000 12:47:31 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Socket accept signedness in G++
Christoper McClan wrote:
>
> I'm doing some fairly standard socket programming, and one piece of
> code contains the line :
>
> client_sockfd = accept(server_sockfd,(struct sockaddr *)&client_address\
> , &client_len);
>
> The variables and such are defined as you would expect. It compiles
> fine with gcc, but when compiling with g++, I get the following error :
>
> server.c: In function `int main()':
> server.c:40: passing `int *' as argument 3 of `accept(int, sockaddr *\
> , socklen_t *)' changes signedness
>
> (Obviously I have inserted the '\' character).
>
> Any ideas?
>
> Cheers,
>
> CIM
C++ is pickier about warnings of such things. Such problems still exist
even if you are using C, they just aren't reported as often. Did you
declare "client_len" as socklen_t? If not, this might be the problem; if
so, what happens when you declare client_len instead as "unsigned int
client_len" instead of socklen_t? (Note that this latter form might
work, but would be non-portable and may not be the best choice if this
will be distributed on anything except x86 linux, but it is something to
test).
------------------------------
From: [EMAIL PROTECTED] (jwk)
Subject: Re: building ELF executables on NT system
Date: 10 Nov 2000 19:59:43 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 10 Nov 2000 16:41:24 +0200, Andrew Voznytsa
<[EMAIL PROTECTED]> wrote:
>Hi All!
>
>I want to build ELF executables on NT systems.
>Does someone know how I can do it ?
>
>I've installed port of gcc/binutils, but these things supports only pe-i386
>target.
>
>--
>
>rgds,
>
>Andrew
>
build a cross-compiler for an ELF target using cygwin32.
Jurriaan
--
BOFH excuse #386:
The Internet is being scanned for viruses.
GNU/Linux 2.2.18pre21 SMP 2x1117 bogomips load av: 1.70 1.21 0.96
------------------------------
From: "Christoper McClan" <[EMAIL PROTECTED]>
Subject: Re: Socket accept signedness in G++
Date: Fri, 10 Nov 2000 20:06:07 +0000
In article <[EMAIL PROTECTED]>, "D. Stimits"
<[EMAIL PROTECTED]> wrote:
> Christoper McClan wrote:
>>
>> I'm doing some fairly standard socket programming, and one piece of
>> code contains the line :
>>
>> client_sockfd = accept(server_sockfd,(struct sockaddr
>> *)&client_address\
>> , &client_len);
>>
>> The variables and such are defined as you would expect. It compiles
>> fine with gcc, but when compiling with g++, I get the following error :
>>
>> server.c: In function `int main()': server.c:40: passing `int *' as
>> argument 3 of `accept(int, sockaddr *\
>> , socklen_t *)' changes signedness
>>
>> (Obviously I have inserted the '\' character).
>>
>> Any ideas?
>>
>> Cheers,
>>
>> CIM
>
> C++ is pickier about warnings of such things. Such problems still exist
> even if you are using C, they just aren't reported as often. Did you
> declare "client_len" as socklen_t? If not, this might be the problem; if
> so, what happens when you declare client_len instead as "unsigned int
> client_len" instead of socklen_t? (Note that this latter form might
> work, but would be non-portable and may not be the best choice if this
> will be distributed on anything except x86 linux, but it is something to
> test).
Cheers for the advice! I've now declared client_len as type socklen_t - I am
suprised this is only a problem for the accept routine, i.e. why don't I need
to define client_lent as socklen_t, but I can leave this as an int.
Also defining it as an unsigned int also works (what does the 'unsigned' mean?)
I also tried casting client_len to type socklen_t but that didn't work - i.e :
(socklen_t *)&client_len
Thanks,
CIM
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development
Subject: Re: Socket accept signedness in G++
Reply-To: [EMAIL PROTECTED]
Date: Fri, 10 Nov 2000 20:28:20 GMT
On Fri, 10 Nov 2000 18:22:02 +0000, Christoper McClan <[EMAIL PROTECTED]>
wrote:
>
>I'm doing some fairly standard socket programming, and one piece of
>code contains the line :
>
>client_sockfd = accept(server_sockfd,(struct sockaddr *)&client_address\
>, &client_len);
>
>The variables and such are defined as you would expect. It compiles
>fine with gcc, but when compiling with g++, I get the following error :
If by ``compile fine'' you mean ``I get a few warnings related to ANSI C
constraint rule violations, but I will ignore them''. ;)
>server.c: In function `int main()':
>server.c:40: passing `int *' as argument 3 of `accept(int, sockaddr *\
>, socklen_t *)' changes signedness
>
>(Obviously I have inserted the '\' character).
>
>Any ideas?
Yes, you must pass a ``socklen_t *'' value as the third argument. The Single
UNIX specification has introduced this absurd ``socklen_t'' type which
represents the length of an address, and required that it must be some unsigned
type, thus breaking all legacy code which uses the type int.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Embedded Systems Developer Needed
Date: Fri, 10 Nov 2000 20:57:09 -0000
In article <cVGM5.293$If6.10707@insync>,
Jo Parmer <[EMAIL PROTECTED]> wrote:
>My name is Jo Parmer and I am with Pedley-Richard and Associates, a
>technical recruiting firm in Austin, TX. We are helping a client to find an
>Embedded Systems Developer for the Southern California area. If anyone
>might have an interest in a new opportunity in CA, please feel free to
>contact me directly. This company offers relo, great compensation, stocks,
>and a dynamic work environment. If you would like to see a job description,
>please go to our website at www.pedley-richard.com Thank you for any help
>and for your time.
Southern California is a big place. You really should be more specific.
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: nfssvc: Function not implemented
Date: Fri, 10 Nov 2000 22:42:07 +0000
In article <8uh90l$7f5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> Redhat 6.1, kernel 2.2.17, nfs-utils-0.2.1
>
>
> rpc.nfsd nfssvc: Function not implemented
>
probably due to fact that your kernel doesn't support kernel nfsd server.
> I tracked this down to the following function call in
> /nfs-utils-0.2.1/support/nfs/nfsctl.c" line 20
>
> int nfsctl (int cmd, struct nfsctl_arg * argp, union nfsctl_res * resp)
> {
> return syscall (__NR_nfsctl, cmd, argp, resp);
> }
>
> So to me this looks like a kernel issue.
>
> Any help?
>
> I just want to NFS mount a device...
>
If you want to mount a remote filesystem then you don't need an nfs server
running locally.
karl.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development
Subject: Re: Socket accept signedness in G++
Date: 11 Nov 2000 00:10:47 GMT
In article <[EMAIL PROTECTED]>, Kaz Kylheku wrote:
>On Fri, 10 Nov 2000 18:22:02 +0000, Christoper McClan <[EMAIL PROTECTED]>
>wrote:
>>
>>I'm doing some fairly standard socket programming, and one piece of
>>code contains the line :
>>
>>client_sockfd = accept(server_sockfd,(struct sockaddr *)&client_address\
>>, &client_len);
>>
>>The variables and such are defined as you would expect. It compiles
>>fine with gcc, but when compiling with g++, I get the following error :
>
>If by ``compile fine'' you mean ``I get a few warnings related to ANSI C
>constraint rule violations, but I will ignore them''. ;)
>
>>server.c: In function `int main()':
>>server.c:40: passing `int *' as argument 3 of `accept(int, sockaddr *\
>>, socklen_t *)' changes signedness
>>
>>(Obviously I have inserted the '\' character).
>>
>>Any ideas?
>
>Yes, you must pass a ``socklen_t *'' value as the third argument. The Single
>UNIX specification has introduced this absurd ``socklen_t'' type which
>represents the length of an address, and required that it must be some unsigned
>type, thus breaking all legacy code which uses the type int.
[-]
I've seen machines where socklen_t can be 4 *or* 8 byte, depending on
how you compile the code and for reasons.
socklen_t isn't that absurd even though people love to say so (gracefully
ignoring Linus' opinion regarding socklen_t here, yep).
Ta',
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: Re: Socket accept signedness in G++
Date: 11 Nov 2000 00:34:59 GMT
In comp.os.linux.development Juergen Heinzl <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Kaz Kylheku wrote:
: socklen_t isn't that absurd even though people love to say so (gracefully
: ignoring Linus' opinion regarding socklen_t here, yep).
AFAICS, it must be the same as size_t, and it isn't! How else
could one be expected to write
socklen_t len = sizeof(struct socket); // or whatever
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
******************************