Hello,
I have I problem with building Prima on strawberry 5.12.3, which appears when I use
Strawberry installed in something other than c:/strawberry directory. The problem
didn't re-appear cleanly when I tried to take a clean vmware box, and install it there,
so I'm not 100% sure how to reproduce it. However a Prima user send that bug to me,
so there's something wrong not only on my machine.
The problem is as such: Prima needs libgdi32.a, which is not found because $Config{libpth}
doesn't contain the path to it (it's in c:/somewhere_else/c/i686-w64-mingw32/lib ). However in Config.pm
there is this line:
libpth => 'C:\\strawberry\\c\\lib C:\\strawberry\\c\\i686-w64-mingw32\\lib',
which seems valid, but if I call either 'perl -V:libpth' or 'perl -MConfig -le "print $Config{libpth}"
I get printed
c:\somewhere_else\c\lib
only. Some substitution gone wrong. To test this further I've temporarily removed Config.pm to see if some
other Config.pm gets picked, - no, it wasn't. Next, I've hacked a copy of Config.pm into Config2.pm (and renamed
it inside), and unsurprisingly, calling 'perl -MConfig2 -le "print $Config{libpth}' yielded just that
unsubstituted line:
C:\strawberry\c\lib C:\strawberry\c\i686-w64-mingw32\lib
I tried to find where the substitution magic is executed to see if the problem is indeed there, but couldn't
find where it gets done.
So I'll need your help here. If anyone can confirm that (and when) $Config{libpth} gets hacked, or point me
to the code where the magic is done, that'd be really appreciated.
--
Sincerely,
Dmitry Karasik
Thread Next