10 replies to this topic

[tobeythorn]

I've been playing around with implementing a higher level languages in c and came to a problem of not being able to dynamically link to external functions not known at compile time and also the lack of a cross platform way of dynamic linking, period. After spending some time on google, it seems that there has been plenty of academic work, going way back, about better, cross platform, fully dynamic linking and modular programming, and no actual implementation in use. I find this remarkable.

Am I missing something? The only solution I know about is remote function calling between executables via a network (Java has this).

Thanks,
-Tobey

[Reedbeta]

I'm not sure what you mean by cross-platform dynamic linking? That sounds to me like it would imply that the same binary could be used on different platforms, which doesn't make much sense unless you're talking about a VM language like Java or .NET, in which case it's automatic. Or perhaps you simply mean using the same API, so you could recompile on a new platform and it would just work? That seems easy enough to achieve by writing just a little bit of wrapper code. You essentially only need three functions - one to load a module, one to unload it, and one to look up a symbol.

As for linking to functions not known at compile time, you certainly can do this - as an example, in Windows, you can use GetProcAddress32 to look up a symbol by name. Of course, you have to know the type of the function to call it properly. Import libraries are, I believe, just a wrapper around this, with the actual module loading and lookup being done by the C runtime.

[tobeythorn]

Reedbeta,
To clarify, I mean cross platform in the sense of a standard way of making and accessing an external library. As it stands for the c, there's .dll on windows, and .dylib and on mac and .so on unix.

I will read up on GetProcAddress, it looks promising. Perhaps there is a mac equivalent. Thanks for the ideas,
-Tobey

[Nick]

tobeythorn said:

To clarify, I mean cross platform in the sense of a standard way of making and accessing an external library. As it stands for the c, there's .dll on windows, and .dylib and on mac and .so on unix.

That's not just for C but for any language compiled to an executable (instead of bytecode or being interpreted). And different operating systems simply have different executable formats. So just compile for the one you need.

Yes it's a pain for someone who writes his own compiler, but there's no way around it. Fortunately though, once you've got it working on one platform the others are very similar.

Anyway, exactly how does your language work? Do you translate it to C and then compile it with an existing compiler? Or do you compile it to assembly code and use an assembler to create the binary code? Or do you generate the binary code yourself? And in what environment is the code used? A standalone executable, a dynamically loaded framework, a network service?

We'll be able to help you better if you could give us more details about your actual goals.

[tobeythorn]

Nick,
I'm attempting to create a (at least partial) implementation of the Io language( for my own learning, and perhaps to produce a faster implementation).

Basically, the plan is to read in a Io program (as text), convert it into a message-pass tree, and then execute that tree. I'm using plain c, and have defined some very generic structures for objects, messages, methods, etc. To avoid needing to know function types at compile time, all underlying c-functions have exactly 2 parameters(an int for the number of parameters, and a pointer to an array of parameters) and return a generic struct. I've written most of a message passing function that transverses a message tree, looks up slots, and then calls appropriate method(some of which call underlying c-functions to get things done). The issue I see is that although my executable will have built in basic functions, Io does allow external c-functions to be called. For example, someone should be able to write a method in Io that binds to an openGL function.

This is my first attempt at something like this and also the first time I've explored dynamic linking.

[Nick]

tobeythorn said:

Io does allow external c-functions to be called.

I'm not familiar with the language, but according to Wikipedia it features DLL loading. So it must have some specification to do this. At least you'll need the name of the library and the name of the function, and then you can use LoadLibrary and GetProcAddress, or equivalent on other platforms.

[SamuraiCrow]

https://developer.mo...g/en/About_NSPR is how Firefox uses .DLL/.SO/.Dylib for plugins. It contains several other advanced features as well. I'm not sure if it is a C or C++ library though.

-edit-
If it is a C++ library, you should be able to write a wrapper using extern "C" directives.

-edit2-
A more useful link is at https://developer.mozilla.org/en/NSPR if you're interested.

[.oisyn]

Nick said:

That's not just for C but for any language compiled to an executable (instead of bytecode or being interpreted). And different operating systems simply have different executable formats. So just compile for the one you need.

I think his point was that there seems to be no cross-platform API to handle the loading of shared libraries and the accessing of symbols (although NSPR as quoted above clearly does)

[tobeythorn]

That was my point, and thank you very much, SamuraiCrow, for pointing out NSPR, because that does appear to be a solution.

[Nick]

.oisyn said:

I think his point was that there seems to be no cross-platform API to handle the loading of shared libraries and the accessing of symbols...

Sure, but it's two lines of code for each platform. I don't really see the need for any 'API' here. Using NSPR for this is like a using a sledgehammer to open a bag of chips.

[SamuraiCrow]

@tobeythorn

You're welcome! I think there may be a simpler wrapper for shared libraries in SDL 1.2.13 also if NSPR proves to be too bulky.

@Nick

One reason that a central API would be desirable for such things would be to make a source-code relatively future-proof. If you wanted to support more than the 3 standard OSs that everybody supports, for example.