I started looking at why the Gz module won't load on W*ndows with dynamic modules, while most others (such as Regexp) do. DLDEBUG had the following to say:
First the Regexp module (which works):
dlopen(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/lib/modules/___Regexp.so,0) filesize(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/lib/modules/___Regexp.so) filesize(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/lib/modules/___Regexp.so) Opening file: z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/lib/modules/___Regexp.so Reading ... tmp=0 len=17764 x=17764 errno=2 Done reading dl_load_file dl_loadcoff dl_load_coff_files(01325BE0,00EDBDBC,1) DL: counting DL: 16dcb28 20 0 40 DL: section[0,0], 1536 bytes, align=16 (0x60500020) DL: section[0,1], 518 bytes, align=4 (0xc0300040) DL: section[0,2], 6080 bytes, align=16 (0x60500020) DL: section[0,3], 804 bytes, align=4 (0xc0300040) DL: section[0,4], 36 bytes, align=4 (0xc0300080) DLINFO(113): -defaultlib:uuid.lib -defaultlib:LIBCMT -defaultlib:OLDNAMES -export:_pike_module_exit -export:_pike_module_init Parse link info ptr=0 Parse link info ptr=0 len=20 '-default' Parse link info ptr=21 Parse link info ptr=21 len=18 '-default' Parse link info ptr=40 Parse link info ptr=40 len=20 '-default' Parse link info ptr=61 Parse link info ptr=61 len=25 '-export:' Parse link info ptr=87 Parse link info ptr=87 len=25 '-export:' Parse link info done. DL: allocating 1360 bytes DL: Got 1360 bytes RWX memory at 00380000 alloc_htable(29) DL: moving code DL: section[0]=00390000 { 260, 1536 } DL: section[1]=00380000 { 2956, 518 } DL: section[2]=00390600 { 3484, 6080 } DL: section[3]=00380208 { 13254, 804 } DL: section[4]=0038052C { 0, 36 } DL: data->symbol_addresses=00391DC0 DL: exporting symbols (169) DL: exporting _pike_module_exit -> 00390000 [...]
Ok, looks fine. Now Gz:
dlopen(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/test-install/pike/7.3.56/lib/modules/Gz.so,0) filesize(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/test-install/pike/7.3.56/lib/modules/Gz.so) filesize(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/test-install/pike/7.3.56/lib/modules/Gz.so) Opening file: z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/test-install/pike/7.3.56/lib/modules/Gz.so Reading ... tmp=0 len=144 x=144 errno=0 Done reading dl_load_file dl_loadcoff dl_load_coff_files(042945F0,00EDACBC,1) DL: counting DL: 42944d0 20 0 40 DLINFO(84): /DEFAULTLIB:"uuid.lib" -defaultlib:uuid.lib -defaultlib:LIBCMT -defaultlib:OLDNAMES Parse link info ptr=0 Parse link info ptr=0 len=22 '/DEFAULT' Parse link info ptr=23 Parse link info ptr=23 len=0 ' -defaul' Parse link info ptr=24 Parse link info ptr=24 len=20 '-default' Parse link info ptr=45 Parse link info ptr=45 len=18 '-default' Parse link info ptr=64 Parse link info ptr=64 len=20 '-default' Parse link info done. DL: allocating 0 bytes DL: Got 0 bytes RWX memory at 00000000 alloc_htable(1) DL: moving code DL: exporting symbols (0) DL: resolving [...]
Now, there are two things wrong with this picture. First, there is no "-export:_pike_module_exit -export:_pike_module_init" in the DLINFO. Second, and even more alarming: Not a single symbol is found in the file.
Ok, now running strings on the Gz.so to see if the symbols are actually missing or of it's only dlopen.c which fails to read them:
[marcus@danae modules]$ strings -a Gz/module.so |less .drectve /DEFAULTLIB:"uuid.lib" -defaultlib:uuid.lib -defaultlib:LIBCMT -defaultlib:OLDNAMES [marcus@danae modules]$
Hm. That's it?? Suspicion starts to dawn.
[marcus@danae modules]$ ls -l Gz/module.so -rw-rw-r-- 1 peter peter 144 Sep 24 16:33 Gz/module.so [marcus@danae modules]$
Right. I think it's safe to say that not only are the symbols missing, the actual code is too.
Runnings strings on Gz/zlibmod.o shows that the symbols are there at least, so it's the linking that has failed.
The buildlog only says
Making Gz make[5]: Entering directory `/mnt/aphraelraid/home/peter/hack/xenofarm/client/pike/vmwarexp.bortas.org/buildtmp/Pike7.3-20020924-135500/build/microsoft-windows-xp-5.1.2600-x86/modules/Gz' Compiling /mnt/aphraelraid/home/peter/hack/xenofarm/client/pike/vmwarexp.bortas.org/buildtmp/Pike7.3-20020924-135500/src/modules/Gz/zlibmod.c Linking Gz Pike Win32 partial linker. $Id: pntld,v 1.14 2002/09/12 17:11:40 peter Exp $ Written by Fredrik Hubinette 2000 - 2001 Creating module.so make[5]: Leaving directory `/mnt/aphraelraid/home/peter/hack/xenofarm/client/pike/vmwarexp.bortas.org/buildtmp/Pike7.3-20020924-135500/build/microsoft-windows-xp-5.1.2600-x86/modules/Gz'
so no clues there. The only difference I can see in the Makefiles for Regexp and Gz is that Gz has
MODULE_LDFLAGS= -R/lib -L/lib -R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib -lshell32 -lkernel32 -lws2_32 -ladvapi32 -lm
while Regexp just has
MODULE_LDFLAGS= -R/lib -L/lib -R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib
but I don't think that's the problem, since Gmp has virtually the same MODULE_LDFLAGS as Gz (including all the -lshell32 etc) and that module works.
What's going on here? Hubbe?
My best guess is that the magic include that is required to make pike_module_{init,exit} exported wasn't included. Without that magic pntld may promptly gc all the symbols and code from the generated file.
However, I don't even remember if that is the way pntld works or not..
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2002-09-24 23:33: Subject: COFF...
I started looking at why the Gz module won't load on W*ndows with dynamic modules, while most others (such as Regexp) do. DLDEBUG had the following to say:
First the Regexp module (which works):
dlopen(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/lib/modules/___Regexp.so,0) filesize(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/lib/modules/___Regexp.so) filesize(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/lib/modules/___Regexp.so) Opening file: z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/lib/modules/___Regexp.so Reading ... tmp=0 len=17764 x=17764 errno=2 Done reading dl_load_file dl_loadcoff dl_load_coff_files(01325BE0,00EDBDBC,1) DL: counting DL: 16dcb28 20 0 40 DL: section[0,0], 1536 bytes, align=16 (0x60500020) DL: section[0,1], 518 bytes, align=4 (0xc0300040) DL: section[0,2], 6080 bytes, align=16 (0x60500020) DL: section[0,3], 804 bytes, align=4 (0xc0300040) DL: section[0,4], 36 bytes, align=4 (0xc0300080) DLINFO(113): -defaultlib:uuid.lib -defaultlib:LIBCMT -defaultlib:OLDNAMES -export:_pike_module_exit -export:_pike_module_init Parse link info ptr=0 Parse link info ptr=0 len=20 '-default' Parse link info ptr=21 Parse link info ptr=21 len=18 '-default' Parse link info ptr=40 Parse link info ptr=40 len=20 '-default' Parse link info ptr=61 Parse link info ptr=61 len=25 '-export:' Parse link info ptr=87 Parse link info ptr=87 len=25 '-export:' Parse link info done. DL: allocating 1360 bytes DL: Got 1360 bytes RWX memory at 00380000 alloc_htable(29) DL: moving code DL: section[0]=00390000 { 260, 1536 } DL: section[1]=00380000 { 2956, 518 } DL: section[2]=00390600 { 3484, 6080 } DL: section[3]=00380208 { 13254, 804 } DL: section[4]=0038052C { 0, 36 } DL: data->symbol_addresses=00391DC0 DL: exporting symbols (169) DL: exporting _pike_module_exit -> 00390000 [...]
Ok, looks fine. Now Gz:
dlopen(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/test-install/pike/7.3.56/lib/modules/Gz.so,0) filesize(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/test-install/pike/7.3.56/lib/modules/Gz.so) filesize(z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/test-install/pike/7.3.56/lib/modules/Gz.so) Opening file: z:/home/peter/hack/Pike/7.3/build/microsoft-windows-xp-5.1.2600-x86/test-install/pike/7.3.56/lib/modules/Gz.so Reading ... tmp=0 len=144 x=144 errno=0 Done reading dl_load_file dl_loadcoff dl_load_coff_files(042945F0,00EDACBC,1) DL: counting DL: 42944d0 20 0 40 DLINFO(84): /DEFAULTLIB:"uuid.lib" -defaultlib:uuid.lib -defaultlib:LIBCMT -defaultlib:OLDNAMES Parse link info ptr=0 Parse link info ptr=0 len=22 '/DEFAULT' Parse link info ptr=23 Parse link info ptr=23 len=0 ' -defaul' Parse link info ptr=24 Parse link info ptr=24 len=20 '-default' Parse link info ptr=45 Parse link info ptr=45 len=18 '-default' Parse link info ptr=64 Parse link info ptr=64 len=20 '-default' Parse link info done. DL: allocating 0 bytes DL: Got 0 bytes RWX memory at 00000000 alloc_htable(1) DL: moving code DL: exporting symbols (0) DL: resolving [...]
Now, there are two things wrong with this picture. First, there is no "-export:_pike_module_exit -export:_pike_module_init" in the DLINFO. Second, and even more alarming: Not a single symbol is found in the file.
Ok, now running strings on the Gz.so to see if the symbols are actually missing or of it's only dlopen.c which fails to read them:
[marcus@danae modules]$ strings -a Gz/module.so |less .drectve /DEFAULTLIB:"uuid.lib" -defaultlib:uuid.lib -defaultlib:LIBCMT -defaultlib:OLDNAMES [marcus@danae modules]$
Hm. That's it?? Suspicion starts to dawn.
[marcus@danae modules]$ ls -l Gz/module.so -rw-rw-r-- 1 peter peter 144 Sep 24 16:33 Gz/module.so [marcus@danae modules]$
Right. I think it's safe to say that not only are the symbols missing, the actual code is too.
Runnings strings on Gz/zlibmod.o shows that the symbols are there at least, so it's the linking that has failed.
The buildlog only says
Making Gz make[5]: Entering directory `/mnt/aphraelraid/home/peter/hack/xenofarm/client/pike/vmwarexp.bortas.org/buildtmp/Pike7.3-20020924-135500/build/microsoft-windows-xp-5.1.2600-x86/modules/Gz' Compiling /mnt/aphraelraid/home/peter/hack/xenofarm/client/pike/vmwarexp.bortas.org/buildtmp/Pike7.3-20020924-135500/src/modules/Gz/zlibmod.c Linking Gz Pike Win32 partial linker. $Id: pntld,v 1.14 2002/09/12 17:11:40 peter Exp $ Written by Fredrik Hubinette 2000 - 2001 Creating module.so make[5]: Leaving directory `/mnt/aphraelraid/home/peter/hack/xenofarm/client/pike/vmwarexp.bortas.org/buildtmp/Pike7.3-20020924-135500/build/microsoft-windows-xp-5.1.2600-x86/modules/Gz'
so no clues there. The only difference I can see in the Makefiles for Regexp and Gz is that Gz has
MODULE_LDFLAGS= -R/lib -L/lib -R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib -lshell32 -lkernel32 -lws2_32 -ladvapi32 -lm
while Regexp just has
MODULE_LDFLAGS= -R/lib -L/lib -R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib
but I don't think that's the problem, since Gmp has virtually the same MODULE_LDFLAGS as Gz (including all the -lshell32 etc) and that module works.
What's going on here? Hubbe?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Hm, module_magic.h is included, but only if HAVE_ZLIB_H is defined. I think this is the way most modules are written; they only include module_magic.h if they include all their other files (since module_magic.h has to be last), and they only include their own files if they exist. So if they don't, module_magic.h gets left out.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-25 01:47: Subject: COFF...
My best guess is that the magic include that is required to make pike_module_{init,exit} exported wasn't included. Without that magic pntld may promptly gc all the symbols and code from the generated file.
However, I don't even remember if that is the way pntld works or not..
/ Fredrik (Naranek) Hubinette (Real Build Master)
A small script later and I found out that there were quite a few modules which were broken in this way, as well as some that didn't contain an include of module_magic.h at all. They should all be fixed in CVS now.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-25 13:04: Subject: COFF...
Hm, module_magic.h is included, but only if HAVE_ZLIB_H is defined. I think this is the way most modules are written; they only include module_magic.h if they include all their other files (since module_magic.h has to be last), and they only include their own files if they exist. So if they don't, module_magic.h gets left out.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Perhaps it doesn't matter, but are they all dynamically loaded (e.g. file, system and sprintf)?
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-09-25 16:17: Subject: COFF...
A small script later and I found out that there were quite a few modules which were broken in this way, as well as some that didn't contain an include of module_magic.h at all. They should all be fixed in CVS now.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
No, but they should include it anyway
A) for symmetry reasons B) so that they can be compiled as dynamic modules if you want to
Also consider that new modules are often made by using an old module as a template, and a static module could be used as a template for a dynamic module. Having the module_magic in place makes this less error-prone.
Including module_magic in a static module doesn't hurt, since there's an #ifdef DYNAMIC_MODULE in it.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-25 16:21: Subject: COFF...
Perhaps it doesn't matter, but are they all dynamically loaded (e.g. file, system and sprintf)?
/ Martin Nilsson (Fake Build Master)
It looks likes things are getting a bit complicated. You should include module_magic after all pike includes, before the code and outside of any ifdefs. This will cause problems over and over again, just like the must-add-empty-testsuite.in-rule.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-09-25 16:27: Subject: COFF...
No, but they should include it anyway
A) for symmetry reasons B) so that they can be compiled as dynamic modules if you want to
Also consider that new modules are often made by using an old module as a template, and a static module could be used as a template for a dynamic module. Having the module_magic in place makes this less error-prone.
Including module_magic in a static module doesn't hurt, since there's an #ifdef DYNAMIC_MODULE in it.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Yes, see 9083479.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-09-25 16:31: Subject: COFF...
It looks likes things are getting a bit complicated. You should include module_magic after all pike includes, before the code and outside of any ifdefs. This will cause problems over and over again, just like the must-add-empty-testsuite.in-rule.
/ Martin Nilsson (Fake Build Master)
Well, if that is what it takes to get things to work, it's just a docs issue. That's just another one of the things Finnman would have to address with his thesis CMOD docs for us, right? :-)
And for those of you that have not yet heard about Andreas Finnman, he is just about to start on a Master's thesis, entitled "Analysis and Documentation of the Pike C Module APIs", which, besides writing some docs for CMOD (and possibly or probably also the old C module API), will result in a glue for bzip2, similar to the Gz module.
/ Johan Sundström (nu även i Gottfridsberg!)
Previous text:
2002-09-25 16:31: Subject: COFF...
It looks likes things are getting a bit complicated. You should include module_magic after all pike includes, before the code and outside of any ifdefs. This will cause problems over and over again, just like the must-add-empty-testsuite.in-rule.
/ Martin Nilsson (Fake Build Master)
Goodie. :)
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-25 16:51: Subject: Pike C Module documentation
Well, if that is what it takes to get things to work, it's just a docs issue. That's just another one of the things Finnman would have to address with his thesis CMOD docs for us, right? :-)
And for those of you that have not yet heard about Andreas Finnman, he is just about to start on a Master's thesis, entitled "Analysis and Documentation of the Pike C Module APIs", which, besides writing some docs for CMOD (and possibly or probably also the old C module API), will result in a glue for bzip2, similar to the Gz module.
/ Johan Sundström (nu även i Gottfridsberg!)
Le Wed, 25 Sep 2002, Johan Sundström (nu även i Gottfridsberg!) @ Pike (-)...:
Well, if that is what it takes to get things to work, it's just a docs issue. That's just another one of the things Finnman would have to address with his thesis CMOD docs for us, right? :-)
And for those of you that have not yet heard about Andreas Finnman, he is just about to start on a Master's thesis, entitled "Analysis and Documentation of the Pike C Module APIs", which, besides writing some docs for CMOD (and possibly or probably also the old C module API), will result in a glue for bzip2, similar to the Gz module.
Yeah docs about pike glue should help programmer to add news glues...
BTW a bzip2 glues exist in Caudium's Pexts projects, feel free to add it ?
(A small question what it the politic to add new C/CMOD modules into pike tree ?)
/Xavier
BTW a bzip2 glues exist in Caudium's Pexts projects, feel free to add it ?
That'd be great. Talk to e.g. jhs@pike.ida.liu.se about the practical details about getting cvs access.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-29 17:02: Subject: Re: Pike C Module documentation
Le Wed, 25 Sep 2002, Johan Sundström (nu även i Gottfridsberg!) @ Pike (-)...:
Well, if that is what it takes to get things to work, it's just a docs issue. That's just another one of the things Finnman would have to address with his thesis CMOD docs for us, right? :-)
And for those of you that have not yet heard about Andreas Finnman, he is just about to start on a Master's thesis, entitled "Analysis and Documentation of the Pike C Module APIs", which, besides writing some docs for CMOD (and possibly or probably also the old C module API), will result in a glue for bzip2, similar to the Gz module.
Yeah docs about pike glue should help programmer to add news glues...
BTW a bzip2 glues exist in Caudium's Pexts projects, feel free to add it ?
(A small question what it the politic to add new C/CMOD modules into pike tree ?)
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. For mail address, please check header of this mails. Spams are not accepted. Caudium: http://caudium.net/, CAMAS webmail: http://camas.caudium.net/ Making friends with FreeBSD: Just because the system has panicked doesn`t mean that you should panic too.
/ Brevbäraren
Yeah docs about pike glue should help programmer to add news glues...
Our intention exactly. :-)
BTW a bzip2 glues exist in Caudium's Pexts projects, feel free to add it ?
That sounds like a time-saver (then he can probably quickly move on to the next stage - implementing the same module via the cmod API). I take it you have no objections on donating the module to Pike, and releasing it under LGPL and MPL, then?
(A small question what it the politic to add new C/CMOD modules into pike tree ?)
Not much politics involved, besides the licensing, and having someone of us in the core development team, IDA or not, bless your code. :-)
Candidates for reviewing code are currently grubba, marcus, mast and per, but since neither have formally been appointed for the job, they should not be treated as if they were obligued to comply, or anything; if it turns out this does not work well, we'll have some homework to do about inventing something that does. (All of these people have jobs to do, you know, besides hacking about in Pike, so don't be pushy. :-)
http://pike.ida.liu.se/development/cvs/policies.xml
applies as usual, of course -- if or when people feel we need more formalized rules, please tell us, or me (I'm not alone about this; we work as a team over here with bigger decisions).
/ Johan Sundström (ska bli kalif i stället för kalifen)
Previous text:
2002-09-29 17:02: Subject: Re: Pike C Module documentation
Le Wed, 25 Sep 2002, Johan Sundström (nu även i Gottfridsberg!) @ Pike (-)...:
Well, if that is what it takes to get things to work, it's just a docs issue. That's just another one of the things Finnman would have to address with his thesis CMOD docs for us, right? :-)
And for those of you that have not yet heard about Andreas Finnman, he is just about to start on a Master's thesis, entitled "Analysis and Documentation of the Pike C Module APIs", which, besides writing some docs for CMOD (and possibly or probably also the old C module API), will result in a glue for bzip2, similar to the Gz module.
Yeah docs about pike glue should help programmer to add news glues...
BTW a bzip2 glues exist in Caudium's Pexts projects, feel free to add it ?
(A small question what it the politic to add new C/CMOD modules into pike tree ?)
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. For mail address, please check header of this mails. Spams are not accepted. Caudium: http://caudium.net/, CAMAS webmail: http://camas.caudium.net/ Making friends with FreeBSD: Just because the system has panicked doesn`t mean that you should panic too.
/ Brevbäraren
Yeah docs about pike glue should help programmer to add news glues...
Our intention exactly. :-)
This great then :)
BTW a bzip2 glues exist in Caudium's Pexts projects, feel free to add it ?
That sounds like a time-saver (then he can probably quickly move on to the next stage - implementing the same module via the cmod API). I take it you have no objections on donating the module to Pike, and releasing it under LGPL and MPL, then?
All modules in pexts are GPL. I see no objections to add them to mainstream pike :)
(A small question what it the politic to add new C/CMOD modules into pike tree ?)
Not much politics involved, besides the licensing, and having someone of us in the core development team, IDA or not, bless your code. :-)
Candidates for reviewing code are currently grubba, marcus, mast and per, but since neither have formally been appointed for the job, they should not be treated as if they were obligued to comply, or anything; if it turns out this does not work well, we'll have some homework to do about inventing something that does. (All of these people have jobs to do, you know, besides hacking about in Pike, so don't be pushy. :-)
http://pike.ida.liu.se/development/cvs/policies.xml
applies as usual, of course -- if or when people feel we need more formalized rules, please tell us, or me (I'm not alone about this; we work as a team over here with bigger decisions).
Here is the list of our C modules for Pike.
PExts Module List =================
AdminTools:
This module implements various low-level system calls, like quotas, shadow files, directory access and more. Requires: OS Support for various systemcalls. Detected by configure. Principal Author: Marek Habersack grendel@caudium.net
Mhash:
A glue to the Mhash library hashing library. It provides fast implementations of a large number of hashing algorithms. Requires: Mhash library from http://mhash.sourceforge.net/ Principal Author: David Hedbor david@caudium.net TODO: Hashed password support.
mcrypt:
A glue to the mcrypt library, which provides a large number of encryption routines using a plugin based architecture. Requires: libmcrypt from http://mcrypt.hellug.gr/#_libmcrypt Principal Author: David Hedbor david@caudium.net
Newt:
A module adding Newt support for Pike. Requires: The newt library Principal Author: Zsolt Varga redax@caudium.net
_Newt:
Experimental module for Newt support. It's a different approach to the subject, thus a separate module. Requires: The newt library Principal Author: Marek Habersack grendel@caudium.net TODO: finish the Newt.pmod implement the Grid functions rewrite the Newt C examples in Pike
PCRE:
A glue to the Perl Compatible Regular Expression library, PCRE. Implements fast, extensive regexps. Requires: The PCRE library from http://www.pcre.org/ Principal Author: David Hedbor david@caudium.net TODO: Complex functionality like regexp replacing.
PDF:
A glue to PDFlib. Allows for dynamic generation of PDF files from within Pike. See src/PDF/README for special instructions on compilation. This module is pretty much redundant since Pike 7.2+ includes PDF handling modules already. Expect this one to disappear soon. Requires: PDFlib from http://www.pdflib.com/ Principal Author: Zsolt Varga redax@caudium.net
_BerkeleyDB:
Low-level glue to the Berkeley DB library. In a very early stage. Requires: Berkeley DB 3.x libraries from http://www.sleepycat.com/ Principal Author: David Hedbor david@hedbor.org TODO: Transactions, DBENV support, cursors, locks, higher level Pike interface.
bzip2:
Glue to the bzip2 library, enabling compression and decompression of bzip2 data. Requires: libbz2 from http://sources.redhat.com/bzip2/ Principal Author: Marek Habersack grendel@caudium.net TODO: File based (de)compression, possibly non-blocking operation?
AVS:
Glue to the Altavista SDK. Requires: AVS SDK from http://solutions.altavista.com/ Principal Author: Aleph One aleph1@caudium.net Other Authors: David Hedbor david@hedbor.org
mnoGo: Glue to the mnoGoSearch search engine. Requires: mnoGoSearch from http://www.mnogosearch.ru/ Principal Author: David Hedbor david@hedbor.org Notes: Similar interface Sql.sql. WIP TODO: Documentation.
OpenLDAP: Glue to the OpenLDAP v2 library. Requires: OpenLDAP v2 from http://www.openldap.org/ Principal Author: Marek Habersack grendel@caudium.net TODO: See the TODO file in the source directory
OpenSSL: Glue to OpenSSL library. Requires: OpenSSL 0.9.x from http://www.openssl.org/ Principal Author: Paul Wankadia junyer@gmx.net Notes: Interface similar to plain OpenSSL libs TODO: Documentation as usual :)
Gzip: Module to read gzip(1)ped files directly from within Pike using zlib. Requires: zlib from http://www.zlib.org/ Principal Author: Marek Habersack grendel@caudium.net Notes: This module is intentionally made separate from the Pike.Gz one. TODO: implement streamed decompression implement compression in all modes
_esmtp: Module that implements the interface to the libesmtp library that provides client side of the SMTP protocol. Requires: http://www.stafford.uklinux.net/libesmtp/ Principal Author: Marek Habersack grendel@caudium.net Notes: WIP
_FDF: Pike glue to the Adobe FDF SDK. Requires: http://partners.adobe.com/asn/developer/acrosdk/forms.html Principal Author: Marek Habersack grendel@caudium.net Notes: WIP, Proprietary lib required
/Xavier
I take it you have no objections on donating the module to Pike, and releasing it under LGPL and MPL, then?
All modules in pexts are GPL. I see no objections to add them to mainstream pike :)
And all of Pike is released under GPL, LGPL *and* MPL, which also means that unless donated code is bound by GPL and the owner does not hold the copyrights for the code, we can not accept it into Pike, the way I understand it (since the GPL does not mandate anyone to release the same code under a different license besides the GPL, unless this person also holds the full rights to do as he wants with the code).
(As far as I could see, the bzip2 glue was written by grendel and/or david, and if both agree about donating it to Pike we have no problem there, of course.)
/ Johan Sundström (ska bli kalif i stället för kalifen)
Previous text:
2002-10-01 13:35: Subject: Re: Pike C Module documentation
Yeah docs about pike glue should help programmer to add news glues...
Our intention exactly. :-)
This great then :)
BTW a bzip2 glues exist in Caudium's Pexts projects, feel free to add it ?
That sounds like a time-saver (then he can probably quickly move on to the next stage - implementing the same module via the cmod API). I take it you have no objections on donating the module to Pike, and releasing it under LGPL and MPL, then?
All modules in pexts are GPL. I see no objections to add them to mainstream pike :)
(A small question what it the politic to add new C/CMOD modules into pike tree ?)
Not much politics involved, besides the licensing, and having someone of us in the core development team, IDA or not, bless your code. :-)
Candidates for reviewing code are currently grubba, marcus, mast and per, but since neither have formally been appointed for the job, they should not be treated as if they were obligued to comply, or anything; if it turns out this does not work well, we'll have some homework to do about inventing something that does. (All of these people have jobs to do, you know, besides hacking about in Pike, so don't be pushy. :-)
http://pike.ida.liu.se/development/cvs/policies.xml
applies as usual, of course -- if or when people feel we need more formalized rules, please tell us, or me (I'm not alone about this; we work as a team over here with bigger decisions).
Here is the list of our C modules for Pike.
PExts Module List
AdminTools:
This module implements various low-level system calls, like quotas, shadow files, directory access and more. Requires: OS Support for various systemcalls. Detected by configure. Principal Author: Marek Habersack grendel@caudium.net
Mhash:
A glue to the Mhash library hashing library. It provides fast implementations of a large number of hashing algorithms. Requires: Mhash library from http://mhash.sourceforge.net/ Principal Author: David Hedbor david@caudium.net TODO: Hashed password support.
mcrypt:
A glue to the mcrypt library, which provides a large number of encryption routines using a plugin based architecture. Requires: libmcrypt from http://mcrypt.hellug.gr/#_libmcrypt Principal Author: David Hedbor david@caudium.net
Newt:
A module adding Newt support for Pike. Requires: The newt library Principal Author: Zsolt Varga redax@caudium.net
_Newt:
Experimental module for Newt support. It's a different approach to the subject, thus a separate module. Requires: The newt library Principal Author: Marek Habersack grendel@caudium.net TODO: finish the Newt.pmod implement the Grid functions rewrite the Newt C examples in Pike
PCRE:
A glue to the Perl Compatible Regular Expression library, PCRE. Implements fast, extensive regexps. Requires: The PCRE library from http://www.pcre.org/ Principal Author: David Hedbor david@caudium.net TODO: Complex functionality like regexp replacing.
PDF:
A glue to PDFlib. Allows for dynamic generation of PDF files from within Pike. See src/PDF/README for special instructions on compilation. This module is pretty much redundant since Pike 7.2+ includes PDF handling modules already. Expect this one to disappear soon. Requires: PDFlib from http://www.pdflib.com/ Principal Author: Zsolt Varga redax@caudium.net
_BerkeleyDB:
Low-level glue to the Berkeley DB library. In a very early stage. Requires: Berkeley DB 3.x libraries from http://www.sleepycat.com/ Principal Author: David Hedbor david@hedbor.org TODO: Transactions, DBENV support, cursors, locks, higher level Pike interface.
bzip2:
Glue to the bzip2 library, enabling compression and decompression of bzip2 data. Requires: libbz2 from http://sources.redhat.com/bzip2/ Principal Author: Marek Habersack grendel@caudium.net TODO: File based (de)compression, possibly non-blocking operation?
AVS:
Glue to the Altavista SDK. Requires: AVS SDK from http://solutions.altavista.com/ Principal Author: Aleph One aleph1@caudium.net Other Authors: David Hedbor david@hedbor.org
mnoGo: Glue to the mnoGoSearch search engine. Requires: mnoGoSearch from http://www.mnogosearch.ru/ Principal Author: David Hedbor david@hedbor.org Notes: Similar interface Sql.sql. WIP TODO: Documentation.
OpenLDAP: Glue to the OpenLDAP v2 library. Requires: OpenLDAP v2 from http://www.openldap.org/ Principal Author: Marek Habersack grendel@caudium.net TODO: See the TODO file in the source directory
OpenSSL: Glue to OpenSSL library. Requires: OpenSSL 0.9.x from http://www.openssl.org/ Principal Author: Paul Wankadia junyer@gmx.net Notes: Interface similar to plain OpenSSL libs TODO: Documentation as usual :)
Gzip: Module to read gzip(1)ped files directly from within Pike using zlib. Requires: zlib from http://www.zlib.org/ Principal Author: Marek Habersack grendel@caudium.net Notes: This module is intentionally made separate from the Pike.Gz one. TODO: implement streamed decompression implement compression in all modes
_esmtp: Module that implements the interface to the libesmtp library that provides client side of the SMTP protocol. Requires: http://www.stafford.uklinux.net/libesmtp/ Principal Author: Marek Habersack grendel@caudium.net Notes: WIP
_FDF: Pike glue to the Adobe FDF SDK. Requires: http://partners.adobe.com/asn/developer/acrosdk/forms.html Principal Author: Marek Habersack grendel@caudium.net Notes: WIP, Proprietary lib required
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. For mail address, please check header of this mails. Spams are not accepted. Caudium: http://caudium.net/, CAMAS webmail: http://camas.caudium.net/ Making friends with FreeBSD: Just because the system has panicked doesn`t mean that you should panic too.
/ Brevbäraren
I take it you have no objections on donating the module to Pike, and releasing it under LGPL and MPL, then?
All modules in pexts are GPL. I see no objections to add them to mainstream pike :)
And all of Pike is released under GPL, LGPL *and* MPL, which also means that unless donated code is bound by GPL and the owner does not hold the copyrights for the code, we can not accept it into Pike, the way I understand it (since the GPL does not mandate anyone to release the same code under a different license besides the GPL, unless this person also holds the full rights to do as he wants with the code).
(As far as I could see, the bzip2 glue was written by grendel and/or david, and if both agree about donating it to Pike we have no problem there, of course.)
I see no problem in adding LGPL/MPL rights to pexts modules and putting them in Pike. I would object against it if it was purely GPL however :-)
GPL/LGPL/MPL is a bit odd (why have GPL at all, it's just a more restrictive LGPL but otherwise the same...?) but fine with me.
/ David Hedbor (I live in interesting times)
Previous text:
2002-10-01 17:53: Subject: Re: Pike C Module documentation
I take it you have no objections on donating the module to Pike, and releasing it under LGPL and MPL, then?
All modules in pexts are GPL. I see no objections to add them to mainstream pike :)
And all of Pike is released under GPL, LGPL *and* MPL, which also means that unless donated code is bound by GPL and the owner does not hold the copyrights for the code, we can not accept it into Pike, the way I understand it (since the GPL does not mandate anyone to release the same code under a different license besides the GPL, unless this person also holds the full rights to do as he wants with the code).
(As far as I could see, the bzip2 glue was written by grendel and/or david, and if both agree about donating it to Pike we have no problem there, of course.)
/ Johan Sundström (ska bli kalif i stället för kalifen)
GPL/LGPL/MPL is a bit odd (why have GPL at all, it's just a more restrictive LGPL but otherwise the same...?) but fine with me.
If nothing else, it saves time debating with people who don't know the difference (or who _think_ they know the difference). If someone asks if they can get it under GPL, we can simply say "yes" and get on with things.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-10-01 20:09: Subject: Re: Pike C Module documentation
I take it you have no objections on donating the module to Pike, and releasing it under LGPL and MPL, then?
All modules in pexts are GPL. I see no objections to add them to mainstream pike :)
And all of Pike is released under GPL, LGPL *and* MPL, which also means that unless donated code is bound by GPL and the owner does not hold the copyrights for the code, we can not accept it into Pike, the way I understand it (since the GPL does not mandate anyone to release the same code under a different license besides the GPL, unless this person also holds the full rights to do as he wants with the code).
(As far as I could see, the bzip2 glue was written by grendel and/or david, and if both agree about donating it to Pike we have no problem there, of course.)
I see no problem in adding LGPL/MPL rights to pexts modules and putting them in Pike. I would object against it if it was purely GPL however :-)
GPL/LGPL/MPL is a bit odd (why have GPL at all, it's just a more restrictive LGPL but otherwise the same...?) but fine with me.
/ David Hedbor (I live in interesting times)
True. That's always a feature.
/ David Hedbor (I live in interesting times)
Previous text:
2002-10-01 21:37: Subject: Re: Pike C Module documentation
GPL/LGPL/MPL is a bit odd (why have GPL at all, it's just a more restrictive LGPL but otherwise the same...?) but fine with me.
If nothing else, it saves time debating with people who don't know the difference (or who _think_ they know the difference). If someone asks if they can get it under GPL, we can simply say "yes" and get on with things.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
And that is essentially the only reason, since LGPL implies GPL compatibility.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-10-01 21:37: Subject: Re: Pike C Module documentation
GPL/LGPL/MPL is a bit odd (why have GPL at all, it's just a more restrictive LGPL but otherwise the same...?) but fine with me.
If nothing else, it saves time debating with people who don't know the difference (or who _think_ they know the difference). If someone asks if they can get it under GPL, we can simply say "yes" and get on with things.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
It was written by me and I have no objections to relicense it under LGPL/MPL in addition to GPL. Hereby I state that I agree to it without any objections :)
/ Marek Habersack (Grendel)
Previous text:
2002-10-01 17:53: Subject: Re: Pike C Module documentation
I take it you have no objections on donating the module to Pike, and releasing it under LGPL and MPL, then?
All modules in pexts are GPL. I see no objections to add them to mainstream pike :)
And all of Pike is released under GPL, LGPL *and* MPL, which also means that unless donated code is bound by GPL and the owner does not hold the copyrights for the code, we can not accept it into Pike, the way I understand it (since the GPL does not mandate anyone to release the same code under a different license besides the GPL, unless this person also holds the full rights to do as he wants with the code).
(As far as I could see, the bzip2 glue was written by grendel and/or david, and if both agree about donating it to Pike we have no problem there, of course.)
/ Johan Sundström (ska bli kalif i stället för kalifen)
That is not the limit of it, and it has to be made very clear to avoid nasty surprices: You should agree to the write access rules of http://pike.ida.liu.se/development/cvs/policies.xml, which goes much further than you relicensing the code.
You give away the copyright of a copy of your code.
/ Peter Bortas
Previous text:
2002-10-02 21:02: Subject: Re: Pike C Module documentation
It was written by me and I have no objections to relicense it under LGPL/MPL in addition to GPL. Hereby I state that I agree to it without any objections :)
/ Marek Habersack (Grendel)
(Well, he already has, regarding the write access. I just wanted to make sure everybody understood that this applied just as much to already written modules up for joining the tree.)
Regarding the long list of other modules that might or might not become part of the core Pike distribution, we would probably have to finally sit down and think out something good about the namespace issues; for one thing, the modules listed already pointed out the problem with duplicates clearly enough.
With the release of 7.4 on the doorstep, it will hardly happen before the branch point, if I'm not mistaken.
/ Johan Sundström (ska bli kalif i stället för kalifen)
Previous text:
2002-10-02 22:18: Subject: Re: Pike C Module documentation
That is not the limit of it, and it has to be made very clear to avoid nasty surprices: You should agree to the write access rules of http://pike.ida.liu.se/development/cvs/policies.xml, which goes much further than you relicensing the code.
You give away the copyright of a copy of your code.
/ Peter Bortas
(A small question what it the politic to add new C/CMOD modules into pike tree ?)
Not much politics involved, besides the licensing, and having someone of us in the core development team, IDA or not, bless your code. :-)
Candidates for reviewing code are currently grubba, marcus, mast and per, but since neither have formally been appointed for the job, [...]
And while this was not intended as an exausive list in the first place, it would get pretty close if I listed Hubbe, Mirar and Niels Möller too.
/ Johan Sundström (ska bli kalif i stället för kalifen)
Previous text:
2002-10-01 12:57: Subject: Re: Pike C Module documentation
Yeah docs about pike glue should help programmer to add news glues...
Our intention exactly. :-)
BTW a bzip2 glues exist in Caudium's Pexts projects, feel free to add it ?
That sounds like a time-saver (then he can probably quickly move on to the next stage - implementing the same module via the cmod API). I take it you have no objections on donating the module to Pike, and releasing it under LGPL and MPL, then?
(A small question what it the politic to add new C/CMOD modules into pike tree ?)
Not much politics involved, besides the licensing, and having someone of us in the core development team, IDA or not, bless your code. :-)
Candidates for reviewing code are currently grubba, marcus, mast and per, but since neither have formally been appointed for the job, they should not be treated as if they were obligued to comply, or anything; if it turns out this does not work well, we'll have some homework to do about inventing something that does. (All of these people have jobs to do, you know, besides hacking about in Pike, so don't be pushy. :-)
http://pike.ida.liu.se/development/cvs/policies.xml
applies as usual, of course -- if or when people feel we need more formalized rules, please tell us, or me (I'm not alone about this; we work as a team over here with bigger decisions).
/ Johan Sundström (ska bli kalif i stället för kalifen)
pike-devel@lists.lysator.liu.se
-
David Hedbor (I live in interesting times) ＠ Pike (-) developers forum -
Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum
-
Johan Sundstr�m (nu �ven i Gottfridsberg!) ＠ Pike (-) developers forum
-
Johan Sundstr�m (ska bli kalif i st�llet f�r kalifen) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Marek Habersack (Grendel) ＠ Pike (-) developers forum
-
Martin Nilsson (Fake Build Master) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum
-
Xavier Beaudouin