Title: creating shared libraries
Incubator - April 30, 2005 08:10 PM (GMT)
ok, bit of a newbie question but I never did this before, I want to know how I can create a C++ shared library for linux and how to compile it.
By which I mean I would not like to put functions in that lib but classes :)
C-Man - April 30, 2005 08:13 PM (GMT)
A very good question i migth add
i allways wanted to know that
for classes i'd say you could use class Factories
Incubator - May 1, 2005 10:53 AM (GMT)
It's just that I find Per land Java have a lot of modules/jar's and i think C++ could have some more
IMO: The world needs a good shakedown and realise C++ is way much better then Java :) (but thzts just my personal opinion, no need to start a flame war or so :P )
and thats why I want to put some effort in it to make some good libraries
C-Man - May 1, 2005 11:00 AM (GMT)
:yes: :yes: :yes: :applause: :applause: :applause:
Java sux0rz but i don't want to flame either :rolleyes:
Incubator - May 1, 2005 12:37 PM (GMT)
ok, after some googling i found it after all :)
| CODE |
/* libhello.h */
#ifndef _HELLO_H
#define _HELLO_H
#include <iostream>
using namespace std;
class Hello {
public:
Hello() {}
~Hello() {}
void sayHello();
};
#endif
/*libhello.cpp */
#include "libhello.h"
void Hello::sayHello() {
cout << "Hello" << endl;
}
compiling:
g++ -c libhello.cpp -shared -fPIC -o libhello.so
/* main.cpp */
#include "libhello.h"
int main(int argc, char** argv) {
Hello* h = new Hello();
h->sayHello();
delete h;
return 0;
}
g++ main.cpp -L. -lhello -o test
|
and thats it =)
though you might want to copy this .so to /usr/lib because thats your LD_LIBRARY_PATH
dorto - May 2, 2005 12:20 PM (GMT)
the process for creating a shared library is same for C and C++ modules. maintainence is difficult in the case of C++ because one can easily break the compatibility with an old library without any intention. one has to be very careful when making changes to a C++ library code if compatability with old library is needed. for eg, the linux documentation project notes the following things that cannot be done if compatability is needed:
| CODE |
1. add reimplementations of virtual functions (unless it it safe for older binaries to call the original implementation), because the compiler evaluates SuperClass::virtualFunction() calls at compile-time (not link-time).
2. add or remove virtual member functions, because this would change the size and layout of the vtbl of every subclass.
3. change the type of any data members or move any data members that can be accessed via inline member functions.
4. change the class hierarchy, except to add new leaves.
5. add or remove private data members, because this would change the size and layout of every subclass.
6. remove public or protected member functions unless they are inline.
7. make a public or protected member function inline.
8. change what an inline function does, unless the old version continues working.
9. change the access rights (i.e. public, protected or private) of a member function in a portable program, because some compilers mangle the access rights into the function name. |
PS: i hope you put that 'using' statement in the header just in the example and not in real code!
Incubator - May 2, 2005 05:12 PM (GMT)
that was just in the example, but why is that forbidden?
dorto - May 4, 2005 04:08 AM (GMT)
this was earlier discussed in some other threads but, in short, if you put 'using namespace ...' in a header file then it gets automatically included in all the files which include this header file. this has the potential of changing the meaning of the code in all the implementation files that include this file.
its like a rule of thumb now: always fully qualify the names in headers and in code before #include statements.
Incubator - May 14, 2005 09:24 AM (GMT)
now I got another problem here, and its more related about managing the files.
the main project source dir is ecsxx/src , but atm it contains all the header and source files.
Now, since Java uses packages its pretty easy in there to separate things but in C++ its a lot harder.
For example there is a class GenericElement with belongs in the ecsxx/src folder but a lot of classes (that are (x)html eleemnts inherit from this class.
So, for example to make all the classes for the html elements, they should be placed in the folder ecsxx/src/html in order for things to be a bit tidy and clean.
But now I am faced with a few problems:
1) in the header files of the classes inside this html dir I would have to use this code:
| CODE |
#include "../genericelement.h"
.....
|
I'm not sure but i think this would give problems if the lib's headers would be installed in /usr/include/ecsxx
/usr/include/ecsxx/html
2nd
compilation
atm I use qmake to generate the makefile because I still have no good knowledge of the dreaded autotools.
Telling to qmake html is a subdir is possible but then it wants a project file in that subdir as well. Since I can only specify app, lib or subdirs as template (type of target) I would have to make for each subdir a .pro file that would create a .so and the main project file in the root dir would have to link htem together.
Now....i dont know but i dont think thats a good way.
I'm open for clean and better suggesstions with the proper tutorial/howto :)
C-Man - May 14, 2005 01:06 PM (GMT)
separate the header and source dir's
./include
./include/html
./src
./src/html
./lib
./bin
Incubator - May 14, 2005 04:29 PM (GMT)
ah, I see...
This is going to be a bit tedious i think...have to adapt the project file and hope kdevelop accepts it :s
