DBD::MySQL Running on 64bit server

Riklin · #1 02-04-2015, 02:34 AM

Forgive me in advance... I'm struggling a bit here to explain what I barely understand (lack of experience).

I have stumbled on the plugins and waded through them. There are some excellent, excellent plugins there, indeed! As I understand it, in order to get the plugins to work, you need to get DBD::MySQL to work. Otherwise the plugins don't do anything. I tried using them and nothing happened other than the entire perl script stopped working when a single plugin entry was added.

My server is a windows 7 Pro machine. 8 core, 32 gig ram, 1tbx4 RAID10 drives very fast internet connection, etc...

I have deviated from the standard installation instructions slightly. I install and run 64 bit versions of as many of the components as possible.

ActivePerl 5.14.2 build 1402 64bit.
MySQL 5.1 x64

Compiled with Visual Studio 2013 in x64 mode for 8core.

The server works flawlessly, so far. I update source and recompile once a week.

I found the webpage link to getting DBD::MySQL to work, but as far as I can tell that works with one very specific version 32 bit version of Perl.

Can you give me any advice as to how to get this to work with a 64 bit version of MySQL and Active Perl without spending $1000+ for a perl license?

Thanks,
Rick (Halls Havoc)

**Akkadius** · #2 02-04-2015, 04:17 AM

Don't use x64 Perl, there's nothing to really be gained out of using it.

Use the approved version on the wiki, that's all it comes down to.

Riklin · #3 02-04-2015, 10:52 AM

I have tried several times to do a build with the x64 perl removed and the "standard" version of perl installed, however the compiler seems to want all the libs/DLLs to be either 64bit or 32bit, not a mix... It errors out if there is a mix.

I guess I'll keep tinkering a bit and see if I can get it to compile without errors. I really do not want to go back to 32 bit, especially since everything else seems to work perfectly in 64 bit.

**Akkadius** · #4 02-04-2015, 02:31 PM

Quote:

Originally Posted by Riklin

I have tried several times to do a build with the x64 perl removed and the "standard" version of perl installed, however the compiler seems to want all the libs/DLLs to be either 64bit or 32bit, not a mix... It errors out if there is a mix.

I guess I'll keep tinkering a bit and see if I can get it to compile without errors. I really do not want to go back to 32 bit, especially since everything else seems to work perfectly in 64 bit.

MySQL does not need to change back to 32 bit, only the Perl libs need to change.

And more particularly, you really really once again should be using a Perl version that plays nice with our embedded source. If you run into random crashes don't expect us to support it.

Riklin · #5 02-04-2015, 04:15 PM

Ok. I get the point... I have loaded the officially supported version of perl a couple times and tried to get it to compile, but it keeps not finding different .h files. One thing I haven't tried yet is to flush cmake and let it find all the perl stuff, with the 32 bit version loaded. I'll try that tonight...

Based on other threads, it seems like perl may not be used here, in the future... Lua seems to be taking over...

**Akkadius** · #6 02-04-2015, 04:16 PM

Quote:

Originally Posted by Riklin

Ok. I get the point... I have loaded the officially supported version of perl a couple times and tried to get it to compile, but it keeps not finding different .h files. One thing I haven't tried yet is to flush cmake and let it find all the perl stuff, with the 32 bit version loaded. I'll try that tonight...

Based on other threads, it seems like perl may not be used here, in the future... Lua seems to be taking over...

You need to re-run CMAKE again if you reinstalled another Perl

Riklin · #7 02-04-2015, 04:24 PM

I was rerunning it, but wasn't flushing the cache and rerunning it after changing the perl.

Last night I noticed that when you flushed and reran cmake, it "found" things more thoroughly. I'm still learning the idiosyncrasies of these particular software components.

You guys are light years ahead of me, regarding how these components interact together. I'm trying to catch up, or at least get comfortable with it all. Thank you for the help and for being patient...

**Akkadius** · #8 02-04-2015, 04:29 PM

Quote:

Originally Posted by Riklin

I was rerunning it, but wasn't flushing the cache and rerunning it after changing the perl.

Last night I noticed that when you flushed and reran cmake, it "found" things more thoroughly. I'm still learning the idiosyncrasies of these particular software components.

You guys are light years ahead of me, regarding how these components interact together. I'm trying to catch up, or at least get comfortable with it all. Thank you for the help and for being patient...

It's all good

Riklin · #9 02-07-2015, 06:49 PM

Based on Akka's comments, I tried to use the recommended 32 bit version of Activestate Perl. The compiler doesn't like mixing of 32bit/64bit libraries. Therefore on my test server (which is set up and configured identically to my main server), I removed all the 64 bit software and installed all the recommended versions (from the server guide) of the software. This includes perl, MySQL, the dependencies, etc. The compiler is Visual Studio 2013. Cmake is 32 bit. Git and svn are 64 bit versions, but that should make no difference.

It all compiles normally, no errors. Whenever starting the server, I get this irritating "The application was unable to start correctly (0xc000007b)" error.

World.exe states perl version is 5.12.3. It executes the Automatic Upgrade Check, so I know world is running correctly. The problem is exclusively with the Zone.exe. The database is online. Navicat finds it and I can view the tables normally, so MySQL (32bit) version 5.1.73 is working normally. even command line MySQL commands work normally.

I am certain everything is 32bit, but Zone.exe won't load. It gives this error everytime.

Again no compile errors. Cmake finds everything perfectly.

The only reason I'm doing this is because I want to use the plugins and cannot find any instructions that make any sense for setting up DBD::MySQL so that the plugins work. The only options seems to be do everything 32 bit and overwrite a lot of the perl stuff with the perl.rar file, as directed in the "Installing Perl DBI and other Modules" guide.

I can't get the 32 bit version of the server to run... So I cannot make it work the "easy way".

I have PPM installed on the 64 bit server, but cannot find any instructions for configuring it to work with the plugins. Those plugins provide a lot of good solutions, such as an easy way to have an npc automatically find and buff a pet, etc...

Is there some kind of guide for configuring DBD to work, other than the "easy way"?

**Akkadius** · #10 02-07-2015, 08:42 PM

i already said you don't need to downgrade MySQL from 64 bit. I don't know how I could say this any differently.

Compile in 32 bit Relwithdebinfo Perl 5.12.3 and make sure your 64 is deleted from root path. Use 32 bit dependencies and you should be fine. Otherwise your doing something wrong.

Riklin · #11 02-07-2015, 10:04 PM

OK. Trying exactly that. Removing 32bit MySQL and installing 64bit MySQL, then loading from a backup source file...

I'll let you know how it goes...

Thanks again,
Riklin

Riklin · #12 02-08-2015, 12:05 AM

SUCCESS! Akkadius, as always you were right...

I blanked out the EQ directory and followed the guide exactly. No shortcuts, word for word. While doing this I realized my error. When I was changing the dependencies back and forth between 64bit and 32bit, I FORGOT TO MANUALLY COPY THE LUA DLL FILE!

So when everything was working in 32 bit, that LUA dll file was the 64 bit version.

Thank you for your help. Now to see copy in the DBD::MySQL stuff and hope for the best...

Thank you again Akkadius for your patience and stubbornness!

You were right!

Riklin