Re: shared libraries
Hi Kevin,
On Sat, Dec 11, 2004 at 08:12:44AM -0500, Kevin B. McCarty wrote:
> Justin Pryzby wrote:
> Alternative solutions would be to put the shared libs in /usr/lib, or
That's what I've done; I think that makes sense, because compiling a
program with "XC" (the IRAF compiler frontend) will see them without
any fuss. I've hacked XC to pass -L and -l options to the host
compiler rather than interpretting them, and eventually I'll do
something to allow users to use static libraries.
Some of IRAF's external tasks will need those libraries. The
sole problem is that I've converted libfoo.a to libiraf-foo.so.0 (plus
a symlink libiraf-foo.so). So users have to be aware to
s/^lib/^libiraf-/. (XC knows that -lx => -liraf-x).
Oh, yeah, and upstream creates a libc.a which is in the search path ..
for now I'm just removing it so that gcc doesn't screw up (shared
libraries are renamed, but static onese are not).
Is there a way to reset the library search path? I would like to
specify gcc -L $IRAFroot (so that I use the just-compiled version of
the libraries, and not something that may be already in /usr/lib)
-lfoo (which XC will resolve to libiraf-foo) ...
--reset-library-search-path?
If I could do that, then libc.a wouldn't be a problem. I suppose I
could just use gcc -L/usr/lib -L$IRAFroot..but that's pretty bad.
By the way, what is /usr/lib/tls/, and why do all of my programs link
to its libc.so?
> By the way, congrats on getting IRAF to build shared libs -- I hope it
> wasn't as much of a pain in the @$$ as I found it was for cernlib.
Well, did you spend more than a week doing it? :-0
Its worth it though; it cut the size of my architecture-dependent
package by a factor of 2. And I'm now a factor of *5* smaller than
what upstream distributes.
It still doesn't completely work yet. Probably something about 30
year old blobs of fortran.. I expect cernlib is the same?
Justin
Reply to: