Re: Creating and using a .DLL/.SO?
- Posted by jimcbrown (admin) Dec 26, 2008
- 1100 views
There's also the issue of possibly conflicting names.
In regards to reserved words in C but usable names in eu, I like the approach that CName() takes. At least it is well defined.
In regards to "reserved" words (like fopen() or dlopen() ) I'm not sure should be done. Mangling (as above) is probably the safest option though.
In regards to conflicting names within the eu code itself (public function ftakes() in file ftakes.e conflicting with public function ftakes() in file outtakes.e for example, included in a.e and b.e respectively and used only there and then a.e and b.e are included in main.ex) this is a tricky situation. Back when we had only global it was a lot easier, but having namespaces makes even this hard. In this case, we need a way to have the user (the one translating the code into a dll/so) specify what to do. There's no way to "do the right thing" and have everybody be happy.
And I believe that gcc prefixes an underscore (though maybe not in all situations).
This is only an issue when mixing and matching compilers. This is actually an ELF standard (meaning all C compilers for all Unix platforms that output ELF binaries will name the functions in the same way), so I believe an issue would only ever arise when using gcc and Windows (e.g. mingw to translate eu to a dll).
Perhaps the best thing to do is just to output the .e wrapper that handles the imports correctly. We could also do a regular C header (.h) fileprobably optional.
I guess by .e wrapper you mean outputting a .e file that has the correct open_dll() and define_c_func()/proc() calls to call the dll from within eu code?
How would one call the dll from C code without a .h wrapper?
The wrapper could be possibly multiple files with a "lib" prefix. The multiple files would allow us to replicate the namespaces. Or we could change the default namespace to be changeable within a file.
Matt
I'm not sure I follow. What would this mean?
