Compiling to make a "Linux dll" using windows cpp's, .h's, and .LIB

a1drich · 05-11-2007, 02:57 AM

I use this code in command prompt in windows to make a dll file. How do i do this exact same thing to make a "dll for linux"? may somebody teach me or point me to the right direction as googling doesnt help much and im still searching.

cl -GX /I C:\include /I c:\include\win32 -LD someLib.LIB -LD firstFile.cpp -LD secondFile.cpp -LD ThirdFile.cpp -FeMyTestDll.dll /link /NODEFAULTLIB:libc.lib /NODEFAULTLIB:libcd.lib /NODEFAULTLIB:libcmtd.lib /NODEFAULTLIB:msvcrtd.lib

Thanks,

Aldrich

taxtropel · 05-11-2007, 03:43 AM

CODING IN LINUX IS VERY DIFFERENT FROM CODING IN WINDOWS

that being said.
A DLL is a dynamic link library. which means that a program can be linked to that library and use the function calls inside.

well any .so library in linux is the same idea

try something like ldd /bin/cp
and you can see what libraries cp is linked to.

so you wanna make a library in linux eh?

you can follow these directions:

the following is from http://www.linux.com/howtos/Program-...ibraries.shtml

Quote:

Creating a Shared Library
Creating a shared library is easy. First, create the object files that will go into the shared library using the gcc -fPIC or -fpic flag. The -fPIC and -fpic options enable ``position independent code'' generation, a requirement for shared libraries; see below for the differences. You pass the soname using the -Wl gcc option. The -Wl option passes options along to the linker (in this case the -soname linker option) - the commas after -Wl are not a typo, and you must not include unescaped whitespace in the option. Then create the shared library using this format:
gcc -shared -Wl,-soname,your_soname -o library_name file_list library_list
Here's an example, which creates two object files (a.o and b.o) and then creates a shared library that contains both of them. Note that this compilation includes debugging information (-g) and will generate warnings (-Wall), which aren't required for shared libraries but are recommended. The compilation generates object files (using -c), and includes the required -fPIC option:
gcc -fPIC -g -c -Wall a.c
gcc -fPIC -g -c -Wall b.c
gcc -shared -Wl,-soname,libmystuff.so.1 -o libmystuff.so.1.0.1 a.o b.o -lc
Here are a few points worth noting:
Don't strip the resulting library, and don't use the compiler option -fomit-frame-pointer unless you really have to. The resulting library will work, but these actions make debuggers mostly useless.
Use -fPIC or -fpic to generate code. Whether to use -fPIC or -fpic to generate code is target-dependent. The -fPIC choice always works, but may produce larger code than -fpic (mnenomic to remember this is that PIC is in a larger case, so it may produce larger amounts of code). Using -fpic option usually generates smaller and faster code, but will have platform-dependent limitations, such as the number of globally visible symbols or the size of the code. The linker will tell you whether it fits when you create the shared library. When in doubt, I choose -fPIC, because it always works.
In some cases, the call to gcc to create the object file will also need to include the option ``-Wl,-export-dynamic''. Normally, the dynamic symbol table contains only symbols which are used by a dynamic object. This option (when creating an ELF file) adds all symbols to the dynamic symbol table (see ld(1) for more information). You need to use this option when there are 'reverse dependencies', i.e., a DL library has unresolved symbols that by convention must be defined in the programs that intend to load these libraries. For ``reverse dependencies'' to work, the master program must make its symbols dynamically available. Note that you could say ``-rdynamic'' instead of ``-Wl,export-dynamic'' if you only work with Linux systems, but according to the ELF documentation the ``-rdynamic'' flag doesn't always work for gcc on non-Linux systems.
During development, there's the potential problem of modifying a library that's also used by many other programs -- and you don't want the other programs to use the ``developmental''library, only a particular application that you're testing against it. One link option you might use is ld's ``rpath'' option, which specifies the runtime library search path of that particular program being compiled. From gcc, you can invoke the rpath option by specifying it this way:
-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)
If you use this option when building the library client program, you don't need to bother with LD_LIBRARY_PATH (described next) other than to ensure it's not conflicting, or using other techniques to hide the library.

a1drich · 05-11-2007, 04:07 AM

Many thanks

a1drich · 05-11-2007, 04:12 AM

Does this mean i wont be able to use my .LIB? do i need to recode a .LIB that is linux friendly?

taxtropel · 05-11-2007, 04:41 AM

well, linux doesn't use .LIB files

it uses source code files, which are turned into object files
from mysource.c -> mysource.o

then you mesh the .o files into a .so file (library)

you will probably have to rewrite a good chunk of your code too