From: Godmar Back (gback@cs.utah.edu)
Date: Wed Jan 20 1999 - 01:26:30 EST
>
> On Jan 18, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>
> > creating libkthread.la
>
> > In other words, it puts the files forming the threading subsystem in
> > their own library.
>
> It's just a convenience library, which means that anything linked with
> it will get *all* its object code. Think of it as a macro that
> expands to the list of all object files in it.
>
What's a convenience library?
Excuse me for using this example, I guess I could just check out the
latest tree and try to build it, but I want to make a point.
I think my question is this:
Does the final link line for kaffe look like
A.
ld ... -lkaffevm -lkthreads
or does it look like
B.
ld ... syscall.o jthread.o internal.o -lkaffevm
or does it look like
C.
ar -r libkaffevm.a syscall.o jthread.o internal.o
ld ... -lkaffevm
Each of these three choices incorporates fundamentally different things.
In order to design the proper interface between the code in kaffevm/
and kaffevm/systems/unix-jthreads/ I need to know whether the
final link line is A, B, or C.
I would choose A if
+ either kaffevm depends only on kthreads, but not the other way around.
In this case, I can choose a link-time interface
+ kaffevm and kthreads are mutually dependent. In this case, I need
to choose a run-time interface.
I would choose C if
+ kthreads is logically part of kaffevm
I would never choose B because kaffevm simply is not a library needed
for the files in libkthreads.a. Your paragraph above, however, seems to
imply it's B. Is that correct?
My point here is that I just don't know what abstractions libtool imposes.
libtool may think it can help me, but I need to know exactly what it is
it's doing and how do I get it to produce link lines that correspond to
the abstractions and interfaces that fit my will and my implementation.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:47 EDT