[Prev][Next][Index][Thread]
Re: linking to Math library with OSKit 20000202
> > and my first errors are:
> >
> > /home/jewel/oskit-install/lib//liboskit_threads.a(osenv_safe.o): In
> > function `safeinterface_query':
> > /home/jewel/oskit-20000202/threads/osenv_safe.c:37: undefined reference to
> > `osenv_safe_iid'
> >
> > ...
> > So this is the thread library looking for references to what? It's
> > confusing to see the file osenv_safe.c looking for symbol osenv_safe_iid.
> >
>
> Doh! I missed something when looking at our specs file. You gotta throw
> in -loskit_com after including -loskit_freebsd_c.
I realized this was "glue code" but didn't get far enough as trying
-loskit_com. Using that it links perfectly (generating a 1MB image). I'll
try it out soon.
>A simpler fix is to use
> the --start-group and --end-group constructs in ld. When placed around a
> group of libraries, it tells ld to iterate over all the libraries until it
> can resolve no more symbols. We have avoided giving in to this in general
> as we want to keep the gruesome dependencies explicit and embarrass ourselves
> into fixing them whereever possible.
I'll prefer to stick with explicit dependencies since I'm not going to be
changing them for this project.
> > Is there any other documentation about resolving these link dependencies?
> >
>
> Not in the current OSKit. Better handling of C-based components (in
> particular the OSKit) is the goal of another project which is going on here.
> Alastair Reid has mentioned this briefly before in at least one posting
> (<200002141722.KAA23483@wrath.cs.utah.edu>) and can say more about it,
> but briefly in "C Plus Units", each component ("unit") has a more formal
> description which includes the dependencies of that component on other
> components. Armed with these descriptions, we can ensure that components
> get glued together correctly.
I suppose this will be useful as the OSKit (and OSKit kernels) get more
and more complex.
Thanks for your help
John
References: