1. Errors using multiple euphoria shared libraries
- Posted by raseu May 24, 2012
- 1012 views
eui Linux Version (Linux Ubuntu)
Euphoria Interpreter v4.1.0 development
32-bit Linux, Using System Memory
Revision Date: unknown, Id: 0:unknown
eui windows Version
Euphoria Interpreter v4.1.0 development
32-bit Windows, Using System Memory
Revision Date: unknown, Id: 0:unknown
Using the above version of euphoria under linux, there are issues regarding the
execution of exported routines when multiple euphoria libraries are loaded
within a program.
Given the following two programs compiled as euphoria shared libraries
--// compile as shared library --// --// $ euc -so lib1.e include std/os.e export procedure lib1_export() printf(1, "inside lib1_export()\n") end procedure
and
--// compile as shared library --// --// $ euc -so lib2.e include std/os.e export procedure lib2_export() printf(1, "inside lib2_export()\n") end procedure
and the following test program
--// run --// --// $ eui test.ex include std/dll.e include std/machine.e ifdef WINDOWS then constant lib1 = open_dll("lib1.dll") constant lib2 = open_dll("lib2.dll") elsedef constant lib1 = open_dll("lib1.so") constant lib2 = open_dll("lib2.so") end ifdef constant lib1_export = define_c_proc(lib1, "lib1_export", {}) constant lib2_export = define_c_proc(lib2, "lib2_export", {}) ? { lib1, lib2, lib1_export, lib2_export } c_proc(lib1_export, {}) c_proc(lib2_export, {})
Windows provides the following output as expected
{7733248,31588352,28,29}
inside lib1_export()
inside lib2_export()
Linux provides the following undesired output
{139554136,139234544,19,20}
inside lib1_export()
inside lib1_export()
Is this a euphoria issue under linux?, or an issue with the way
linux loads shared libraries with all symbols exported as default?
I am guessing that because both shared libraries under linux share
a lot of underlying euphoria library routines that the system cannot
resolve linkage definitions correctly?
2. Re: Errors using multiple euphoria shared libraries
- Posted by mattlewis (admin) May 24, 2012
- 984 views
Is this a euphoria issue under linux?, or an issue with the way
linux loads shared libraries with all symbols exported as default?
I am guessing that because both shared libraries under linux share
a lot of underlying euphoria library routines that the system cannot
resolve linkage definitions correctly?
It does not appear to be a euphoria interpreter issue. I wrote some C code to test:
// lib1.h void lib1_export(); // lib2.h void lib2_export(); // lib.c // gcc lib.c -l1 -l2 -o test #include "lib1.h" #include "lib2.h" int main(){ lib1_export(); lib2_export(); return 0; }
I get the same result. If I switch the linking order libraries, then both calls go to lib2. I added define_c_var() calls to see what was being reported for lib1_export and lib2_export, and the pointers returned were different, however the memory pointed to was identical (a jump table?).
Also:
$ nm lib1.so | grep lib 0000000000011d20 T _1lib1_export 0000000000016ae0 T _3std_library_address 0000000000011d20 T lib1_export $ nm lib2.so | grep lib 0000000000011d20 T _1lib2_export 0000000000016ae0 T _3std_library_address 0000000000011d20 T lib2_export
I guess that they aren't being relocated properly when linked. I built simple shared libs from source:
// lib1.c gcc -shared -fPIC lib1.c -o lib1.so #include <stdio.h> void _1lib1_export(){ puts("inside C lib1_export"); } void lib1_export() __attribute__ ((alias ("_1lib1_export"))); // lib2.c // gcc -shared -fPIC lib2.c -o lib2.so #include <stdio.h> void _1lib1_export(){ puts("inside C lib1_export"); } void lib1_export() __attribute__ ((alias ("_1lib1_export")));
Those worked as expected, so I'm not sure why the euphoria translated libraries aren't working...
Matt