[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: shared version of CPML (was Re: seti at home)

"Alexander L. Belikoff" wrote:
> "Wes Bauske" <wsb@paralleldata.com> writes:
> > "Christopher T. Lansdown" wrote:
> > >
> > > Well,
> > >         I once found some program that wouldn't compile with -lcpml, it
> > > needed something in -lm, so I ended up doing -lcpml -lm and it worked.  It
> > > may be a gnu extension or something, but I wouldn't recommend replacing
> > > your libm with the cpml.  You probably won't run into much trouble, but
> > > you never know.
> >
> > I've observed something similar but I'm wondering if it was
> > just a linker behavior. I've noticed if one builds archives
> > that are interdependent (a in -la calls b in -lb calls c in -la)
> > one can get undefined references if you don't put libs on
> > the link as "-la -lb -la". Anyone else noticed this or is
> > there another way to fix it? (no time to unravel the interdependence)
> >
> AFAIK, that is the standard behavior of ld in UNIX. Hence the:
>         -lc -lpthread -lc

I don't have to do that on other platforms, either
that, or I've been lucky on them?? (Solaris/AIX/IRIX)

I can see how one could build tricky binaries with it.
For example, you have the same module name with two 
slightly different versions, (for some reason), and
want one part of your code to use one version and some
other to use the other one.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []