| View previous topic :: View next topic |
| Author |
Message |
rildopragana
Newbie
Joined: 08 Jun 2005
Posts: 3
|
 Posted: Mon Jun 13, 2005 2:00 pm Post subject: Calling .so libraries under Linux |
 |
|
I'm with m680 on Linux. What should I do to call a C shared library function? The following code don't work, it returns "error loading the DLL".
I have changed the library to "ncurses" (without the lib preffix), "libncurses" (without the suffix .so), and several other combinations without success. What am I doing wrong?
Also, the ChDir statement don't change the current directory (the msbox in the line after it returns the previous current dir). Are all those functions only supposed to work under MS-Windows?
Please, give me some hints!
| Code: |
Declare Sub beep Lib "/usr/lib/libncurses.so" Alias "beep" ( )
Sub ExampleDeclare
ChDir("/tmp")
msgbox curdir()
print fileExists("/usr/lib/libncurses.so")
beep()
FreeLibrary("/usr/lib/libncurses.so" )
End Sub
|
|
|
| Back to top |
|
 |
Danad
OOo Advocate
Joined: 22 Feb 2004
Posts: 293
Location: Brasil
|
|
| Back to top |
|
|
SergeM
Super User
Joined: 09 Sep 2003
Posts: 3211
Location: Troyes France
|
|
| Back to top |
|
|
rildopragana
Newbie
Joined: 08 Jun 2005
Posts: 3
|
| Posted: Tue Jun 14, 2005 11:25 am Post subject: |
|
|
Thanks Serge, but I found the answer in the source code of the StarBasic interpreter. According the following lines from basic/source/runtime/dllmgr.cxx, Linux (and other unices as well) are second class environments for OOo 
| Code: | SbiDllHandle SbiDllMgr::CreateDllHandle( const ByteString& rDllName )
{
#if defined(MAC) || defined(UNX)
SbiDllHandle hLib=0;
#else
SbiDllHandle hLib;
#endif
#if defined(WIN)
hLib = LoadLibrary( (const char*)rDllName );
if( (ULONG)hLib < 32 )
hLib = 0;
...
|
It is a shame, because loading .so libraries is so easy or easier than Win* .DLLs. Only MS-Wincrap and OS/2 libraries are supported. Unfortunatelly, my application requires a fast bidirectional communication between OOo and my code. Sockets in Basic locks during reads and are too sloooow in OOo implementation, pipes and also fifos [named pipes] are not supported by the SimpleFile service, and so on. Only the clipboard was left to make my communication. Of course, there is the Shell() command and the environment to exchange messages, but this is a slower yet alternative. And the scriptngs framework don't (at least yet) support tcl (which I need) and is not easy to create another uno bridge. And I plan to stay very away from Java (arg!!!!!) code.
So, we can conclude OOo is a nice environment, well guarded under a crystal shield, pratically unable to talk to any other.
Anyway, thanks for your effort and fine links collection!
_________________
Rildo Pragana
http://pragana.net/
Recife, PE - Brazil |
|
| Back to top |
|
|
DannyB
Moderator
Joined: 02 Apr 2003
Posts: 3991
Location: Lawrence, Kansas, USA
|
| Posted: Wed Jun 15, 2005 6:10 am Post subject: |
|
|
| rildopragana wrote: | ... the scriptngs framework don't (at least yet) support tcl (which I need) and is not easy to create another uno bridge. And I plan to stay very away from Java (arg!!!!!) code.
So, we can conclude OOo is a nice environment, well guarded under a crystal shield, pratically unable to talk to any other.
|
There is a .NET (and presumably Mono) bridge for UNO in the works.
There is a working Python bridge right now. I use it.
While I don't have anything against Java, and am hopeful to see GCJ supported soon so that Java works as natively compiled code rather than JVM code; I find Java very difficult to use with OOo's API because of all of the queryInterface.
For similar reasons, I suspect (but don't know) that C++ is similarly difficult to use. Constantly having to cast to the right interface before you can call a method.
Basic, Python and JavaScript are a breeze. JavaScript and Basic are only supported as a scripting language. Python can be used for scripting, components, or external programs running outside of the office -- even on a different computer-- even a different OS.
Even if Basic could load .so files, it would give you portability problems similar to what Windows users get when they use DLL's. If I write a component in Java or Python, or if I write a script in Basic, JavaScript, Python, or Java (BeanShell), then it works on OOo on any platform. Even if that platform is not yet invented. For example, suppose that somebody ports OOo over to SkyOS, or BeOS. Then my components and scripts just work. Use of non-portable features like .so's and DLL's won't work.
The .NET bridge would (presumably) have the same benefit. You could write in any language for .NET, not just C#, and then code could presumably work on any platform that OOo runs on.
_________________
Want to make OOo Drawings like the colored flower design to the left? |
|
| Back to top |
|
|
hector
General User
Joined: 11 Apr 2004
Posts: 6
Location: France
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
