So I've built a project on my 32 bit box, and am now trying to deploy to a 64bit windows 2008 server. I got an error that indicates it's a dll issue built for 32bit trying to run on 64bit.
So my main question is whether I need to try to rebuild the project file provided here? Or the actual Oracle libdb45.dll, or all of them?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just a follow-up note, I have opened up the source code provided in this project (in VS2008), and receive the following error:
Inconsistent accessibility: parameter type 'out BerkeleyDb.DB_SEQUENCE_STAT*' is less accessible than delegate 'BerkeleyDb.DB_SEQUENCE.StatFcn'
I actually get this error about 40+ times for multiple structs, etc...it seems that they just need the same "public" accessor, but I haven't really looked through the code all that much to see if this would present a problem or not...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Likely you need to rebuild all of them. But I have no access to a 64bit machine, so I was never able to test if the .NET wrapper actually works properly with the 64bit libdb45.dll library. The issue basically is that the .NET binding must pick the precise offsets in the structs returned by libdb to call into the proper function pointers. This I have carefully figured out for 32bits, but never had a chance to check against 64bit libraries.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to get the file vis CVS, and it got rid of the error, but building didn't seem to build the Utils45 or Serialization libraries....just the libdb_dotnet dll...still fussing around with that though...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just had someone with access to a 64 bit machine debug the library, and it looks as if we got it going for 64bit platforms. The main point was to translate all occurrences of time_t and size_t types in the C library to IntPtr instances in the .NET wrapper.
So, if you update to current CVS, the library should work on both, 32bit and 64bit Windows platforms, from the bit of testing that was performed. No rebuild should be needed, as the JIT compiler automatically adjust IntPtr to the correct platform size.
Karl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So I've built a project on my 32 bit box, and am now trying to deploy to a 64bit windows 2008 server. I got an error that indicates it's a dll issue built for 32bit trying to run on 64bit.
So my main question is whether I need to try to rebuild the project file provided here? Or the actual Oracle libdb45.dll, or all of them?
Thanks!
Just a follow-up note, I have opened up the source code provided in this project (in VS2008), and receive the following error:
Inconsistent accessibility: parameter type 'out BerkeleyDb.DB_SEQUENCE_STAT*' is less accessible than delegate 'BerkeleyDb.DB_SEQUENCE.StatFcn'
I actually get this error about 40+ times for multiple structs, etc...it seems that they just need the same "public" accessor, but I haven't really looked through the code all that much to see if this would present a problem or not...
Could you check out from current CVS and try that. I think this might be resolved in the current source.
Likely you need to rebuild all of them. But I have no access to a 64bit machine, so I was never able to test if the .NET wrapper actually works properly with the 64bit libdb45.dll library. The issue basically is that the .NET binding must pick the precise offsets in the structs returned by libdb to call into the proper function pointers. This I have carefully figured out for 32bits, but never had a chance to check against 64bit libraries.
I was able to get the file vis CVS, and it got rid of the error, but building didn't seem to build the Utils45 or Serialization libraries....just the libdb_dotnet dll...still fussing around with that though...
I just did a checkout and it built everything OK.
I just had someone with access to a 64 bit machine debug the library, and it looks as if we got it going for 64bit platforms. The main point was to translate all occurrences of time_t and size_t types in the C library to IntPtr instances in the .NET wrapper.
So, if you update to current CVS, the library should work on both, 32bit and 64bit Windows platforms, from the bit of testing that was performed. No rebuild should be needed, as the JIT compiler automatically adjust IntPtr to the correct platform size.
Karl