You were right on the $$ about the source of the config weirdness. cygwin had scattered many copies of /<drive_root>cygwin and home.brianp directories. I had missed one on an obscure, deeply buried location on one of my data drives.

Got everything pointing to the new Strawberry Perl location. But a number of the builds are failing; Image(Perl)Magick and ExifTool. I am going to reinstall ImageMagick. Not sure about ExifTool.

Trying to build imagemagick from source to link it into my C programs was what got me venturing into this quagmire in the first place. The (Open_Source) IM gang only supports the msvc compiler on windoz and my research suggests that you have to use the same (32bit) compiler and the same (i386??) optimizations to link to their binary distributions.

The good news is that GD works like a charm and is a Speed Daemon with GCC/64 bit. Can hardly wait to try it out on Intel!

Thanks 1E6

   JCRISTY/PerlMagick-6.89-1.tar.gz
  E:\STRAWB~1\c\bin\dmake.exe -- OK
Running make test
"E:\strawberry_perl\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTe
+st::Harnes
s" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', '
+blib\arch'
)" t/*.t t/bzlib/*.t t/jpeg/*.t t/png/*.t t/tiff/*.t t/wmf/*.t t/zlib/
+*.t
t/blob.t .......... ok
t/bzlib/read.t .... ok
t/bzlib/write.t ... ok
t/composite.t ..... ok
t/filter.t ........ ok
t/getattribute.t .. ok
t/jpeg/read.t ..... ok
t/jpeg/write.t .... ok
t/montage.t ....... Failed 2/19 subtests
t/ping.t .......... ok
t/png/read-16.t ... ok
t/png/read.t ...... ok
t/png/write-16.t .. ok
t/png/write.t ..... ok
t/read.t .......... ok
t/setattribute.t .. ok
t/tiff/read.t ..... ok
t/tiff/write.t .... ok
t/wmf/read.t ...... Failed 2/2 subtests
t/write.t ......... ok
t/zlib/read.t ..... ok
t/zlib/write.t .... ok

Test Summary Report
-------------------
t/montage.t     (Wstat: 0 Tests: 19 Failed: 2)
  Failed tests:  12-13
t/wmf/read.t    (Wstat: 0 Tests: 2 Failed: 2)
  Failed tests:  1-2
Files=22, Tests=333, 38 wallclock secs ( 0.16 usr +  0.06 sys =  0.22 
+CPU)
Result: FAIL
Failed 2/22 test programs. 4/333 subtests failed.
dmake.exe:  Error code 255, while making 'test_dynamic'
  JCRISTY/PerlMagick-6.89-1.tar.gz
  E:\STRAWB~1\c\bin\dmake.exe test -- NOT OK
//hint// to see the cpan-testers results for installing this module, t
+ry:
  reports JCRISTY/PerlMagick-6.89-1.tar.gz
Stopping: 'install' failed for 'Image::Magick'.
[download]

The (Open_Source) IM gang only supports the msvc compiler on windoz and my research suggests that you have to use the same (32bit) compiler and the same (i386??) optimizations to link to their binary distributions.

But doesn't your Strawberry build link to their binary distributions ?
Mine used their dlls, though I (perhaps unnecessarily) rebuilt the import libs from those dlls using gendef and dlltool.

I get the same test failures as you ... though, occasionally, the montage tests succeed.

Do you know how siginificant those failures are ? (I don't.)
They're not *obviously* of far-reaching siginificance:

C:\sisyphusion\Image-Magick-6.89>perl t/montage.t
1..19
.....
Test 12, signatures do not match.
     Expected: bcd96dabb454c5d25091422763b1cdecb6a69a9b02b84a5b7fa0a70
+f150b957c
     Computed: f1ed563cf9a446dd4516945b475bc21692037d0c12a83405a837abc
+bdf37bcf7
     Depth:    16
not ok 12
Test 13, signatures do not match.
     Expected: 9209b2db884fa4730eeab6c410b90e094fa305635baab7ede17270c
+13f6e80ad
     Computed: c09fb4e6033eb562b277dc2d8d5b61e4255b56ee9c666011d18e4fe
+7fbee994b
     Depth:    16
not ok 13
.....

C:\sisyphusion\Image-Magick-6.89>perl t/wmf/read.t
1..2
mean-error=1.00003051827663, maximum-error=1
not ok 1
mean-error=1.00003051827663, maximum-error=1
not ok 2
[download]

Even the slightest and most insignificant variation would result in a failed signature match.
And 1.00003051827663 is only just outside the "maximum-error".

Cheers,
Rob

Rob, >> Mine used their dlls, though I (perhaps unnecessarily) rebuilt the import libs from those dlls using gendef and dlltool.

I finally got everything to compile and link, but I could not make it work with static. I had to use --enabled-shared. Why would anybody prefer shared over static for, say, ImageMagick?

When you are dashing off to work in the morning, who would want to scour the neighborhood for 4 matching tires, pressurize them uniformly, jack up the car, torque them to spec, put the tools away and then, after half an hour of needless rigmarole, you're finally off! Why?

In the horrible, old dos days when you had to operate in a Megabyte or less, this made sense. Today, breaking find.exe into a 64k .exe and 3 DLLs totaling 4.26MB seems anachronistic.

With disk space going for $150 per 4 TERABYTES, a 100% disk savings on 4 Mb is worth:
4E6B * $150 / 4E12B = $0.00015.
If you have 7000 dlls, your savings could approach a whole DOLLAR! All of cygwin that I used had 331 DLLs totaling 75MB so they saved less than ¢1/3. The space saving angle is PREPOSTEROUS on the face of it!

How much memory are you saving when you load a DLL containing 100 functions when you will only use 3 of them, with each costing a page fault? Caching code you will never use is a 100% waste. Seeking your heads all over town scavenging scattered DLLs while reading ahead MBs of stuff you will never use is another titanic cache miss! How can you beat 1 seek, 1 read, a tiny amount of excess read ahead and being immediately ready for action?

But if you already a module have loaded into memory, you can share the same image? It's like having 5 kids and one set of toys and arbitrating who will get which toy and when. Buy each kid their own toy for $5 each and forget about the critical regions, setting and checking semaphores, locking and unlocking, rounding of robins, mutual assured exclusions, mutating mutexes, etc.

There is a case when using a library provided by a third party where a DLL is efficient, but when you have all of the code right there, chopping it into tiny chunks and assembling it just before you need it seems like the pinnacle of inefficiency.

Time is $$. My main use case is crunching 219MB of UINT48, raw, RGB data AFAP. Paying a 5% - 20% performance penalty to save a MB of memory seems absurd unless you are on a tiny device with extremely limited resources. I have 32GB already paid for so saving a meg or 2 saves me absolutely nothing.

I must be missing something here.
B

The (Open_Source) IM gang only supports the msvc compiler on windoz and my research suggests that you have to use the same (32bit) compiler and the same (i386??) optimizations to link to their binary distributions.

But doesn't your Strawberry build link to their binary distributions ?
Mine used their dlls, though I (perhaps unnecessarily) rebuilt the import libs from those dlls using gendef and dlltool.

I get the same test failures as you ... though, occasionally, the montage tests succeed.

Do you know how siginificant those failures are ? (I don't.)
They're not *obviously* of far-reaching siginificance:

C:\sisyphusion\Image-Magick-6.89>perl t/montage.t
1..19
.....
Test 12, signatures do not match.
     Expected: bcd96dabb454c5d25091422763b1cdecb6a69a9b02b84a5b7fa0a70
+f150b957c
     Computed: f1ed563cf9a446dd4516945b475bc21692037d0c12a83405a837abc
+bdf37bcf7
     Depth:    16
not ok 12
Test 13, signatures do not match.
     Expected: 9209b2db884fa4730eeab6c410b90e094fa305635baab7ede17270c
+13f6e80ad
     Computed: c09fb4e6033eb562b277dc2d8d5b61e4255b56ee9c666011d18e4fe
+7fbee994b
     Depth:    16
not ok 13
.....

C:\sisyphusion\Image-Magick-6.89>perl t/wmf/read.t
1..2
mean-error=1.00003051827663, maximum-error=1
not ok 1
mean-error=1.00003051827663, maximum-error=1
not ok 2
[download]

Even the slightest and most insignificant variation would result in a failed signature match.
And 1.00003051827663 is only just outside the "maximum-error".

Cheers,
Rob