in reply to Re^6: Tcl for Strawberry Perl on Windows 64bit
in thread Tcl for Strawberry Perl on Windows 64bit

I ran the following code to create the symbol list from zlib1.dll, and indeed the symmbol inflateGetHeader is included in zlib1.def. I also created libzlib1.a

I can only think that a different zlib1.dll (one that doesn't export that function, and is elsewhere in your PATH) has been loaded.

Try renaming the zlib1.dll in C:/Tcl/bin to (eg) zlib1.dll_hide, and see if that makes any difference to the errors you're getting.
If it does make a difference, then that means that the C:/Tcl/bin/zlib1.dll is probably the dll that was being loaded. But if it makes no difference, then there's probably another zlib1.dll that's being loaded.

The import lib you subsequently created is not needed as the build (dmake) stage did not contain any code that directly referenced any zlib functions, and the Tcl dll will automatically load the zlib functions (if they're present in the zlib dll).
If that import lib had been needed then the 'dmake' stage would have failed initially.

Cheers,
Rob
  • Comment on Re^7: Tcl for Strawberry Perl on Windows 64bit

Replies are listed 'Best First'.
Re^8: Tcl for Strawberry Perl on Windows 64bit
by Anonymous Monk on Jul 24, 2015 at 01:42 UTC

    Try renaming ...

    Simply putting Tcl\bin first in %PATH% ought to suffice

      Simply putting Tcl\bin first in %PATH% ought to suffice

      I think that would mean that everything that wants to load zlib1.dll will then load the one that's in Tcl/bin.
      What if there's something that needs to load the other (different) zlib1.dll ? It may now break - a somewhat unlikely scenario, admittedly :-)

      If you want to ensure that Tcl/bin/Tcl.dll (and nothing else) loads that C:/Tcl/bin/zlib1.dll you can:
      1) Copy C:/Tcl/bin/zlib1.dll to, say, C:/Tcl/bin/zxxxx.dll;
      2) In C:/Tcl/bin/Tcl.dll, change every occurrence of "zlib1.dll" to "zxxxx.dll". It's best to do this second step programmatically, and to keep a backup copy of the original Tcl.dll in case something goes awry.

      This hack (which I've used many times, though not with Tcl) ensures that the Tcl.dll will load zxxxx.dll instead of zlib1.dll - so it doesn't matter how many zlib1.dll files are in the path.

      However, you can't just pick *any* arbitrary name for the zlib1.dll copy - the name of the copy must contain the same number of characters as the original.
      That is, for this particular dll, the name you choose must consist of exactly 5 characters - it doesn't matter what those characters are, so long as they are valid filename characters.

      Update: I probably should give some sort of indication of the program I would use to effect this hack. This is untested:
      use strict; use warnings; use File::Copy; File::Copy::copy('Tcl.dll', 'Tcl.dll_bak') or die $!; open my $infh, '<', 'Tcl.dll' or die $!; open my $outfh, '>', 'Tcl.dll_new' or die $!; binmode($infh); binmode($outfh); while(<$infh>) { $_ =~ s/zlib1\.dll/zxxxx.dll/g; print $outfh, $_; }
      Then check that Tcl.dll, Tcl.dll_bak and Tcl.dll_new all exist.
      If they do, remove Tcl.dll and rename Tcl.dll_new to Tcl.dll.
      If they don't exist .... freak !!

      The actual code that I would be using does all of the removing and renaming, too.
      And it does some stuff with permissions - though I'm not sure whether that's generally necessary:
      close $infh; close $outfh; my $mode = (stat('Tcl.dll'))[2]; my $newmode = $mode | 0220; chmod($newmode, 'Tcl.dll'); unlink 'Tcl.dll'; File::Copy::copy( 'Tcl.dll_new', 'Tcl.dll') or die $!; chmod($mode, 'Tcl.dll'); unlink('Tcl.dll_new');


      Cheers,
      Rob

        Thankyou everyone for your help and guidance. Problem solved.

        When I renamed C:\Tcl\bin\zlib1.dll and tried perl Makefile.pl I got the same zlib1 error "The procedure entry point inflateGetHeader could not be located in the dynamic link library zlib1.dll". This clearly indicated existance of another zlib1.dll, and indeed on searching my system drive I found four. Using a perl implementation of 'which' I found two of those were indeed in the PATH, listed these in order. It was then a simple job to re-order my PATH (the ordering was pretty random anyway), following which I was able to build Tcl succesfully.

        All pretty simple in hindsight - but I might not have got there without the expert guidance. Thanks Again.