Re: shared libraries
On 12/11/2004 10:21 AM, Justin Pryzby wrote:
> 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).
Oh. My. God. Can you hit them with the clue stick? Is it supposed to
replace the standard system libc, or are they just _really_ dumb about
selecting library names?
> 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.
Could you rename the libc.a to something else immediately after it's
created, and link to it as needed?
> By the way, what is /usr/lib/tls/, and why do all of my programs link
> to its libc.so?
I have no idea. Looking it up in packages.debian.org doesn't seem to
produce any results. What does "dpkg -S /usr/lib/tls" say? Is it in
your /etc/ld.so.conf?
> 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.
Oh yes, quite a bit more than a week. But I agree it was worth the trouble.
> It still doesn't completely work yet. Probably something about 30
> year old blobs of fortran.. I expect cernlib is the same?
Yep, exactly. Got to love scientific code... ;-)
--
Kevin B. McCarty <kmccarty@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544
Reply to: