I am looking into porting a Windows app to UNIX. It consists of an executable and several dlls. I assume that the dlls will be compiled as shared libraries. How do I specify which functions in the shared libraries are 'exported', i.e. made available to the the executable and other dlls.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Porting Windows dlls to UNIX
- Thread starter reddog51
- Start date
Shared libs on Unix are different from Windows in several ways:
1) dlmain is not required
2) there is no need to create a .def file. If it is public or not static, it is exported
3) there isn't a separate .lib and .dll file. It is just one .so or .sl (HPUX) file. They all begin with lib but you drop the lib and .so when linking. Ergo libibel.so becomes -libel
4) In the linker -L sets the library path
5) If you need to simulate LoadLibrary, look at dlopen etc. This isn't normally necessary unless you are doing something weird. I always thought the LoadLibrary stuff in dlmain was strange in that if has already been linked, why do you need to load it?
6) Watch out for templates. If you are working in C, no problem. If you are working in C++, use the C++ compiler to do the link. You may magically lose your template definitions if you use the linker directly.
7) When running, if it loads up the wrong stuff, use ldd (or chatr on HPUX) to find out which dlls it is trying to load. It looks at the $PATH variable so the first one it hits on the path will be loaded and may not be the one you want.
Have fun.
1) dlmain is not required
2) there is no need to create a .def file. If it is public or not static, it is exported
3) there isn't a separate .lib and .dll file. It is just one .so or .sl (HPUX) file. They all begin with lib but you drop the lib and .so when linking. Ergo libibel.so becomes -libel
4) In the linker -L sets the library path
5) If you need to simulate LoadLibrary, look at dlopen etc. This isn't normally necessary unless you are doing something weird. I always thought the LoadLibrary stuff in dlmain was strange in that if has already been linked, why do you need to load it?
6) Watch out for templates. If you are working in C, no problem. If you are working in C++, use the C++ compiler to do the link. You may magically lose your template definitions if you use the linker directly.
7) When running, if it loads up the wrong stuff, use ldd (or chatr on HPUX) to find out which dlls it is trying to load. It looks at the $PATH variable so the first one it hits on the path will be loaded and may not be the one you want.
Have fun.
- Thread starter
- #4
What I'm trying to figure out is: in Windows, you specify a DLL_EXPORT declaration for the functions you want to export from the dll, and then a corresponding DLL_IMPORT declaration in the modules which use those functions. I can't find any corresponding construct in UNIX. How do you identify which functions are being exported?
Everything that is public, protected or not static is exported. There is no need to identify them. Windows puts in the DLL_EXPORT so that they can create the .lib file and DLL_IMPORT so that the compiler can generate the right code.
This is not required on Unix: the compilers and linkers can figure it out for themselves.
Just try it out on a small noddy program. Check the C++ compiler flags: there is normally one to create shared libraries. Failing that, look at the ld command.
This is not required on Unix: the compilers and linkers can figure it out for themselves.
Just try it out on a small noddy program. Check the C++ compiler flags: there is normally one to create shared libraries. Failing that, look at the ld command.
This might not even be necessary. Do the dlls really need to be dynamically loaded? Are there multiple instances of the program running at once or are the libraries used by many different executables at once?
Even if they are, is the executable image really that big that they need to be shared?
If not then just create static libraries and link them statically. This simple in UNIX.
I often wonder whether the dlls created for many windows programs need to be dynamic at all. Maybe it just makes the title screen quicker to come up before it loads in the rest of the code using dlls? I suppose it does mean you can release a new dll for a bug fix without having to release the whole executable.
Even if they are, is the executable image really that big that they need to be shared?
If not then just create static libraries and link them statically. This simple in UNIX.
I often wonder whether the dlls created for many windows programs need to be dynamic at all. Maybe it just makes the title screen quicker to come up before it loads in the rest of the code using dlls? I suppose it does mean you can release a new dll for a bug fix without having to release the whole executable.
- Thread starter
- #7
Thanks to all for your help.
My problem was that my application uses a number of dlls which all perform a variant of the same calculation. As such they all contain a number of functions with the same name. This was not a problem in Windows since I only exported the primary entry point.
Without getting into the gory details, it wasn't practical to move the common files to a separate library or have multiple copies of those functions with different names.
My solution was to include all of the code for each dll/library into a single code module, and make everything static. The only external is my entry point.
It works in Windows. Have yet to test it in UNIX.
My problem was that my application uses a number of dlls which all perform a variant of the same calculation. As such they all contain a number of functions with the same name. This was not a problem in Windows since I only exported the primary entry point.
Without getting into the gory details, it wasn't practical to move the common files to a separate library or have multiple copies of those functions with different names.
My solution was to include all of the code for each dll/library into a single code module, and make everything static. The only external is my entry point.
It works in Windows. Have yet to test it in UNIX.
- Status
Similar threads
- Locked
- Question