My plan for simplifying things while catering to various wishes is to
- remove pike7.8-full
- let pike7.8 Recommend all other packages. That way everything will be installed if you run apt-get install pike7.8 unless you have switched off automatic installation of recommended packages, but it's still possible to opt out of individual packages.
I have made a small set of patches which I'd like to be included in pike and debian packages in order to make the package emdebian (cross) compilable. I've attached the patches, but as described below there are still some caveats to them.
Patches according to http://wiki.debian.org/EmdebianMakefile Patches are made against the current debian package (pike 7.8.352).
1) Patch to debian/rules. This patch can be included as is. The patch makes it possible to use a cross compiler for compiling pike. (cross compiling in debian you can do using "pkg-build -a arm -uc -us)
2) Patch to src/configure.in This patch can be included as is into pike, I think this was is a bug in configure.in because it originally tries to use the newly build pike instead of the pike installed on the host.
3) Patch to src/configure I think this patch should ultimately be done in src/configure.in. But I'm no M4 expert and haven't yet found which changes need to be made in src/configure.in
4) Patch to src/modules/Mysql/configure I think this patch was already included in src/modules/Mysql/configure.in.
Then there is the issue of bytecompiling. As I understand it pike can do without byte-compiling. However the debian packaging copies the byte-compiled files into the several packages. If byte-compiling fails (because the newly build pike can't be used for byte-compiling) the package manager fails to create a package.
I've only come up with one possible sollution to this. Which is, push the byte-compiling of the code into a post-install script. This way the byte-compiling can be done on the target machine. But maybe there is a better sollution? It is not allowed to have diff between the debian and the emdebian packaging files.
Best regards,
Marc
I just yesterday added simple bytecompilation management to the maintainer scripts (with the help of triggers), except for master.pike. There is no way to turn it off at build time short of patching the makefiles, but it has so far always failed completely when I run the build (except for master.pike, which is handled specially, but a master.pike.o created with pike -x dump should work equally well, shouldn't it?). I could, however, simply exclude any .o files from the packages.
.o files should be generated on the machine it runs on.
[...]
I've only come up with one possible sollution to this. Which is, push the byte-compiling of the code into a post-install script. This way the byte-compiling can be done on the target machine. But maybe there is a better sollution?
This is the standard solution used by our own binary distributions.
What do the debian packages of e.g. Emacs do? Byte-compile at compile or install time?
One caveat about byte-compiled modules in the context of separating them into separate packages: If a package A optionally depends on a package B, it will be at the time when A is byte-compiled that it is determined if B is available. So, if the byte-compilation takes place at compile time, when all modules are available (which are supported on the platform, of course), the byte-compiled A module will not be usable without B. On the other hand, if the module is byte-compiled on install, it becomes necessary to install B before A, otherwise A will not be able to use B even though it is installed.
On Sun, Jun 06, 2010 at 10:35:08AM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
if the byte-compilation takes place at compile time, when all modules are available (which are supported on the platform, of course), the byte-compiled A module will not be usable without B. On the other hand, if the module is byte-compiled on install, it becomes necessary to install B before A, otherwise A will not be able to use B even though it is installed.
hmm, then the most suitable action would be to force a recompilation of A when be in installed. not sure how to trigger that unless either all pike modules are recompiled everytime another pike module is installed, or more elaborate triggers are placed somewhere.
greetings, martin.
The modern way of doing it in Debian is with triggers, meaning that dpkg is instructed to run the postinst of script of some central package (e.g. pike7.8-core) whenever one or more files are installed in or removed from a particular directory (e.g. /usr/lib/pike7.8/modules) or subdirectory thereof. Then all modules can be byte-compiled after they are all in place, but as Martin Bähr noted, it looks like we'll have to always recompile everything for now.
Well, as long as it only recompiles everything once even if you install several modules (for example due to installing the meta-package), I guess it's not so bad.
I'm trying to wrap up the module dumping now, but I get a number of "Failed to find name of unencodable object" errors. Could someone explain what this error means?
Examples: #### /usr/lib/pike7.8/modules/Locale.pmod/module.pmod: Failed to find name of unencodable object master(). /usr/lib/pike7.8/master.pike:5170: master()->Encoder()->nameof(master(),({0})) /usr/lib/pike7.8/master.pike:5201: master()->Encoder()->nameof(master().joinnode,UNDEFINED) /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:220: /main()->dumpit("/usr/lib/pike7.8/modules/Locale.pmod/module.pmod","/usr/lib/pike7.8/modules/Locale.pmod/module.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules/Locale.pmod","/usr/lib/pike7.8/modules/Locale.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules/","/usr/lib/pike7.8/modules/") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:341: /main()->dump_files() -:1: Pike.Backend(0)->`()(3600.0)
#### /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike: Failed to find name of unencodable object /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump(). /usr/lib/pike7.8/master.pike:5170: master()->Encoder()->nameof(/${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump(),UNDEFINED) /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:220: /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike","/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod","/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod","/usr/lib/pike7.8/modules/Tools.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump()->dumpit("/usr/lib/pike7.8/modules/","/usr/lib/pike7.8/modules/") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:341: /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump()->dump_files() -:1: Pike.Backend(0)->`()(3600.0)
#### /usr/lib/pike7.8/modules/Calendar.pmod/Stardate.pmod: Failed to find name of unencodable object /${PIKE_MODULE_PATH}/Calendar.pmod/Ruleset(). /usr/lib/pike7.8/master.pike:5170: master()->Encoder()->nameof(/${PIKE_MODULE_PATH}/Calendar.pmod/Ruleset(),UNDEFINED) /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:220: /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump()->dumpit("/usr/lib/pike7.8/modules/Calendar.pmod/Stardate.pmod","/usr/lib/pike7.8/modules/Calendar.pmod/Stardate.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump()->dumpit("/usr/lib/pike7.8/modules/Calendar.pmod","/usr/lib/pike7.8/modules/Calendar.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump()->dumpit("/usr/lib/pike7.8/modules/","/usr/lib/pike7.8/modules/") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:341: /${PIKE_MODULE_PATH}/Tools.pmod/Standalone.pmod/dump()->dump_files() -:1: Pike.Backend(0)->`()(3600.0)
Also, when run with -DENCODE_DEBUG -DRESOLV_DEBUG, there are many cases of
resolv("/${PIKE_MODULE_PATH}/Foo.Bar", 0) => not found compare_resolved: object_program(/${PIKE_MODULE_PATH}/Foo.Bar) is different from 0 Warning: Failed to resolve; encoding path
where Foo.Bar varies. Is that normal? I would have guessed that resolv takes the name of something, not a path.
"Failed to find name of unencodable object" means that an object (in this case the master) is either not found in master()->objects, or its program not found in master()->programs (see objects_reverse_lookup() and programs_reverse_lookup()).
The master object and program should both be registered though (they are actually in the initializers for these variables). Does it work better if you turn off PIKE_MODULE_RELOC?
Simply by editing master.pike (that's the sole effect --with-relocatable-dumped-modules has AFAICT)?
Not quite the same result, but still some errors:
#### /usr/lib/pike7.8/modules/Locale.pmod/module.pmod: Failed to find name of unencodable object master(). /usr/lib/pike7.8/master.pike:5170: master()->Encoder()->nameof(master(),({0})) /usr/lib/pike7.8/master.pike:5201: master()->Encoder()->nameof(master().joinnode,UNDEFINED) /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:220: /main()->dumpit("/usr/lib/pike7.8/modules/Locale.pmod/module.pmod","/usr/lib/pike7.8/modules/Locale.pmod/module.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules/Locale.pmod","/usr/lib/pike7.8/modules/Locale.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules/","/usr/lib/pike7.8/modules/") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:341: /main()->dump_files() -:1: Pike.Backend(0)->`()(3600.0)
#### /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike: Failed to find name of unencodable object /main(). /usr/lib/pike7.8/master.pike:5170: master()->Encoder()->nameof(/main(),UNDEFINED) /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:220: /main()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike","/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod","/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod","/usr/lib/pike7.8/modules/Tools.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules/","/usr/lib/pike7.8/modules/") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:341: /main()->dump_files() -:1: Pike.Backend(0)->`()(3600.0)
#### /usr/lib/pike7.8/modules/Local.pmod: Failed to find name of unencodable object master(). /usr/lib/pike7.8/master.pike:5170: master()->Encoder()->nameof(master(),({0})) /usr/lib/pike7.8/master.pike:5201: master()->Encoder()->nameof(master().joinnode,UNDEFINED) /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:220: /main()->dumpit("/usr/lib/pike7.8/modules/Local.pmod","/usr/lib/pike7.8/modules/Local.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules/","/usr/lib/pike7.8/modules/") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:341: /main()->dump_files() -:1: Pike.Backend(0)->`()(3600.0)
(Naturally I've deleted all .o files first.)
The debug output leading up to that last one is
resolv("__builtin.automap_marker", "/usr/lib/pike7.8/modules/Local.pmod") => found _static_modules.Builtin()->automap_marker nameof (program Local.pmod) got the thing to encode - encoding recursively nameof (function aggregate) returned "caggregate" nameof (function reverse) returned "creverse" nameof (function __automap__) returned "c__automap__" nameof (program master().joinnode) got parent: master.pike found object for parent program in objects: master() nameof (master master()) found program in objects: master.pike got program of object: master.pike
Unless you already have some dumped modules, just changing the define in master.pike should be enough, yes.
Ok, then the problem is not caused by bitrot in MODULE_RELOC, which would have been a rather plausible scenario since I didn't think anyone was using it... :-)
My guess is that you have several master objects around. Known to happen when one uses replace_master, but I think I've seen it in other cases too. There ought to be only one of course, but with replace_master it's not easy to get rid of all references to the old one (it's practically impossible), so the best one can do is to try to make them reference the same data and hope noone notices the difference. :\
For starters I think it's best to find out if that's the case. I usually add something like this to _sprintf when I need to tell objects apart:
protected idnumber = ++all_constants()->asdfdsaf; string _sprintf (int flag) { return flag == 'O' && sprintf ("MyClass()[%d]", idnumber); }
The one in dump.pike looks like something else, though. The ENCODE_DEBUG output prior to it might give a clue.
My guess is that you have several master objects around.
For starters I think it's best to find out if that's the case.
Apparently:
#### /usr/lib/pike7.8/modules/Locale.pmod/module.pmod: Failed to find name of unencodable object master()[1]. /usr/lib/pike7.8/master.pike:5170: master()[2]->Encoder()->nameof(master()[1],({0})) /usr/lib/pike7.8/master.pike:5201: master()[2]->Encoder()->nameof(master()[1].joinnode,UNDEFINED) /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:220: /main()->dumpit("/usr/lib/pike7.8/modules/Locale.pmod/module.pmod","/usr/lib/pike7.8/modules/Locale.pmod/module.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules/Locale.pmod","/usr/lib/pike7.8/modules/Locale.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:183: /main()->dumpit("/usr/lib/pike7.8/modules","/usr/lib/pike7.8/modules") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:341: /main()->dump_files()
Ok, hmm.. That's a bit awkward since the codec cannot really try to dig out the same duplicate master objects on decode. I guess the right way is to make the encoder identify the master object(s) in a better way, so the decoder then always use the same one.
But the first step would be to find out why there are duplicate masters, and if possible avoid it. E.g. dumping the backtrace from create() should be useful to see where the second one is created.
The second master quite obviously is the MyMaster object that is created and passed to replace_master() in dump.pike. The question is why the original master, which is the one that is "unencodeable", hangs around.
Because the module Locale is a joinnode created by the old master.
Yes I figured that out too, so I fixed the encoder to encode references to both the master and all ex-masters the same way. Please see if it helps.
No cvs access?
cvs diff -D"2 hours ago" -Dnow
Index: lib/master.pike.in =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/lib/master.pike.in,v retrieving revision 1.474 retrieving revision 1.476 diff -u -r1.474 -r1.476 --- lib/master.pike.in 28 Jul 2010 10:29:59 -0000 1.474 +++ lib/master.pike.in 28 Jul 2010 22:58:01 -0000 1.476 @@ -6,7 +6,7 @@ // Pike is distributed under GPL, LGPL and MPL. See the file COPYING // for more information. // -// $Id: master.pike.in,v 1.474 2010/07/28 10:29:59 mast Exp $ +// $Id: master.pike.in,v 1.476 2010/07/28 22:58:01 mast Exp $
#pike __REAL_VERSION__ //#pragma strict_types @@ -85,6 +85,13 @@ //! int show_if_constant_errors = 0;
+int is_pike_master = 0; +// This integer variable should exist in any object that aspires to be +// the master. It gets set to 1 when the master is installed, and is +// therefore set in any object that is or has been the master. That +// makes the Encoder class encode references to the master and all +// ex-masters as references to the current master object. + // --- Functions begin here.
// Have to access some stuff without going through the resolver. @@ -5092,6 +5099,11 @@ } }
+ else if (what->is_pike_master) { + ENC_MSG (" is a master object\n"); + ENC_RETURN ("o/master"); + } + program prog; if ((prog = objects_reverse_lookup (what))) ENC_MSG (" found program in objects: %O\n", prog); Index: lib/modules/Tools.pmod/Standalone.pmod/dump.pike =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/lib/modules/Tools.pmod/Standalone.pmod/dump.pike,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- lib/modules/Tools.pmod/Standalone.pmod/dump.pike 25 Sep 2009 11:12:59 -0000 1.11 +++ lib/modules/Tools.pmod/Standalone.pmod/dump.pike 28 Jul 2010 23:31:42 -0000 1.12 @@ -6,7 +6,7 @@ || This file is part of Pike. For copyright information see COPYRIGHT. || Pike is distributed under GPL, LGPL and MPL. See the file COPYING || for more information. -|| $Id: dump.pike,v 1.11 2009/09/25 11:12:59 grubba Exp $ +|| $Id: dump.pike,v 1.12 2010/07/28 23:31:42 mast Exp $ */
constant description = "Dumps Pike files into object files."; @@ -114,9 +114,11 @@ } programs["/master"] = this_program; objects[this_program] = this; -#if constant(_gdb_breakpoint) - _gdb_breakpoint(); -#endif + + // When we arrive at our own dump.pike during dumping, we should + // dump it as a module class like any other, and thus we should + // remove the /main special case. + m_delete (programs, "/main"); } }
Index: src/builtin_functions.c =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/builtin_functions.c,v retrieving revision 1.704 retrieving revision 1.705 diff -u -r1.704 -r1.705 --- src/builtin_functions.c 27 Jul 2010 16:46:01 -0000 1.704 +++ src/builtin_functions.c 28 Jul 2010 22:51:00 -0000 1.705 @@ -2,7 +2,7 @@ || This file is part of Pike. For copyright information see COPYRIGHT. || Pike is distributed under GPL, LGPL and MPL. See the file COPYING || for more information. -|| $Id: builtin_functions.c,v 1.704 2010/07/27 16:46:01 mast Exp $ +|| $Id: builtin_functions.c,v 1.705 2010/07/28 22:51:00 mast Exp $ */
#include "global.h" @@ -7364,22 +7364,28 @@ */ PMOD_EXPORT void f_replace_master(INT32 args) { + struct object *new_master; ASSERT_SECURITY_ROOT("replace_master");
if(!args) SIMPLE_TOO_FEW_ARGS_ERROR("replace_master", 1); if(Pike_sp[-args].type != T_OBJECT) SIMPLE_BAD_ARG_ERROR("replace_master", 1, "object"); - if(!Pike_sp[-args].u.object->prog) + new_master = Pike_sp[-args].u.object; + if(!new_master->prog) bad_arg_error("replace_master", Pike_sp-args, args, 1, "object", Pike_sp-args, "Called with destructed object.\n");
if (Pike_sp[-args].subtype) bad_arg_error("replace_master", Pike_sp-args, args, 1, "object", Pike_sp-args, "Subtyped master objects are not supported yet.\n"); - + + push_constant_text ("is_pike_master"); + args++; + object_set_index (new_master, 0, Pike_sp - 1, &svalue_int_one); + free_object(master_object); - master_object=Pike_sp[-args].u.object; + master_object=new_master; add_ref(master_object);
free_program(master_program); Index: src/object.c =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/object.c,v retrieving revision 1.310 retrieving revision 1.311 diff -u -r1.310 -r1.311 --- src/object.c 11 Jul 2010 10:08:02 -0000 1.310 +++ src/object.c 28 Jul 2010 22:50:59 -0000 1.311 @@ -2,7 +2,7 @@ || This file is part of Pike. For copyright information see COPYRIGHT. || Pike is distributed under GPL, LGPL and MPL. See the file COPYING || for more information. -|| $Id: object.c,v 1.310 2010/07/11 10:08:02 grubba Exp $ +|| $Id: object.c,v 1.311 2010/07/28 22:50:59 mast Exp $ */
#include "global.h" @@ -658,6 +658,7 @@ }
{ + int f; ONERROR uwp;
/* fprintf(stderr, "Cloning master...\n"); */ @@ -673,7 +674,11 @@
call_c_initializers(master_object); call_pike_initializers(master_object,0); - + + f = find_identifier ("is_pike_master", master_program); + if (f >= 0) + object_low_set_index (master_object, f, &svalue_int_one); + /* fprintf(stderr, "Master loaded.\n"); */
UNSET_ONERROR (uwp); Index: src/svalue.c =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/svalue.c,v retrieving revision 1.261 retrieving revision 1.262 diff -u -r1.261 -r1.262 --- src/svalue.c 11 Jul 2010 12:39:10 -0000 1.261 +++ src/svalue.c 28 Jul 2010 22:46:39 -0000 1.262 @@ -2,7 +2,7 @@ || This file is part of Pike. For copyright information see COPYRIGHT. || Pike is distributed under GPL, LGPL and MPL. See the file COPYING || for more information. -|| $Id: svalue.c,v 1.261 2010/07/11 12:39:10 jonasw Exp $ +|| $Id: svalue.c,v 1.262 2010/07/28 22:46:39 mast Exp $ */
#include "global.h" @@ -30,14 +30,10 @@
#define sp Pike_sp
-PMOD_EXPORT const struct svalue svalue_undefined = +PMOD_EXPORT struct svalue svalue_undefined = SVALUE_INIT (T_INT, NUMBER_UNDEFINED, 0); -PMOD_EXPORT const struct svalue svalue_int_zero = SVALUE_INIT_INT (0); -#ifdef HAVE_UNION_INIT -PMOD_EXPORT const struct svalue svalue_int_one = SVALUE_INIT_INT (1); -#else +PMOD_EXPORT struct svalue svalue_int_zero = SVALUE_INIT_INT (0); PMOD_EXPORT struct svalue svalue_int_one = SVALUE_INIT_INT (1); -#endif
#ifdef PIKE_DEBUG PMOD_EXPORT const char msg_type_error[] = Index: src/svalue.h =================================================================== RCS file: /pike/data/cvsroot/Pike/7.8/src/svalue.h,v retrieving revision 1.172 retrieving revision 1.173 diff -u -r1.172 -r1.173 --- src/svalue.h 18 Feb 2010 08:52:55 -0000 1.172 +++ src/svalue.h 28 Jul 2010 22:46:40 -0000 1.173 @@ -2,7 +2,7 @@ || This file is part of Pike. For copyright information see COPYRIGHT. || Pike is distributed under GPL, LGPL and MPL. See the file COPYING || for more information. -|| $Id: svalue.h,v 1.172 2010/02/18 08:52:55 srb Exp $ +|| $Id: svalue.h,v 1.173 2010/07/28 22:46:40 mast Exp $ */
#ifndef SVALUE_H @@ -323,13 +323,8 @@
#define FUNCTION_BUILTIN USHRT_MAX
-extern PMOD_EXPORT const struct svalue svalue_undefined, svalue_int_zero; -#ifdef HAVE_UNION_INIT -extern PMOD_EXPORT const struct svalue svalue_int_one; -#else -/* The value 1 is initialized first thing in init_pike. */ -extern PMOD_EXPORT struct svalue svalue_int_one; -#endif +extern PMOD_EXPORT struct svalue svalue_undefined, + svalue_int_zero, svalue_int_one;
#define is_gt(a,b) is_lt(b,a) #define is_ge(a,b) is_le(b,a)
Sure, anon CVS is always available, but I didn't know exactly what commits were relevant to this problem.
Now I get
#### /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike: Cannot find Tools.Standalone.dump() in master()->dirnode("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod":Tools.Standalone.module). /usr/lib/pike7.8/master.pike:4956: master()->Encoder()->find_index(master()->dirnode("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod":Tools.Standalone.module),Tools.Standalone.dump(),UNDEFINED,UNDEFINED) /usr/lib/pike7.8/master.pike:5172: master()->Encoder()->nameof(@0=Tools.Standalone.dump(),UNDEFINED) /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:222: Tools.Standalone.dump()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike","/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:185: Tools.Standalone.dump()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod","/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:185: Tools.Standalone.dump()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod","/usr/lib/pike7.8/modules/Tools.pmod") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:185: Tools.Standalone.dump()->dumpit("/usr/lib/pike7.8/modules","/usr/lib/pike7.8/modules") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:343: Tools.Standalone.dump()->dump_files() -:1: Pike.Backend(0)->`()(3600.0)
Can't say why the dirnode doesn't find dump.pike all of a sudden.
Something to watch out for is duplicate dirnode trees however. I have a suspicion that there might be such a problem lurking, because in my own testing yesterday, ENCODE_DEBUG reported several cases like this:
nameof (object Stdio) found program in objects: object_program(Stdio) found path in programs: "/home/mast/Pike/devel/lib/modules/Stdio.pmod/module.pmod" program name: "Stdio" compare_resolved: Stdio is different from Stdio Warning: Failed to resolve; encoding path returned "o/home/mast/Pike/devel/lib/modules/Stdio.pmod/module.pmod"
And having several Stdio modules doesn't look good.
Maybe the replaced master is the culprit there as well, or perhaps it's a problem with all that compat resolver stuff. I have however seen it for Tools.AutoDoc, which doesn't exist in any of the module compat trees.
Here is the preceding ENCODE_DEBUG output:
nameof (program dump.pike()->MyMaster) got parent: dump.pike nameof (program dump.pike) got the thing to encode - encoding recursively inside the thing to encode - encoding recursively nameof (function indices) returned "cindices" nameof (function object_program) returned "cobject_program" nameof (function m_delete) returned "cm_delete" nameof (program Tools.Standalone.dump()->MyMaster) got parent: Tools.Standalone.dump nameof (program Tools.Standalone.dump) found path in programs: "/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike" compare_resolved: Tools.Standalone.dump is Tools.Standalone.dump returned "rTools.Standalone.dump" parent has name: "rTools.Standalone.dump" found function name in parent: "MyMaster" returned ({ /* 2 elements */ "rTools.Standalone.dump", "MyMaster" }) nameof (object Tools.Standalone.dump()) got program of object: Tools.Standalone.dump found parent path in programs: "/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod" got parent of program: master()->dirnode("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod":Tools.Standalone.module) nameof (object master()->dirnode("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod":Tools.Standalone.module)) is a dirnode compare_resolved: master()->dirnode("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod":Tools.Standalone.module) is different from master()->joinnode(({ /* 1 element */ master()->dirnode("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod":Tools.Standalone.module) })) found path in fc: "/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod" compare_resolved: master()->dirnode("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod":Tools.Standalone.module) is different from master()->joinnode(({ /* 1 element */ master()->dirnode("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod":Tools.Standalone.module) })) Warning: Failed to resolve; encoding path returned "f/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod" parent has name: "f/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod"
The one in dump.pike looks like something else, though. The ENCODE_DEBUG output prior to it might give a clue.
nameof (program dump.pike()->MyMaster) got parent: dump.pike nameof (program dump.pike) got the thing to encode - encoding recursively inside the thing to encode - encoding recursively nameof (function indices) returned "cindices" nameof (function object_program) returned "cobject_program" nameof (program /main()->MyMaster) got parent: /main nameof (program /main) found path in programs: "/main" compare_resolved: /main is different from 0 Warning: Failed to resolve; encoding path returned "p/main" parent has name: "p/main" found function name in parent: "MyMaster" returned ({ /* 2 elements */ "p/main", "MyMaster" }) nameof (object /main()) got program of object: /main found parent path in programs: "/" #### /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike: Failed to find name of unencodable object /main(). /usr/lib/pike7.8/master.pike:5170: master()->Encoder()->nameof(/main(),UNDEFINED) /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:220: /main()->dumpit("/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike","/usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike") /usr/lib/pike7.8/modules/Tools.pmod/Standalone.pmod/dump.pike:341: /main()->dump_files() -:1: Pike.Backend(0)->`()(3600.0)
Perhaps not such a huge problem that dump.pike fails to dump itself.
Also, when run with -DENCODE_DEBUG -DRESOLV_DEBUG, there are many cases of
resolv("/${PIKE_MODULE_PATH}/Foo.Bar", 0) => not found compare_resolved: object_program(/${PIKE_MODULE_PATH}/Foo.Bar) is different from 0 Warning: Failed to resolve; encoding path
where Foo.Bar varies. Is that normal? I would have guessed that resolv takes the name of something, not a path.
Yes, that looks wrong. I get the impression that the PIKE_MODULE_RELOC stuff isn't playing nice with the resolver and/or encoder. Did those warnings disappear when you turned off PIKE_MODULE_RELOC?
Also, when run with -DENCODE_DEBUG -DRESOLV_DEBUG, there are many cases of
resolv("/${PIKE_MODULE_PATH}/Foo.Bar", 0) => not found compare_resolved: object_program(/${PIKE_MODULE_PATH}/Foo.Bar) is different from 0 Warning: Failed to resolve; encoding path
where Foo.Bar varies. Is that normal? I would have guessed that resolv takes the name of something, not a path.
Yes, that looks wrong. I get the impression that the PIKE_MODULE_RELOC stuff isn't playing nice with the resolver and/or encoder. Did those warnings disappear when you turned off PIKE_MODULE_RELOC?
Yes, looks like they did.
Ok. It might be just a simple oversight somewhere. If you want to make PIKE_MODULE_RELOC work, I suggest something like
if (has_prefix (identifier, "/${PIKE_MODULE_PATH}/")) werror (describe_backtrace (backtrace()));
at the beginning of resolv(), to see where it comes from.
[...]
I've only come up with one possible sollution to this. Which is, push the byte-compiling of the code into a post-install script. This way the byte-compiling can be done on the target machine. But maybe there is a better sollution?
This is the standard solution used by our own binary distributions.
Is there a way to avoid byte-compiling at compile time that I've missed or do you just discard the .o files?
What do the debian packages of e.g. Emacs do? Byte-compile at compile or install time?
At install time.
Is there a way to avoid byte-compiling at compile time that I've missed or do you just discard the .o files?
AFAIK there is no byte-compiling to avoid when you compile normally.
Only "make verify" byte-compiles everything because it performs an install operation. This happens in a special directory test-install though, so you never get byte-compiled files in any of the dirs used by "make export" or "make bin_export".
Right, it's not really at compile time but at install time; what we do is $(MAKE) INSTALLARGS=--traditional \ buildroot=$(TMP) \ prefix=/usr \ man_prefix=/usr/share/man \ lib_prefix="$(lib_prefix)" \ include_prefix="$(include_prefix)" \ pike_name=/usr/bin/$(PIKE) \ install_nodoc
So we should use bin_export instead?
make bin_export runs install.pike with the --export flag, which does two things:
* Instead of copying files to a directory, they are put in a .tar.gz (or in the case of Windows, a "burk")
* Instead of running dump_modules(), which performs the byte-compilation, it runs do_export(), which will package the tar.gz and the installation script into a self-extracting tar
- Patch to src/configure.in
This patch can be included as is into pike, I think this was is a bug in configure.in because it originally tries to use the newly build pike instead of the pike installed on the host.
If the diff is manageable I prefer to patch configure and avoid depending on and running autoconf. I suppose that's the only reason for the last hunk of rules.diff.
How do you ensure that pike is installed on the host system before cross-compiling for other architectures?
- Patch to src/modules/Mysql/configure
I think this patch was already included in src/modules/Mysql/configure.in.
That one looks reversed.
pike-devel@lists.lysator.liu.se
-
Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum -
Marc Dirix -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Bähr -
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum