[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: Shared Libraries
From:       "W. Tasin" <tasin () fhm ! edu>
Date:       2002-03-28 15:03:24
[Download RAW message or body]

Shridhar Daithankar wrote:

>On 25 Mar 2002 at 17:32, August Hörandl wrote:
>
>>shared libraries are supported: just create a subdirectory, whatever
>>class you put there will go into a library: static or shared - it is 
>>your choice
>>
>
>Thanks. I tried and it worked. (I mean I got it working ..;-)). but I still 
>have some problems. Or rather to-dos.
>
><snip>
>
>
>2)How do I control order in which modules get compiled in shared libraries? As 
>far as I understand, the first one created will be compiled first. But is there 
>any way to control compilation order and especially setting up dependencies.
>
Why?
You mean an order-problem of linking (and not of compiling).
I haven't checked the problem deeply, but IMHO it should be unimportant 
in which order I put an object or library to the linkage process, if all 
functions are available so they will be added to the binary (static 
case)  or at least a reference to it (shared case).

I know there are problems with it, but I think there wouldn't be if you 
use a libtool-linked-lib (proofs against are welcome).
I still don't know if it is a ld, ar, ranlib or make-tool problem or 
sth. else, any suggestions are welcome, too.

But I don't think that it is an ordering problem... changing the order 
and make it working is only a workaround (and another way of discipline 
coding as you mentioned below).

see:
http://lists.kde.org/?l=kdevelop&m=100549583602845&w=2

>
>3)In a test project where I linked main.cpp against a module library lib1 just 
>by adding -llib1 to additional libraries in project->options->Liker options. 
>But when I do ldd on generated binary it doesn't recognise it as a dynamic 
>
>executable. Same for strip and nm. But it works.
>
If main.cpp is in the same project like the library, so kdevelop handles 
it correctly by adding lib1/liblib1.la.
If main.cpp is in a different project then liblib1.(la|a|so|so.xx.yy) 
has to be installed and this project uses -llib1 and the -L-flag to 
specify the directory where it is installed.

Is this what you mean?

>
>I do a make install of same and do ldd on installed binary and it shows 
>everything correctly. And it even works when project installation is in odd 
>folders like /mnt2/tmp and /mnt2/tmp/lib is not in 
>LD_LIBRARY_PATH//etc/ld.so.conf.
>
>4)How do I maintain a shared library project? Like a dll project in MSVC? Right 
>now What I think is to create a custom project and add a module to it. That way 
>it won't add a redundant binary to project. Is this correct? I haven't tested 
>it.
>
My personal opinion is to create a c++-terminal application, where the 
binary can test your shared lib (verbose output  like version number, 
functionality tests etc.). Creating a subdir and declare this as shared lib.
 
Many other issues to 2) and 3) and 4) are described here:

http://www.gnu.org/software/libtool/manual.html
E.g. the following charpters
- Introduction
- libtool's versioning system
- inter-library dependencies

>
>
>>From what I have seen in a short experiment, KDevelop's ability to manage and 
>maintain library modules is perfectly working but it's bit more rigid than 
>desired and doesn't offer much control once module created. I think disciplined 
>coding shouldn't face any problem but most people won't do that..;-)
>
That's correct...
but the solution to give kdevelop all possibilities of autotools/libtool 
and the "old fashioned"-ld stuff and maintain all changements in these 
tools is a task that takes more than one release, I guess ;-).

>
>Regards
> Shridhar
>
>
>_______________________________________________
>Kdevelop-devel mailing list
>Kdevelop-devel@barney.cs.uni-potsdam.de
>http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
Ciao

Walter

-- 
oohhh sveglia.... il mondo e' ammalato, ma x colpa di chi.........
(Zucchero)
:-------W._Tasin,_FB_04,_FHM-------------------PGP-KeyID:0x7961A645---:
<Key-Fingerprint: 1610 835F 0080 32F4 6140  6CF7 A7D0 44CD 7961A645>
<http://wwwkeys.pgp.net:11371/pks/lookup?op=index&search=0x7961A645&fingerprint=on>




_______________________________________________
Kdevelop-devel mailing list
Kdevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]