Skip Menu |
 

This queue is for tickets about the Perl-Dist-Strawberry CPAN distribution.

Report information
The Basics
Id: 58079
Status: resolved
Priority: 0/
Queue: Perl-Dist-Strawberry

People
Owner: csjewell [...] cpan.org
Requestors: csjewell [...] cpan.org
Cc: RIVY [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Can't find libmysql_.dll when loading DBD::mysql
From: csjewell [...] cpan.org
Hi Curtis,

I went through the above mention blog post and come to this idea:

what about to install all DLLs from external lib packs not to strawberry\c\bin but to strawberry\perl\bin

It could definitely avoid some pains.

--
kmx



Show quoted text
> what about to install all DLLs from external lib packs not to
> strawberry\c\bin but to strawberry\perl\bin

One "maybe-interesting side-effect" will be that those who want to bundle strawberry with their application they simply drop the whole strawberry\c directory once they have preinstalled all necessary prereq. modules.

--
kmx

Patched in r#12623.
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
Download (untitled) / with headers
text/plain 2.4k
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.
Subject: Re: [rt.cpan.org #58079] Can't find libmysql_.dll when loading DBD::mysql
Date: Sun, 09 Feb 2014 09:42:11 +0100
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 1.1k
Show quoted text
> 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?
It should be absolutely fine and safe to move all c:\strawberry\c\bin\*_.dll to c:\strawberry\perl\bin. Some time ago I was even considering changing strawberry installer/ZIP in this way (maybe it is time to think about it again). Using different c compiler might cause some issue depending on how much different the other compiler is (but you probably know about this). Show quoted text
> 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?
We are already using our "vendor" specific DLL naming: *_.dll (for 32bit dlls) and *__.dll (for 64bit dlls) - I think it works as expected. -- kmx


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.