Shared Libraries

[Shridhar Daithankar]

On Thursday 28 March 2002 20:33, W. Tasin wrote:
> Shridhar Daithankar wrote:
> 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).

No. People are lazy. Say there are two libraries A and B. (Did I say this 
before? I think so. Anyway I will say here too..) Library A depends upon A.

Now in normal situation, a sane person would code library A first. So it will 
get compiled first. But in case, somebody codes B first and references a in 
it, he is bound to get linking error.

That's not bad in itself. But problem is entire make aborts due to it. If 
make continues in this case of errors and build library A anyways, next run 
of make will succeed because library A is present.

Just now I coded a class where in implementation class of a dialog, few slots 
were defined but not implemented and I got linking errors. Just putting empty 
slot definitions in .cpp solved it for time being. But that's how it is.

Yes I don't use add member function dialog box. I prefer copy/pasting around..

> 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).

No. Point is you allow to adjust coding and compile dependencies at any point 
of time. That is disciplined coding but bit more than that when it comes to 
maintaining a large project. I do one and know the grief when somebody does 
not follow convention and discipline.. I hate paying for somebody else's 
crime.. Like hardcoding tags in Makefiles etc..

And besides it looks rather strange to me that kdevelop allows you to create 
libraries but not modify them later in project config. Some options should be 
there.

> 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.

That's what I am doing. ..;-)

Yes. But that means a small effort of commenting out that binary from 
Makefile.am before I make a release.

Note I don't mind that. But my opinion is an IDE should allow to maintain 
things automatically. Developer need not follow build discipline like this. 
Imagine one fine day I forget. You can't expect a person to be right every 
time. But machine will work as instructed.

And Kdevelop's clear demarcation of what it will touch and what not in 
Makefile.am is in fact example of rather clean functionality. I don't have to 
worry about my changes being lost some point of time..

> 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

I will go thr. it. But in context of this discussion, I feel kdevelop should 
provide an encapsulation of some of such functionalities. Once I have 
kdevelop I shouldn't need to tinker Makefile.am even if I can.

> 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 ;-).

Agreed. I am going to attempt some improvements in this area. Allow me some 
time. I hope I can help.

 Shridhar