Generic cross platform DLLs?
Author
I've been searcing around and I found both the Win32 way and POSIX way for dlls but I'm wondering if there is any cross-platform method for building and linking dlls. I looked at the boost library hoping to find something there but i couldn't find anything.
Any information would be greatly appreciated.
.NET (and Java, sort of) allows this. You can't create a native cross platform binary though. (If that's what you're asking. I'm kind of confused.)
Author
C++ actually.
I'm looking for a library that will help me run & comiple dlls for different platform.s
I'm looking for a library that will help me run & comiple dlls for different platform.s
If by "cross-platform" you mean OS's other than Windows or platforms other than PC, you're out of luck. Your DLLs will work with Windows only and to some extend with OS/2: They will, however, not work out-of-the-box for other operating systems or platforms that are not binary compatible with the x86.
Author
Oh I'm not asking for the binaries to be the same. I just want have an easy way to recompile the plugins for a different OS instead of having to rewrite everything from the ground up.
That depends entirely on your code. For optimal performance/platform support you'd need to have different implementations of your plugin. The cleanest way to deal with this is to have a common interface and to implement platform dependant bits in separate modules (e.g. cpp files) that you include on a per-platform basis.
A trivial example would be a memory-mapped file. You'd use a common interface and at least two implementations - one for windows that uses CreateFile, CrweateViewOfFile, etc. and a *NIX version that uses mmap. You'll often find that the parts that actually are platform dependant aren't the majority of code, but only a fraction of it. You can therefore share most of the code (especially any high-level code) and include platform dependant implementations as required.
HTH,
Pat
A trivial example would be a memory-mapped file. You'd use a common interface and at least two implementations - one for windows that uses CreateFile, CrweateViewOfFile, etc. and a *NIX version that uses mmap. You'll often find that the parts that actually are platform dependant aren't the majority of code, but only a fraction of it. You can therefore share most of the code (especially any high-level code) and include platform dependant implementations as required.
// another sample: Mutex interface, e.g. threading.hppnamerspace threading { /// Platform-dependant low-level class class Mutex { public: Mutex(); ~Mutex(); void Lock(); void Unlock(); private: struct Pimpl; Pimpl * pimp; }; /// Platform-independant high-level class class ScopedLock { Mutex & mutex; public: ScopedLock(Mutex & mutex) : mutex(mutex) { mutex.Lock(); } ~ScopedLock() { mutex.Unlock(); } };}// sample win32 implementation e.g. threading_w32.cpp:namespace threading { struct Mutex::Pimpl { Pimpl() { InitializeCriticalSection(&cs); } ~Pimpl() { DeleteCriticalSection(&cs); } CRITICAL_SECTION cs; }; Mutex::Mutex() : pimp(new Pimpl()) { } void Mutex::Lock() { EnterCriticalSection(&pimp->cs); } void Mutex::Unlock() { LeaveCriticalSection(&pimp->cs); } Mutex::~Mutex() { delete pimp; }}HTH,
Pat
I asked about this a little while ago in this thread and some one posted some good info:
hope that helps.
Quote:
Regarding multi-platform DLLs, there are some working solutions available, such as for example "KoreLib" (theKompany) or "SharedLib" (poco: http://poco.sourceforge.net
hope that helps.
please note however, that -at least in the long run- you might see the benefits of employing non-native DLLs (modules), so that embedding an scripting interpreter might suddenly become a very viable option, there's hardly anything that you can't do this way, while ensuring ultimate flexibility with regards to portability requirements. So, in general you may want to consider implementing your performance-critical code natively, while using a scripting interpreter to employ this functionality, this would have LOTS of benefits.
Author
Thanks Wavesonics, I looked at those libs: Poco Korelib and libtools and they all look interesting. My only concern is that those libs seem pretty heavy weight just for their dll tools. I'm not sure if it would be possible to write my own dll wrapper for UNIX vs win32... any ideas on this?
Exactly what are your lookig for, a way to build dynamically-loaded object modules on different target architectures, or a way to structure your code so that when given a way to build dynamically-loaded object modules on different target architectures, it will work, or a way to wrap COFF-format DLLs targetted at Intel architecture using PEI linkloader references so that they are loadable and runnable under foreign architectures such as ELF (Linux/Unix) or MACH-O (OS X)?
I might recommend just starting with doing basic cross-platform development first. Any cross-platform development toolsuite includes the necessary tools for, uh, developing cross-platform software, whether that software is a binary executable or a dynamically loaded object module (where supported). Once you've got that down, the question becomes moot.
I have used both the GNU autotools (automake/autoconf/libtool) and ant with the cpptasks add-on successfully to build dynamically-loaded object modules across all popular platforms from a single codebase.
--smw
I might recommend just starting with doing basic cross-platform development first. Any cross-platform development toolsuite includes the necessary tools for, uh, developing cross-platform software, whether that software is a binary executable or a dynamically loaded object module (where supported). Once you've got that down, the question becomes moot.
I have used both the GNU autotools (automake/autoconf/libtool) and ant with the cpptasks add-on successfully to build dynamically-loaded object modules across all popular platforms from a single codebase.
--smw
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
