From: Reini U. <ru...@x-...> - 2011-03-02 21:43:34
|
2011/3/2 Charles Wilson: > On 3/1/2011 10:51 AM, LRN wrote: >> On 27.02.2011 22:02, Charles Wilson wrote: >>> In any case, we might also need to bring in Reini's 'perlrebase' tool, >>> which is a script like rebaseall, but invokes rebase.exe only on perl >>> DLLs with some special settings for perl. > *perlrebase*, on the other hand, is a shell script that ONLY rebases the > dlls associated with perl, including extension XS dlls. It also uses an > address range different than that used by rebaseall for the /rest/ of > the DLLs on the system -- this way, the two sets of DLLs will be > unlikely to have image base addresses that clash. perlrebase also uses the address range upwards while rebaseall uses the address range downwards, so the chance for an overlap and fork error then is quite small. > However, since perlrebase is a shell script, and doesn't use any perl > commands, one can hope that perl is not loaded into memory, and hence: > the DLLs associated with perl will all be rebase-able (e.g. not in use). > > So...for *perl* there's not really any need for a native version of rebase. > > HOWEVER...I *can* see a case where you would want (a) your native > rebase, and (b) a native "rebaseall"-ish application. And that is when > your installation is so screwed up, that you can't even run dash.exe or > you get the dreaded fork error when trying to run the rebaseall script. > (FWIW, I'd also want to see something similar re: peflags/peflagsall to > consider it a full "native" port of the rebase package). > > But, once that is complete, I'm sure Jason would incorporate those > changes upstream -- at worst, in a mingw-specific branch, and we could > ship a mingw-rebase package. Perhaps, in order to prefer at first the > msys version, we'd install into /mingw/lib/rebase/ rather than > /mingw/bin/, and only after a long testing period change the package to > install into the "prefered" /mingw/bin location where it would take > precedence over the msys one. > > I'll take a look at your current rebase mods later this week. > >> It could be >> also run automatically - simply make a batch file that waits a few >> seconds, kills any msys processes still running, runs rebase, re-runs >> msys-sh, making it run a particular script (which is written beforehand) >> that will restore the shell state (set env variables, cd into the right >> directory and run the right command, probably `make $something'). > > I think this is overkill. Now, /perhaps/ something similar could be > integrated into mingw-get (not sure if this is advisable; cygwin's > setup.exe has gone for years without trying to incorporate rebasing; I > suspect doing so would actually CAUSE more problems than it would > solve). But I don't see a need for a fancy batch file to kill msys > processes, run rebase(all).exe, restart, etc etc. > >> With such a tool it should be possible to rebase perl after it is >> compiled and before its testsuite is run - and all that would be >> completely automatic! I do this in my build script. rebase before the test, and after compiling the vendor modules again. See http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/perl/build_common and http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/perl/build > Ah, but see, there's no need for this. All you really need to do is to > rebase each newly-built XS dll (and the main msys-perl-5_N.dll) before > trying to run any perl scripts (or the new perl.exe, or miniperl.exe) > And doing THAT doesn't require a native perl, or to avoid > bash.exe/sh.exe. You can simply add the appropriate rebase.exe command > (or perlrebase invocation [*]) as part of the Makefile (or MakeMaker > code). It does mean that you (probably) can't build perl with 'make > -jN' (unless N=1)... Yes, something like this is the idea but it is not implemented yet. We would need some kind of perl global imagebase-file of the last rebased dll to be able to continue from there. You even would not need rebase, we could generate the correct baseaddress for the linker automatically and advance the global imagebase-file if we check the code size also. EUMM and MB needs to be supported at least. No big deal technically. Heavy cygwin CPAN users would love it. > In fact, that's pretty much was cygwin's perl 5.10.x distribution does, > if you look in its source tarball IIRC. Also, in perl git master, > there's this (as mentioned by Reini Urban earlier this morning; post > hasn't shown up on the list yet): > > Reini wrote: >> BTW, I added recently a rebaseall/perlrebase trick to perl core for >> cygwin only. I believe this should be used my msys perl also, best by >> just inherting from MM_Cygwin. >> http://perl5.git.perl.org/perl.git/commit/172830635ea7813c85e51e > This particular change really only helps when you are building cygwin > (msys) perl on a system that already has cygwin (msys) perl *of the same > revision* installed. It ensures that the new Cwd.dll you just built > (for perl-5.A.B) uses the same image_base as the Cwd.dll already > installed in /usr/lib/perl5/5.A.B/ (Obv. ditto for all other XS dlls) > If your currently installed cygwin (msys) perl-5.A.B works, then this is > probably a "good" address to use for the new dll... Exact. Just an imprfovement if it already exists, not a full solution. But most anger stems from updating existing DLL's. And with completely new DLL's this situation rarely appears. > [*] I think perlrebase is written to operate on /usr/lib/perl5/$VER/, > not $builddir/blib/*, but we can check with Reini if we need > improvements along those lines. Yes, I forgot this, blib/arch should be added also. But in the last years I never really needed that. Most conflicts arise only in the very first loaded DLL's, like Cwd.dll, ZLib.dll or version.dll. Now I even link Cwd statically, so once chance less and faster startup. -- Reini Urban |