On Sun Jul 18 07:28:21 2010, KMX wrote:
Show quoted text> Hi Curtis,
>
> I slightly disagree with this patch.
>
> The original problem in case described at lpsolit.wordpress.com was
> for sure
> incorrectly set PATH variable (libmysql_.dll is in c:\strawberry\c\bin
> so this
> dir has to be in PATH).
>
> The problem occurs when you run a perl script from webserver (Apache,
> IIS) as
> the webserver runs usually under a special user and you have either to
> set PATH
> system wide or to set PATH for the user used by webserver.
>
> Why I do not like you patch is the fact that it will not work when
> user decides
> to install new DBD::mysql from CPAN - the new install will go to
> "site" but you
> are copying libmysql_.dll in "vendor" - so in theory it can make
> future
> troubleshooting even more complicated.
>
> The other question is "why just libmysql_dll?" as exactly the same
> problem can
> occur with any other *.dll from c:\strawberry\c\bin.
>
> To sum up: please consider again the patch rev#12623
>
> --
> kmx
@KMX, Curtis,
I've run into this issue from a slightly different perspective.
As I use some perl scripts in my basic utility tool chest, I install perl into all of my Windows machines. But I use various GCC compilers (for testing, cross-compiling, etc) at different times, *not* always the MinGW gcc included with strawberry. Therefore, I specifically exclude the "...\perl\c\bin" directory from my PATH.
This leads to similar missing DLL problems. In my case, it's usually missing "libeay32__.dll" and "ssleay32__.dll" from scripts using HTTPS. I understand from this that I could fix it by copying adding the mentioned path or adding all the DLLs to the "..\perl\bin" directory, but is there some way to portably place these DLLs so that the "..\perl\c\bin" path is not needed in PATH except when actually compiling modules?
I'd like to be able to use the alternate compilers without breaking simple perl scripts. Would you recommend just bluntly copying all the DLLs from the "..\perl\c\bin" directory to the "..\perl\bin" directory?
I saw your concern about complicating future troubleshooting and installation failures. And, I don't fully understand the DLL interactions of the strawberry installations. But, if the DLL names were even more obviously "vendor", say by being named "libXXX_strawberry.dll", would that mitigate the possible troubleshooting issue allowing them to be moved to a more purely perl location?
Thanks for the consideration.
RT for rt.cpan.org