Linux-Development-Sys Digest #272, Volume #8 Sat, 11 Nov 00 20:13:10 EST
Contents:
Re: What C++ compiler to use for dev if you don't want to give away source for your
program? ([EMAIL PROTECTED])
Re: Socket accept signedness in G++ (Juergen Heinzl)
Re: Socket accept signedness in G++ ("Peter T. Breuer")
Re: How to decompress debian package? Pls help (Victor Wagner)
Re: catching smurf attack... ("deadmeat")
Re: What C++ compiler to use for dev if you don't want to give away source for your
program? (John Hasler)
Re: loading interdependent modules (Peter Pointner)
Re: Erors making modules with RedHat7.0 and 2.2.16-22 ([EMAIL PROTECTED])
Re: Raw block device interface (Ronald Cole)
Re: What C++ compiler to use for dev if you don't want to give away (George
MacDonald)
Re: Socket accept signedness in G++ (Kaz Kylheku)
Kernel function reference ([EMAIL PROTECTED])
Re: loading interdependent modules ([EMAIL PROTECTED])
Re: Socket accept signedness in G++ (Juergen Heinzl)
Re: Socket accept signedness in G++ (Juergen Heinzl)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
Subject: Re: What C++ compiler to use for dev if you don't want to give away source
for your program?
Crossposted-To: gnu.misc.discuss
Date: Sat, 11 Nov 2000 01:55:00 GMT
"D. Stimits" <[EMAIL PROTECTED]> writes:
> David Ball wrote:
> >
> > 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?
>
> I could be way off base, so take this with the proverbial grain of salt.
>
> If you statically bind libraries that are GNU into your project,
> then you have to also follow the GNU licensing.
This leaves considerable ambiguity in the question of "what's GNU?"
Particularly since "the GNU licensing" is inaccurate as the GNU
project involves _several_ quite distinct licenses.
Safer to ask this via "what is _licensed under the GNU GPL_?"
And yes, if you link into code that is licensed under the GNU GPL,
then you are required to release your code under the same terms.
The only really conspicuous library for C++ using such terms is the
free version of the GUI toolkit Qt from Troll Tech.
In contrast, GLIBC and libstdc++ are _not_ licensed under the GPL, but
rather have a release such that you can link to them without having to
follow the GPL.
> Selling the compiler or requiring the compiler in your software
> would cause you to be bound to GNU licensing. Compiling your own
> source code, with purely dynamic linking of libraries that may be
> GNU, should enable you to sell your software without open sourcing
> it.
Selling the compiler _alongside_ your own software would likely
considered "mere aggregation," and would not bind your software with
the GPL.
Notable relevant quote from the GPL [Section 2].
"In addition, mere aggregation of another work not based on the
Program with the Program (or with a work based on the Program) on a
volume of a storage or distribution medium does not bring the other
work under the scope of this License."
The wording "GNU licensing" is _NOT_ good wording to use; it is
ambiguous since the GNU Project:
a) Is somewhat ambiguous in its nature, and
b) Is inclusive of a _bunch_ of licenses of which the
oft-controversial GPL is _but one_.
If you are trying to assert claims about the effects of a particular
license, _name the license_.
If it seems I'm being annoyingly "officious," that seems to me to be
Tough Luck. The thread of discussion involves the legalities of
software licensing, and miswording of licenses can have ill effects
despite "meaning well."
--
(concatenate 'string "cbbrowne" "@hex.net")
<http://www.ntlug.org/~cbbrowne/lsf.html>
Rules of the Evil Overlord #172. "I will allow guards to operate under
a flexible work schedule. That way if one is feeling sleepy, he can
call for a replacement, punch out, take a nap, and come back refreshed
and alert to finish out his shift. <http://www.eviloverlord.com/>
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development
Subject: Re: Socket accept signedness in G++
Date: 11 Nov 2000 02:38:40 GMT
In article <8ui47j$5c1$[EMAIL PROTECTED]>, Peter T. Breuer wrote:
>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
[-]
You mean sockaddr I presume and as it is a type one must not
care what size socklen_t is, which is the whole point of using
a typedef.
Sure though -- "Points to a socklen_t which on input specifies
the length of the supplied sockaddr structure, and on output specifies
the length of the stored address." -- and it must be large enough
so one can do that.
I don't know what you mean by "or whatever" either, as if you use
socklen_t for "whatever" it's basically your problem, but maybe I
got something really wrong. It got a bit late -- glibc update %-)
Cheers,
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 02:47:37 GMT
In comp.os.linux.development Juergen Heinzl <[EMAIL PROTECTED]> wrote:
: In article <8ui47j$5c1$[EMAIL PROTECTED]>, Peter T. Breuer wrote:
:>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
: You mean sockaddr I presume and as it is a type one must not
Probably. I didn't recall what I had to use it to measure last time I
used it.
: care what size socklen_t is, which is the whole point of using
I can't parse your sentence. Nobody cares what size socklen_t is. One
cares what VALUE it has. And one can't give it a value conveniently
because it has the wrong type to receive a value produced by sizeof.
At least that's what I recall as being the difficulty!
: a typedef.
: Sure though -- "Points to a socklen_t which on input specifies
: the length of the supplied sockaddr structure, and on output specifies
: the length of the stored address." -- and it must be large enough
: so one can do that.
: I don't know what you mean by "or whatever" either, as if you use
I meant that I didn't recall what the struct was that it is normally
applied to. I do very little network programming.
Peter
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.development.apps
Subject: Re: How to decompress debian package? Pls help
Date: 10 Nov 2000 22:37:40 +0300
In comp.os.linux.misc Alan Po <[EMAIL PROTECTED]> wrote:
: Dear sir
: I have got a ash file but is in debain package (deb extension). I don't
: know how to decompress under Red Hat. Would you give me help? Thanks a
: lot
ar p filename.deb data.tar.gz |tar xzf -
--
How many chunks could checkchunk check if checkchunk could check chunks?
-- Alan Cox
------------------------------
From: "deadmeat" <[EMAIL PROTECTED]>
Subject: Re: catching smurf attack...
Date: Sat, 11 Nov 2000 04:40:55 GMT
> Hi guys, I'm writing a module for my computer science thesis work.
> I've to catch the smurf attack using netfilter firewalling scheme
> ( so we are in 2.4.0 kernel series ).
> How is filled the broadcast field in the sock structure, and when?
do you mean you want to detect if you are:
- the source amplifier in a smurf attack, or
- the target in a smurf attack?
if the former, it should be a simply matter of adding a firewall rule (I
don't know netfilter yet), that logs any packets arriving on your internet
interface destined for your broadcast address. for IPChains, it would be
something like
ipchains -I input 1 -j REJECT -i ppp0 -d 1.2.3.255 -l
where ppp0 is your link to the internet, and 255 is your broadcast address
(mine is 192 since I have a subnet not a whole net, so make sure you know
what it is).
if you get a lot of packets logged for this, it could be indicative of an
attack. a small number may just be a portscan.
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: What C++ compiler to use for dev if you don't want to give away source
for your program?
Date: Sat, 11 Nov 2000 04:08:28 GMT
David Ball wrote:
> 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?
Gcc.
> It looks like gcc forces me to release everything under GNU GPL. Is that
> correct?
No. Gcc forces you to do nothing. You can use any license you please.
You are not required to release source.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: loading interdependent modules
Date: 10 Nov 2000 22:53:03 +0100
Sean Bose <[EMAIL PROTECTED]> wrote:
> Hi Friends
> I have two driver modules which uses exported symbols from
> each other. When I try to load using insmod, it fails, as when
> the first module is getting loaded it cannot find the symbols
> which are exported by the second module. Is there any way I can
> load these mutually dependent modules into the kernel.
If these modules are mutually dependent, why do you use two modules?
Can't you just linkt the two object modules together? (Hint: ld -r).
Peter
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.ox.linux.setup
Subject: Re: Erors making modules with RedHat7.0 and 2.2.16-22
Date: Sat, 11 Nov 2000 17:05:04 GMT
(Flame on: RH did a really crappy job of QA on the 7.0 release. If this
is an indication of things to come, I'm going make to Mandrake.
Shesh. :flame off)
In include/linux/modules/i386_ksym.ver, (did I get that spelling right?)
you need to qualify the definition of smp_num_cpus, i.e. make it look
like:
#ifndef smp_num_cpus
#define smp_num_cpus <what ever they had there>
#endif
That'll take care of the compile errors correctly.
Now, if I can only fix the module build errors...
I love doing RH's job for them....
In article <[EMAIL PROTECTED]>,
root <[EMAIL PROTECTED]> wrote:
> I had to redefine smp_num_cpus, for no reason I could quickly
determine,
> in '/linux/kernel_stat.h' whilst compiling the kernel. The reported
> error was an undefined symbol, probably some conditional compilation I
> couldn't be arsed to look for.
>
> Secondly, and currently, make modules throws an error
> (`get_module_symbol_R_ver_str' declared as function returning a
> function) whilst compiling loop.c in /block/drivers. I don't know why,
> does anyone else?
>
> Otherwise system performing beautifully. One last gripe: why aren't
the
> AGP config options included in xconfig?
>
> Arch
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Ronald Cole <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer,comp.os.linux.networking
Subject: Re: Raw block device interface
Date: 11 Nov 2000 09:37:14 -0800
Manoj Patil <[EMAIL PROTECTED]> writes:
> Is raw interface available in linux for block devices ?
I think you mean: "Is a character device available for hard drives"?
> I have a partition and need to access it through a raw interface.
> Basically the aim of my program is to bypass the buffer cache and be
> assured that every read/write operation results into disk activity.
I fancied a post where it seemed that someone was able to do it with
RedHat 7.0. I didn't see it in the docs and I haven't had time to
look into it yet, but Stephen Tweedie's raw disk I/O may be there.
--
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: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: gnu.misc.discuss
Subject: Re: What C++ compiler to use for dev if you don't want to give away
Date: Sat, 11 Nov 2000 18:57:33 GMT
John Hasler wrote:
>
> David Ball wrote:
> > 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?
>
> Gcc.
>
> > It looks like gcc forces me to release everything under GNU GPL. Is that
> > correct?
>
> No. Gcc forces you to do nothing. You can use any license you please.
> You are not required to release source.
However, if you can contribute to the open source community, please do!!
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development
Subject: Re: Socket accept signedness in G++
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Nov 2000 19:10:04 GMT
On 11 Nov 2000 00:10:47 GMT, Juergen Heinzl <[EMAIL PROTECTED]>
wrote:
>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.
Or, more likely, the type int can be 4 or 8 bytes, with socklent_t probably
having to be defined so that its size stays the same for the ABI? Is
that what you are thinking of?
>socklen_t isn't that absurd even though people love to say so (gracefully
>ignoring Linus' opinion regarding socklen_t here, yep).
It's absurd because
- the standard requires it to be unsigned, whereas all traditional UNIX
code uses the type int. Without that requirement, implementors could just
typedef int socklen_t, should they wish to do so.
- you don't need a big honking typedef to represent the length of something
that is unlikely to ever reach a two digit figure in the forseeable future.
- As a source level construct, it does nothing for binary compatibility. E.g.
32 bit *binary* applications, perhaps compiled even before socklen_t
existed, running over a 64 bit library and kernel.
- It's just a hack for brain-damaged code that assumes sizeof(int) == 4,
and must be translated with a special compiler mode which makes the
compiler incompatible with any library interface that uses naked int,
or at least pointers thereto.
A better solution to that is to provide a whole set of 32 bit legacy
libraries, perhaps derived from earlier versions of the OS,
and not bother maintaining them. When compiling in the brain-damaged mode,
those obsolescent libraries are used. Eventually they are removed
and everyone has to learn to program without dependencies on sizeof (int).
You need those libraries anyway for legacy binaries, because those binaries
have encoded assumptions, through no fault of the programmer, on the sizes of
things, like sizeof(int) being 4. If an old binary app calls accept(),
it will pass a pointer to a 4 byte object. If a new app calls accept(),
the pointer may be to an 8 byte object. So clearly two versions of
accept() are needed. Given that, surely the compiler front end can figure
out which one to use for a given setting without the help of a hack like
socklen_t!
------------------------------
From: [EMAIL PROTECTED]
Subject: Kernel function reference
Date: Sat, 11 Nov 2000 21:49:39 +0100
Is there some sort of online kernel function reference? I did a RedHat
7.0 total install but still when I type:
Man kfree
Man kmalloc
Man printk
Man register_chrdev
Man memcpy_fromfs
End so one�.
No success I bought the book Linux device drivers and the functions I
named above are in there but looking for a total reverence list.
Greetings Bas
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: loading interdependent modules
Date: Sat, 11 Nov 2000 21:28:22 GMT
One solution is not to refer directly the function, using a pointer on
it. For example :
module A implements : int fct(struct sk_buff *) ;
in module B :
declare : int (*pf_fct)(struct sk_buff *) ;
Init : pf_fct = (int (*) (struct sk_buff *))get_module_symbol
(moduleA_name, "fct");
if pf_fct is null, the symbol is unknown.
call the function : pf_fct(skb) ;
Sylvie
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi Friends
> I have two driver modules which uses exported symbols from
> each other. When I try to load using insmod, it fails, as when
> the first module is getting loaded it cannot find the symbols
> which are exported by the second module. Is there any way I can
> load these mutually dependent modules into the kernel.
>
> thanks
> Sean
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development
Subject: Re: Socket accept signedness in G++
Date: 12 Nov 2000 00:33:08 GMT
In article <[EMAIL PROTECTED]>, Kaz Kylheku wrote:
>On 11 Nov 2000 00:10:47 GMT, Juergen Heinzl <[EMAIL PROTECTED]>
>wrote:
>>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.
>
>Or, more likely, the type int can be 4 or 8 bytes, with socklent_t probably
>having to be defined so that its size stays the same for the ABI? Is
>that what you are thinking of?
[-]
I'm thinking of not caring what size socklen_t is compared to the size
of an int and no, it does not need to have the same size.
Using int and thinking it'd be okay is an assumptions -- computers are
stupid though, they don't like assumptions.
>>socklen_t isn't that absurd even though people love to say so (gracefully
>>ignoring Linus' opinion regarding socklen_t here, yep).
>
>It's absurd because
>
>- the standard requires it to be unsigned, whereas all traditional UNIX
> code uses the type int. Without that requirement, implementors could just
> typedef int socklen_t, should they wish to do so.
[-]
Never mind, so we ought to use K&R C because ANSI or C99 breaks traditional
code ?
>- you don't need a big honking typedef to represent the length of something
> that is unlikely to ever reach a two digit figure in the forseeable future.
[-]
I don't care what size socklen_t is of in an actual implementation, really.
>- As a source level construct, it does nothing for binary compatibility. E.g.
> 32 bit *binary* applications, perhaps compiled even before socklen_t
> existed, running over a 64 bit library and kernel.
[-]
A 32 bit binary may be compiled to use a 64 bit socklen_t -- there goes
your "int is fine" in new code.
>- It's just a hack for brain-damaged code that assumes sizeof(int) == 4,
> and must be translated with a special compiler mode which makes the
> compiler incompatible with any library interface that uses naked int,
> or at least pointers thereto.
[-]
There's a lot of traditional code that assumes sizeof(int) to be 4 I dare
say but I do agree, it's brain damaged code but okay, it's the way it is
and tons of new code are being written along that line every day.
> A better solution to that is to provide a whole set of 32 bit legacy
> libraries, perhaps derived from earlier versions of the OS,
> and not bother maintaining them. When compiling in the brain-damaged mode,
> those obsolescent libraries are used. Eventually they are removed
> and everyone has to learn to program without dependencies on sizeof (int).
[-]
You don't need such libraries on systems that support versioning like
Solaris or Linux nowadays, so problem solved as far as old binaries are
concerned. At least for some time into the future, that is.
[-]
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development
Subject: Re: Socket accept signedness in G++
Date: 12 Nov 2000 00:33:14 GMT
In article <8uic09$8cu$[EMAIL PROTECTED]>, Peter T. Breuer wrote:
>In comp.os.linux.development Juergen Heinzl <[EMAIL PROTECTED]> wrote:
>: In article <8ui47j$5c1$[EMAIL PROTECTED]>, Peter T. Breuer wrote:
>:>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
>: You mean sockaddr I presume and as it is a type one must not
>
>Probably. I didn't recall what I had to use it to measure last time I
>used it.
[-]
Yup.
>: care what size socklen_t is, which is the whole point of using
>
>I can't parse your sentence. Nobody cares what size socklen_t is. One
>cares what VALUE it has. And one can't give it a value conveniently
>because it has the wrong type to receive a value produced by sizeof.
>At least that's what I recall as being the difficulty!
[-]
Sorry, but if one cannot give it a value then socklen_t would not
be usable at all. I've written code using socklen_t not only on
Linux and can assure you giving it a value using sizeof() always
compiled and worked like a charm.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
** 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
******************************
