1. open_dll on Linux?
- Posted by jaygade Sep 09, 2009
- 1587 views
Are there any known issues with open_dll() on Linux?
I'm running Xubuntu 9.04
Linux ubuntu 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 19:25:34 UTC 2009 x86_64 GNU/Linuxand
Euphoria Interpreter 4.0.0 beta 2 (r2670) for Linux Using System Memory
Attempting:
eui callc.exuFrom the demos/unix directory. Paths are set. Sanity.ex passes. I made sure that callc.exu has the full paths to the .so files and that said files actually exist.
The program runs but reports that it cannot find the .so files and only prints out the Euphoria results. No ex.err or other error messages.
2. Re: open_dll on Linux?
- Posted by jeremy (admin) Sep 09, 2009
- 1558 views
Is the DLL the 64bit version? If so, you'll have to get/compile a 32bit version of the shared library 
Jeremy
3. Re: open_dll on Linux?
- Posted by mattlewis (admin) Sep 09, 2009
- 1601 views
Are there any known issues with open_dll() on Linux?
Not that I'm aware of.
Attempting:
eui callc.exuFrom the demos/unix directory. Paths are set. Sanity.ex passes. I made sure that callc.exu has the full paths to the .so files and that said files actually exist.
The program runs but reports that it cannot find the .so files and only prints out the Euphoria results. No ex.err or other error messages.
What does ldd say about the .so files? I'm not on a Linux box right now, though I will be in a while. I'll check again on my box.
Matt
4. Re: open_dll on Linux?
- Posted by mattlewis (admin) Sep 09, 2009
- 1548 views
Works for me:
demo/unix$ eui callc.exu > string copy test: Hello Euphoria > malloc test: 169 > sin test: 0.8414709848 0.8414709848 > printf test: Here are 4 numbers: 111, 222.222, 333, 4.444444e+02
Matt
5. Re: open_dll on Linux?
- Posted by jaygade Sep 09, 2009
- 1562 views
Okay, I'll check it later tonight...
I thought about the fact that the .so files may be 64 bit versions which would kind of hose everything up. I'm not about to compile a 32 bit copy of everything.
6. Re: open_dll on Linux?
- Posted by jaygade Sep 09, 2009
- 1526 views
Works for me:
demo/unix$ eui callc.exu > string copy test: Hello Euphoria > malloc test: 169 > sin test: 0.8414709848 0.8414709848 > printf test: Here are 4 numbers: 111, 222.222, 333, 4.444444e+02
Matt
This is what I get too, except at the top the program reports that it cannot open the shared libraries.
7. Re: open_dll on Linux?
- Posted by jeremy (admin) Sep 09, 2009
- 1546 views
Okay, I'll check it later tonight...
I thought about the fact that the .so files may be 64 bit versions which would kind of hose everything up. I'm not about to compile a 32 bit copy of everything.
I'm sure this is the case and yes, it's a real problem
Jeremy
8. Re: open_dll on Linux?
- Posted by mattlewis (admin) Sep 09, 2009
- 1518 views
Okay, I'll check it later tonight...
I thought about the fact that the .so files may be 64 bit versions which would kind of hose everything up. I'm not about to compile a 32 bit copy of everything.
No, it should be handled by your package manager, once we get packages built for distribution. I've no idea how the linking decides which version to load, but proper dependencies would at least ensure that the right libraries are there.
What does ldd say about eui? On my 32bit system:
$ ldd eui
linux-gate.so.1 => (0xb7f9d000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f57000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7f53000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7f3c000)
libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7f23000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dc0000)
/lib/ld-linux.so.2 (0xb7f9e000)
Matt
9. Re: open_dll on Linux?
- Posted by jeremy (admin) Sep 09, 2009
- 1539 views
No, it should be handled by your package manager, once we get packages built for distribution. I've no idea how the linking decides which version to load, but proper dependencies would at least ensure that the right libraries are there.
Not really. Here's the problem:
libm = open_dll("/usr/lib/libm.so")
That fails on any 64bit OS. libm.so is a 64bit version.
eui will work fine, but any open_dll() will have issues. For instance:
open_dll("libmysqlclient.so")
will fail on a 64bit os. You have to install the 32bit versions of libmysqlclient.so, then Euphoria can open it.
Jeremy
10. Re: open_dll on Linux?
- Posted by jimcbrown (admin) Sep 09, 2009
- 1515 views
Okay, I'll check it later tonight...
I thought about the fact that the .so files may be 64 bit versions which would kind of hose everything up. I'm not about to compile a 32 bit copy of everything.
No, it should be handled by your package manager, once we get packages built for distribution. I've no idea how the linking decides which version to load, but proper dependencies would at least ensure that the right libraries are there.
What does ldd say about eui? On my 32bit system:
$ ldd eui
linux-gate.so.1 => (0xb7f9d000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f57000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7f53000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7f3c000)
libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7f23000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dc0000)
/lib/ld-linux.so.2 (0xb7f9e000)
Matt
On a 64bit system:
$ ldd ./eui
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib32/libm.so.6 (0xf7ef2000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7eee000)
libresolv.so.2 => /lib32/libresolv.so.2 (0xf7eda000)
libnsl.so.1 => /lib32/libnsl.so.1 (0xf7ec2000)
libc.so.6 => /lib32/libc.so.6 (0xf7d73000)
/lib/ld-linux.so.2 (0xf7f2c000)
11. Re: open_dll on Linux?
- Posted by jimcbrown (admin) Sep 09, 2009
- 1522 views
open_dll("libmysqlclient.so")
will fail on a 64bit os. You have to install the 32bit versions of libmysqlclient.so, then Euphoria can open it.
Jeremy
I think that is essentially correct, but I'm not sure the automatic (automagic?) changing from lib to lib32 applies to just shared linking or to full dynamic linking in dlopen().
If not, we'll need to explicitly include /lib32 and /usr/lib32 and /usr/share/lib32 and /usr/local/lib32 and /usr/local/share/lib32 in the search.
Not really. Here's the problem:
libm = open_dll("/usr/lib/libm.so")
That fails on any 64bit OS. libm.so is a 64bit version.
eui will work fine, but any open_dll() will have issues.
I am not 100% sure, but I think the fact that the path is hardcoded causes problems as it overrides the automatic conversion of /usr/lib into /usr/lib32 for 32bit apps. So we'll always end up opening the wrong 64bit dll. (Of course, the automatic conversion may not apply to dlopen(), and thus not to open_dll(), anyways.)
12. Re: open_dll on Linux?
- Posted by jeremy (admin) Sep 09, 2009
- 1520 views
I am not 100% sure, but I think the fact that the path is hardcoded causes problems as it overrides the automatic conversion of /usr/lib into /usr/lib32 for 32bit apps. So we'll always end up opening the wrong 64bit dll. (Of course, the automatic conversion may not apply to dlopen(), and thus not to open_dll(), anyways.)
Well, this is where it begins to get more tricky. Not all systems use /usr/lib32 and /usr/lib. For instance, openeuphoria.org has /lib and /lib64, /usr/lib and /usr/lib64.
Oh, and they have a bare number of libs installed for the 32bit stuff. For instance, no libpcre, libmysqlclient, etc... but those are installed for the lib64.
Jeremy
13. Re: open_dll on Linux?
- Posted by mattlewis (admin) Sep 09, 2009
- 1493 views
No, it should be handled by your package manager, once we get packages built for distribution. I've no idea how the linking decides which version to load, but proper dependencies would at least ensure that the right libraries are there.
Not really. Here's the problem:
libm = open_dll("/usr/lib/libm.so")
That fails on any 64bit OS. libm.so is a 64bit version.
Yes, I was really referring to the need to compile 32bit versions.
Matt
14. Re: open_dll on Linux?
- Posted by mattlewis (admin) Sep 09, 2009
- 1491 views
Yeah, hard coding the paths in general is a bad idea. Beyond the architecture, what if the user built something himself and installed to /usr/local/lib instead of /usr/lib?
Does the demo work correctly (on 64bit architectures) if we just supply the file name?
Matt
15. Re: open_dll on Linux?
- Posted by jaygade Sep 09, 2009
- 1483 views
Doing a quick Google, it looks like there might be a package which includes common 32-bit libs already (at least for Ubuntu).
I'll still have to wait until later this evening to look into it further since I don't have the machine in question handy.
Thanks for the responses. We'll probably want to make a note in the Wiki and/or in the docs once this is resolved.
16. Re: open_dll on Linux?
- Posted by mattlewis (admin) Sep 09, 2009
- 1522 views
Doing a quick Google, it looks like there might be a package which includes common 32-bit libs already (at least for Ubuntu).
I'll still have to wait until later this evening to look into it further since I don't have the machine in question handy.
Thanks for the responses. We'll probably want to make a note in the Wiki and/or in the docs once this is resolved.
Yeah, it's probably already installed, since eui runs at all. The hard coding of the path in the demo is probably the issue, not allowing the linker to do its job (I hope).
Matt
17. Re: open_dll on Linux?
- Posted by jacques_desch Sep 09, 2009
- 1484 views
On fedora 11 64bit, It works if I replace libm.so by libm.so.6
Jacques
18. Re: open_dll on Linux?
- Posted by jeremy (admin) Sep 09, 2009
- 1481 views
On fedora 11 64bit, It works if I replace libm.so by libm.so.6
That's another common problem on varying Linux installs. For instance, openeuphoria has only the full version numbered .so files, they don't do symlinks up to the simple .so file.
open_dll has been changed a bit to make this a bit more easy to deal with. You can no do:
open_dll({"libm.so", "libm.so.6", "libm.so.6.0", "libm.so.6.0.0" })
I was thinking of making it a bit smarter yet, for instance:
open_dll("mysqlclient", { 6, 7, 8 })
From that it would realize that on Unix systems, library mysqlclient needs a lib prepended onto it. Further, that so should be used (on OSX it would use dylib and on Windows, dll). Then, 6, 7 and 8 are version numbers that your app is compatible with. So, it would try the most common options first, i.e. libmysqlclient.so, libmysqlclient.so.6, libmysqlclient.so.7, ..., libmysqlclient.so.6.0, ...
Jeremy
19. Re: open_dll on Linux?
- Posted by ghaberek (admin) Sep 09, 2009
- 1508 views
I was thinking of making it a bit smarter yet, for instance:
open_dll("mysqlclient", { 6, 7, 8 })
From that it would realize that on Unix systems, library mysqlclient needs a lib prepended onto it. Further, that so should be used (on OSX it would use dylib and on Windows, dll). Then, 6, 7 and 8 are version numbers that your app is compatible with. So, it would try the most common options first, i.e. libmysqlclient.so, libmysqlclient.so.6, libmysqlclient.so.7, ..., libmysqlclient.so.6.0, ...
A problem with this, is that libraries have "a version number that is incremented whenever the interface changes." Such that, from one version number to the next, one will likely encounter partial, if not complete, incompatibility.
-Greg
20. Re: open_dll on Linux?
- Posted by jeremy (admin) Sep 09, 2009
- 1476 views
A problem with this, is that libraries have "a version number that is incremented whenever the interface changes." Such that, from one version number to the next, one will likely encounter partial, if not complete, incompatibility.
I guess that my experience has been that they typically add functionality but keep dynamic backward compatibility. There has been a few that have not been compatible. When you develop your library wrapping libxyz, you should know that your .e file is compatible with 1, 2 and 3 but 4 introduces a change. From this type of synario, you could do something such as:
atom dll = open_dll("mysqlclient", { 1, 2, 3 }) atom api_ver = 1 if dll = 0 then dll = open_dll("mysqlclient", { 4, 5, 6 }) api_ver = 2 end if
Jeremy
21. Re: open_dll on Linux?
- Posted by ChrisB (moderator) Sep 09, 2009
- 1424 views
Hi
In my experience, 32 bit euphoria can't access 64 bit libraries. You need to
1. run ldd on the libraries you have installed, that the eu program is asking for. 2. install the required libraries on a 32 bit system (if you don't have a 32 bit box, then install virtual box - its easier to install on a windows machine) 3. Copy the files to /usr/lib and /usr/local/lib (overkill - perhaps) 4. If the the eu program requires a specific name, create a symlink in /usr/lib pointing to the lib in /usr/local/lib 5. try the programs again, if still not working, run ldd again, to find whats missing.
Its a complete utter pain, and this and installing printers on Linux is putting me off more and more and more, and if it wasn't the security and reliable networking I would have moved over fully to Windows by now.
Chris
22. Re: open_dll on Linux?
- Posted by jimcbrown (admin) Sep 09, 2009
- 1444 views
Hi
In my experience, 32 bit euphoria can't access 64 bit libraries. You need to
<snip>
Its a complete utter pain<snip>
Chris
Well, that is doing it the hard way. Most 64bit distros are multilib, and you can just ask the package manager to install the 32bit versions of the libraries and their dependencies.
23. Re: open_dll on Linux?
- Posted by jacques_desch Sep 09, 2009
- 1393 views
On fedora 11 64bit, It works if I replace libm.so by libm.so.6
That's another common problem on varying Linux installs. For instance, openeuphoria has only the full version numbered .so files, they don't do symlinks up to the simple .so file.
open_dll has been changed a bit to make this a bit more easy to deal with. You can no do:
open_dll({"libm.so", "libm.so.6", "libm.so.6.0", "libm.so.6.0.0" })
I was thinking of making it a bit smarter yet, for instance:
open_dll("mysqlclient", { 6, 7, 8 })
From that it would realize that on Unix systems, library mysqlclient needs a lib prepended onto it. Further, that so should be used (on OSX it would use dylib and on Windows, dll). Then, 6, 7 and 8 are version numbers that your app is compatible with. So, it would try the most common options first, i.e. libmysqlclient.so, libmysqlclient.so.6, libmysqlclient.so.7, ..., libmysqlclient.so.6.0, ...
Jeremy
Please don't over do with open_dll() that kind of problems should be solved by installation scripts creating symbolic link as needed. Euphoria should not try to solve all linux quirks.
What I did to solved the problem in fedora 11 was no big deal. I just used find command to locate libm* then change the source according to my found results, but I would have better done by creating a symbolic link, which is not a big deal too.
I think its better that way than making euphoria interpreter too complex.
Jacques
24. Re: open_dll on Linux?
- Posted by jeremy (admin) Sep 09, 2009
- 1442 views
Please don't over do with open_dll() that kind of problems should be solved by installation scripts creating symbolic link as needed. Euphoria should not try to solve all linux quirks.
The problem is a lot of programs may be installed in user land and not have the ability to alter /usr/lib, /lib symlinks.
What I did to solved the problem in fedora 11 was no big deal. I just used find command to locate libm* then change the source according to my found results, but I would have better done by creating a symbolic link, which is not a big deal too.
That is, if you have the source. What about a bound or translated application that needs to run on a wide variety of Linux distros? Or source that you want to easily work on Windows, OS X, SunOS, FreeBSD, NetBSD, OpenBSD, Fedora, Debian, Gentoo and ArchLinux w/o change? (euWeb will work on all those platforms w/o change BTW).
I think its better that way than making euphoria interpreter too complex.
Yes, simplicity is king, there has to be a good balance between functionality and simplicity though. Where that is, is decided all the time, such as this thread with open_dll(). I'm not sure where the balance is. The changes I suggested, however, would affect a normal open_dll() call. You could still do open_dll("libm.so") w/no issue, or if you wanted to produce a binary w/o source, you could make things more platform independent via open_dll("m", { 1, 2, 3 })
Jeremy
25. Re: open_dll on Linux?
- Posted by jaygade Sep 09, 2009
- 1424 views
OT: For what it's worth, I've had fewer problems installing printers on Linux than on Windows in the past 4 or 5 years.
Before that, yeah, it was a pain though.
Note: I'm not a Linux guru but I've been playing with it off and on since 1996 or so.
26. Re: open_dll on Linux?
- Posted by jacques_desch Sep 09, 2009
- 1419 views
(euWeb will work on all those platforms w/o change BTW).
OT: euWeb? firts news for me. Did I miss something or is this some of your idea you're working on.
Although I'm not found of WEB OS it would be a curiousity to explore.
Jacques
27. Re: open_dll on Linux?
- Posted by jeremy (admin) Sep 09, 2009
- 1414 views
(euWeb will work on all those platforms w/o change BTW).
OT: euWeb? firts news for me. Did I miss something or is this some of your idea you're working on.
Although I'm not found of WEB OS it would be a curiousity to explore.
euWeb is the name given to the software that runs OpenEuphoria.org and is slowly expanding. Nothing more. Sorry to get your hopes up
Jeremy
28. Re: open_dll on Linux?
- Posted by euphoric (admin) Sep 09, 2009
- 1440 views
euWeb is the name given to the software that runs OpenEuphoria.org and is slowly expanding. Nothing more. Sorry to get your hopes up
Hopefully you'll have YUI integration soon. Then we can start thinking "WebOS." 
Forked into: YUI and euWeb
29. Re: open_dll on Linux?
- Posted by jaygade Sep 09, 2009
- 1383 views
- Last edited Sep 10, 2009
Okay, got it figured out.
Here's the output of ldd eui on my system:
ldd eui linux-gate.so.1 => (0xf7eec000) libm.so.6 => /lib32/libm.so.6 (0xf7ead000) libdl.so.2 => /lib32/libdl.so.2 (0xf7ea9000) libresolv.so.2 => /lib32/libresolv.so.2 (0xf7e92000) libnsl.so.1 => /lib32/libnsl.so.1 (0xf7e79000) libc.so.6 => /lib32/libc.so.6 (0xf7d16000) /lib/ld-linux.so.2 (0xf7eed000)
Now, when I edit the program to open_dll("libc.so") and open_dll("libm.so") I still get the error messages even though the program output still seems correct.
When I edit the program to open_dll("libc.so.6") and open_dll("libm.so.6") then I get no error messages. The linker apparently finds the correct lib32 versions of the files.
I'm going to try opening a different library (one not already linked to the eui executable) and see what happens. Then I'll edit this post here.
30. Re: open_dll on Linux?
- Posted by mattlewis (admin) Sep 09, 2009
- 1412 views
- Last edited Sep 10, 2009
ldd eui linux-gate.so.1 => (0xf7eec000) libm.so.6 => /lib32/libm.so.6 (0xf7ead000) libdl.so.2 => /lib32/libdl.so.2 (0xf7ea9000) libresolv.so.2 => /lib32/libresolv.so.2 (0xf7e92000) libnsl.so.1 => /lib32/libnsl.so.1 (0xf7e79000) libc.so.6 => /lib32/libc.so.6 (0xf7d16000) /lib/ld-linux.so.2 (0xf7eed000)
Some follow up questions:
- Are your 64-bit libraries in /usr/lib or /usr/lib64 ?
- What is the value of LD_LIBRARY_PATH?
- In the 64-bit directory, what's the name of the libc that's there?
Matt
31. Re: open_dll on Linux?
- Posted by jaygade Sep 09, 2009
- 1397 views
- Last edited Sep 10, 2009
ldd eui linux-gate.so.1 => (0xf7eec000) libm.so.6 => /lib32/libm.so.6 (0xf7ead000) libdl.so.2 => /lib32/libdl.so.2 (0xf7ea9000) libresolv.so.2 => /lib32/libresolv.so.2 (0xf7e92000) libnsl.so.1 => /lib32/libnsl.so.1 (0xf7e79000) libc.so.6 => /lib32/libc.so.6 (0xf7d16000) /lib/ld-linux.so.2 (0xf7eed000)
Some follow up questions:
- Are your 64-bit libraries in /usr/lib or /usr/lib64 ?
- What is the value of LD_LIBRARY_PATH?
- In the 64-bit directory, what's the name of the libc that's there?
Matt
I guess my 64-bit libraries are in both /usr/lib64 is a link to /usr/lib. LD_LIBRARY_PATH isn't set. In /usr/lib, I have libc.so and libc.a.
I see in /etc/ld.so.conf includes the files in /etc/ld.so.conf.d which includes lib32asound2.conf libasound2.conf libc.conf x86_64-linux-gnu.conf
None of these seem to point to /lib32. Unless that is somehow hardcoded (or configured) into ldconfig or something? Or /lib/ld-linux.so.2?
32. Re: open_dll on Linux?
- Posted by jaygade Sep 10, 2009
- 1394 views
Okay, so I added a section to callc.exu that opens pcre.so.3 and queries some of its configuration options. And it works on my machine.
I'll see if I can remember how to do svn stuff...
33. Re: open_dll on Linux?
- Posted by jeremy (admin) Sep 10, 2009
- 1379 views
Okay, so I added a section to callc.exu that opens pcre.so.3 and queries some of its configuration options. And it works on my machine.
I'll see if I can remember how to do svn stuff...
Hm, not everyone will have libpcre, which may cause the demo to err. Also, did you know that pcre is built into 4.0? You can use std/regex.e. It's compiled in statically, so no matter where Euphoria is, you have complete regex support.
Jeremy
34. Re: open_dll on Linux?
- Posted by jaygade Sep 10, 2009
- 1293 views
Okay, so I added a section to callc.exu that opens pcre.so.3 and queries some of its configuration options. And it works on my machine.
I'll see if I can remember how to do svn stuff...
Hm, not everyone will have libpcre, which may cause the demo to err. Also, did you know that pcre is built into 4.0? You can use std/regex.e. It's compiled in statically, so no matter where Euphoria is, you have complete regex support.
Jeremy
Well, I'm pretty sure not everyone will have pcre but I was trying to find a library which would be common and had both 32- and 64-bit versions installed.
Any other suggestion would be good...
I know that pcre is supposed to be built-in to 4.0, but it is not one of the libraries which is dynamically linked (as reported by ldd) so I thought that it was a safe bet.
However, looking at my system, even though libpcre was installed, I couldn't find the C header file outside of the Euphoria source tree. Heh.
Another thing which I realized this morning was that I should have for the libc and libm passed a list of likely names to open_dll() as you suggested somewhere up above.
So I'll try and remember to do that tonight.
If someone has another suggestion for a common dynamic lib other than libpcre which Euphoria doesn't link to, I'm interested in it.
One reason I think that the demo was working even though it originally reported not being able to open libc or libm, was that those two libraries are already linked to the eui executable and so c_func and c_proc were still able to resolve them.
Sorry if this is rambling I'm still caffeinating myself.
35. Re: open_dll on Linux?
- Posted by jimcbrown (admin) Sep 10, 2009
- 1304 views
Well, I'm pretty sure not everyone will have pcre but I was trying to find a library which would be common and had both 32- and 64-bit versions installed.
Any other suggestion would be good...
If someone has another suggestion for a common dynamic lib other than libpcre which Euphoria doesn't link to, I'm interested in it.
I have a few ideas:
/lib/libz.so.1
/lib/libncurses.so.5
/lib/libreadline.so.5
Most linux distros will have these installed. libz in particular is a very common library.
36. Re: open_dll on Linux?
- Posted by jaygade Sep 10, 2009
- 1275 views
- Last edited Sep 11, 2009
The only one that I have in both /lib and /lib32 is libncurses.so.5. Is that a pretty good library to use for a demo/test?
I mean, is it ubiquitous enough on most Linux distros as both a 32- and a 64-bit library? I know that it's otherwise a pretty common lib.
37. Re: open_dll on Linux?
- Posted by jimcbrown (admin) Sep 10, 2009
- 1292 views
- Last edited Sep 11, 2009
The only one that I have in both /lib and /lib32 is libncurses.so.5. Is that a pretty good library to use for a demo/test?
I mean, is it ubiquitous enough on most Linux distros as both a 32- and a 64-bit library? I know that it's otherwise a pretty common lib.
I think it should be. Many very common utilities (such as cfdisk) require it.
For reference, versions of eu prior to 2.5 on linux and freebsd required ncurses to be installed and were dynamically linked to it. So at one point in time, eu would not work unless you installed ncurses on your system.
38. Re: open_dll on Linux?
- Posted by jaygade Sep 10, 2009
- 1312 views
- Last edited Sep 11, 2009
The only one that I have in both /lib and /lib32 is libncurses.so.5. Is that a pretty good library to use for a demo/test?
I mean, is it ubiquitous enough on most Linux distros as both a 32- and a 64-bit library? I know that it's otherwise a pretty common lib.
I think it should be. Many very common utilities (such as cfdisk) require it.
For reference, versions of eu prior to 2.5 on linux and freebsd required ncurses to be installed and were dynamically linked to it. So at one point in time, eu would not work unless you installed ncurses on your system.
Okay. I'll try and write up a quick-and-dirty demo which returns the ncurses version, which seems like the easiest routine call that I can see in the lib. Thanks.
39. Re: open_dll on Linux?
- Posted by jaygade Sep 11, 2009
- 1314 views
Here, try this:
-- Call a C routine in a shared library include std/dll.e include std/machine.e atom libncurses, curses_version, ver_string integer c -- Attempt to open the library using various names libncurses = open_dll({"libncurses.so", "libncurses.so.5"}) if libncurses = 0 then puts(2, "Could not open libncurses.so or libncurses.so.5.\n") abort(1) end if curses_version = define_c_func(libncurses, "curses_version", {}, C_POINTER) ver_string = c_func(curses_version) puts(1, "Curses version: ") loop with entry do puts(1, c) entry c = peek(ver_string) ver_string += 1 until c = 0 puts(1, '\n')
Output:
Curses version: ncurses 5.7.20090207
Should this replace the current demo? Should it be added on? I'm not ambitious enough to do some fancy curses stuff like draw a window and say "Euphoria" and what not.
Surprisingly it worked the first time I ran it no typos or anything! That almost never happens!
