1. wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by TheDcoder Mar 05, 2018
- 1415 views
Hello,
Been a while since I had looked at Euphoria. I am trying to get wxEuphoria working and for some reason the library won't load at all... I have confirmed that libwxeu.dll is present in the path by using the where command:
Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. C:\Users\TheDcoder>where libwxeu.dll E:\Software\Euphoria\bin\libwxeu.dll C:\Users\TheDcoder>
I also peeked into the code and I can see that open_dll is returning 0 hence the error message. According to the manual, 0 is returned when open_dll cannot find the .dll
Feeling puzzled... does anyone have any useful advice for me?
2. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by ghaberek (admin) Mar 05, 2018
- 1423 views
What version of Euphoria are you running?
Where did you download wxEuphoria from?
Are you using pre-built libraries or did you build them yourself?
-Greg
3. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by irv Mar 05, 2018
- 1406 views
Could this be a 32 vs 64-bit problem? They aren't on speaking terms, you know:)
4. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by ChrisB (moderator) Mar 06, 2018
- 1393 views
Hi
Yes, this would be my suspicion too. Remember a return value of 0 from open_dll does not mean it cannot find it, it means it cannot load the library (which might mean it cannot find it too, but cannot find is a subset of cannot load)
This is such a common issue, that this should be a sticky referral to a wiki page, or a usingeuphoria article.
In fact, feel free to add to this wiki page http://openeuphoria.org/wiki/view/Compatability%20issues.wc
Cheers
Chris
5. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by irv Mar 06, 2018
- 1360 views
Here's an attempt to determine 32/64 bit dlls programatically. I've tested it with a few, it seems to work. Needs to be run from the folder where the dll lives:
constant dllname = "atl.dll" -- or whatever; include std/io.e include std/filesys.e include std/console.e include std/sequence.e if not file_exists(dllname) then display("[] can't be found!",{dllname}) abort(1) end if object buffer = {} atom fn = open(dllname,"rb") if fn then buffer = get_bytes(fn,1000) integer x = match({80,69},buffer) if find('L',buffer[x..$]) = 5 then display("x86 (32-bit)") end if if match({#64,#86},buffer[x..$]) = 5 then display("x64 (64-bit)") end if else display("Failed to open []",{dllname}) end if
6. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by ChrisB (moderator) Mar 06, 2018
- 1328 views
Hi
Useful.
What would also be nice would be to tell the user whether the interpreter is running in 32 or 64 bits, for instance Phix has machine_bits().
I guess you could put a known 32 bit dll and a known 64 bit dll in the folder, and attempt to open them both. Success on one would indicate the architecture of the interpreter.
Chris
7. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by ghaberek (admin) Mar 06, 2018
- 1465 views
What would also be nice would be to tell the user whether the interpreter is running in 32 or 64 bits, for instance Phix has machine_bits().
Do you mean like this? We already have ifdef values for these things, and this is precisely how they should be used.
-- Example 3: -- This routine is phix specific. For compatibility with OpenEuphoria the following can be used (copied from builtins\cffi.e): --/* public function machine_bits() ifdef BITS64 then return 64 elsedef return 32 end ifdef end function --*/
I guess you could put a known 32 bit dll and a known 64 bit dll in the folder, and attempt to open them both. Success on one would indicate the architecture of the interpreter.
No please don't do this. Shared libraries should not be handled this way. Don't let the interpreter decide which architecture library to attempt to load.
Put libraries of the same architecture in C:\Euphoria\bin next to the interpreter and set up multiple environments, or store and load them in your project directory like this:
bin\
32\
library.dll
64\
library.dll
ifdef BITS64 then constant LIB_PATH = "bin/64" elsedef constant LIB_PATH = "bin/32" end ifdef atom library = open_dll( LIB_PATH & "/library.dll" )
-Greg
8. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by ChrisB (moderator) Mar 06, 2018
- 1315 views
Hi
Eu doesn't have machine_bits(), BITS64, or BITS32
Cheers
Chris
9. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by irv Mar 06, 2018
- 1315 views
Hi
Eu doesn't have machine_bits(), BITS64, or BITS32
Cheers
Chris
Eu 4.1 does:
4.4.3.3 Architecture Definitions
Chip architecture:
X86
X86_64
ARM
Size of pointers and euphoria objects. This information can be derived from the chip architecture, but is provided for convenience.
BITS32
BITS64
Size of long integers. On Windows, long integers are always 32 bits. On other platforms, long integers are the same size as pointers. This information can also be derived from a combination of other architecture and platform ifdefs, but is provided for convenience.
LONG32
LONG64
10. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by ghaberek (admin) Mar 06, 2018
- 1323 views
Eu doesn't have machine_bits(), BITS64, or BITS32
What?!
Euphoria 4.1, the only version to provide anything but 32-bit architecture, includes the following in its manual:
Chip architecture:
- X86
- X86_64
- ARM
Size of pointers and euphoria objects. This information can be derived from the chip architecture, but is provided for convenience.
- BITS32
- BITS64
Size of long integers. On Windows, long integers are always 32 bits. On other platforms, long integers are the same size as pointers. This information can also be derived from a combination of other architecture and platform ifdefs, but is provided for convenience.
- LONG32
- LONG64
I always write my architecture ifdef statements as shown below. Doing it this way means the code will always fall back to 32-bit on Euphoria 4.0.
ifdef BITS64 then -- 64-bit Euphoria 4.1 elsedef -- 32-bit Euphoria 4.x end ifdef
Now, you're right that Euphoria doesn't include machine_bits() like Phix, but that's why I linked to the Phix documentation.
Pete provides a specific example (that I copied above) on how to provide machine_bits() in a Phix-compatible way on Euphoria.
-Greg
11. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by petelomax Mar 06, 2018
- 1289 views
Here's an attempt to determine 32/64 bit dlls programatically. I've tested it with a few, it seems to work. Needs to be run from the folder where the dll lives:
constant dllname = "atl.dll" -- or whatever; include std/io.e include std/filesys.e include std/console.e include std/sequence.e if not file_exists(dllname) then display("[] can't be found!",{dllname}) abort(1) end if object buffer = {} atom fn = open(dllname,"rb") if fn then buffer = get_bytes(fn,1000) integer x = match({80,69},buffer) if find('L',buffer[x..$]) = 5 then display("x86 (32-bit)") end if if match({#64,#86},buffer[x..$]) = 5 then display("x64 (64-bit)") end if else display("Failed to open []",{dllname}) end if
Looks about right to me.
I would however test for buffer[#80..#83]={'P','E',0,0} rather than that (equivalent) match, and that buffer[#84..#85]={#4C,#01} is 32bit and buffer[#84..#85]={#64,#86} is 64bit.
For a linux equivalent, if a .so file starts with {#7F,'E','L','F',#01} it is 32 bit and if {#7F,'E','L','F',#02} it is 64 bit.
Be warned I didn't actually test any of that though.
Pete
12. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by irv Mar 06, 2018
- 1295 views
The PE is at a different offset from start in 32 and 64 bits, so we need to search for it. I think the offset may vary depending on what compiler was used to build the dll, also.
There seems to be no guarantee that the byte following the L on 32-bit dlls is going to be 01, although all I've tried so far are.
The {#64,#86} seems to be consistent for 64-bit dlls.
Thanks for the Linux equivalent.
Anybody want to try this with a dll built by a Euphoria program?
13. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by ChrisB (moderator) Mar 06, 2018
- 1277 views
Eu doesn't have machine_bits(), BITS64, or BITS32
What?!
Euphoria 4.1, the only version to provide anything but 32-bit architecture, includes the following in its manual:
Chip architecture:
- X86
- X86_64
- ARM
Size of pointers and euphoria objects. This information can be derived from the chip architecture, but is provided for convenience.
- BITS32
- BITS64
Size of long integers. On Windows, long integers are always 32 bits. On other platforms, long integers are the same size as pointers. This information can also be derived from a combination of other architecture and platform ifdefs, but is provided for convenience.
- LONG32
- LONG64
I always write my architecture ifdef statements as shown below. Doing it this way means the code will always fall back to 32-bit on Euphoria 4.0.
ifdef BITS64 then -- 64-bit Euphoria 4.1 elsedef -- 32-bit Euphoria 4.x end ifdef
Now, you're right that Euphoria doesn't include machine_bits() like Phix, but that's why I linked to the Phix documentation.
Pete provides a specific example (that I copied above) on how to provide machine_bits() in a Phix-compatible way on Euphoria.
-Greg
Heh heh, why would I RTFM Greg, when I have you to so eloquently correct me? 
Cheers
Chris
14. Re: wxEuphoria cannot load library even if libwxeu.dll is present in path
- Posted by petelomax Mar 06, 2018
- 1246 views
The PE is at a different offset from start in 32 and 64 bits, so we need to search for it. I think the offset may vary depending on what compiler was used to build the dll, also.
Yep, my bad. All the ones I build (/phix builds) are at #80, but it took me no time at all to find a couple at #E8 and #F8.
I'd still say x[x..x+5]={'P','E',0,0,#4C,#01} or similar is the right test though, see below.
EDIT: actually, the right thing to be done is study what demo\pGUI\filedump.exw does, as that has over the years been through a fair bit of testing.
There seems to be no guarantee that the byte following the L on 32-bit dlls is going to be 01, although all I've tried so far are.
The {#64,#86} seems to be consistent for 64-bit dlls.
The relevant official definitions, as researched/collected by me many moons ago (only two of which we care about), are:
constant -- IMAGE_FILE_MACHINE_UNKNOWN = 0x0000 IMAGE_FILE_MACHINE_I386 = 0x014c, -- Intel 386 or later -- = 0x014d, -- Intel 486 or better (deprecated) -- = 0x014e, -- Intel Pentium or better (deprecated) -- IMAGE_FILE_MACHINE_R3000 = 0x0162, -- MIPS little-endian, 0x160 big-endian -- IMAGE_FILE_MACHINE_R4000 = 0x0166, -- MIPS little-endian -- IMAGE_FILE_MACHINE_R10000 = 0x0168, -- MIPS little-endian -- IMAGE_FILE_MACHINE_WCEMIPSV2 = 0x0169, -- MIPS little-endian WCE v2 -- IMAGE_FILE_MACHINE_ALPHA = 0x0184, -- Alpha_AXP -- IMAGE_FILE_MACHINE_SH3 = 0x01a2, -- Hitachi SH3 little-endian -- IMAGE_FILE_MACHINE_SH3DSP = 0x01a3, -- Hitachi SH3 DSP -- IMAGE_FILE_MACHINE_SH3E = 0x01a4, -- Hitachi SH3E little-endian -- IMAGE_FILE_MACHINE_SH4 = 0x01a6, -- Hitachi SH4 little-endian -- IMAGE_FILE_MACHINE_SH5 = 0x01a8, -- Hitachi SH5 -- IMAGE_FILE_MACHINE_ARM = 0x01c0, -- ARM Little-Endian -- IMAGE_FILE_MACHINE_THUMB = 0x01c2, -- ARM or Thumb ("interworking") -- IMAGE_FILE_MACHINE_ARMNT = 0x01c4, -- ARMv7 (or higher) Thumb mode only -- IMAGE_FILE_MACHINE_ARM64 = 0xaa64, -- ARMv8 in 64-bit mode -- IMAGE_FILE_MACHINE_AM33 = 0x01d3, -- Matsushita AM33 -- IMAGE_FILE_MACHINE_POWERPC = 0x01f0, -- IBM PowerPC little-endian -- IMAGE_FILE_MACHINE_POWERPCFP = 0x01f1, -- IBM Power PC with floating point support -- IMAGE_FILE_MACHINE_IA64 = 0x0200, -- Intel 64 (Itanium) -- IMAGE_FILE_MACHINE_MIPS16 = 0x0266, -- MIPS16 -- IMAGE_FILE_MACHINE_ALPHA64 = 0x0284, -- ALPHA64 (aka IMAGE_FILE_MACHINE_AXP64) -- IMAGE_FILE_MACHINE_MIPSFPU = 0x0366, -- MIPS with FPU -- IMAGE_FILE_MACHINE_MIPSFPU16 = 0x0466, -- MIPS16 wth FPU -- IMAGE_FILE_MACHINE_TRICORE = 0x0520, -- Infineon -- IMAGE_FILE_MACHINE_CEF = 0x0CEF, -- IMAGE_FILE_MACHINE_EBC = 0x0EBC, -- EFI Byte Code IMAGE_FILE_MACHINE_AMD64 = 0x8664, -- AMD64 (K8) (aka IMAGE_FILE_MACHINE_X64) -- IMAGE_FILE_MACHINE_M32R = 0x9041, -- Mitsubishi M32R little-endian -- IMAGE_FILE_MACHINE_CEE = 0xC0EE,
So as I understand it, if that next byte ain't #01, it won't load. Thinking on it, that 14d/e suggests perhaps such a routine should only really be used after a lib has failed to load?
Thanks for the Linux equivalent.
That was always meant to be the more important/useful bit of my post.
Regards,
Pete
