Re: shared libraries
On Sat, Dec 11, 2004 at 08:47:01PM -0500, Kevin B. McCarty wrote:
> 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?
The latter. It seems to be a part of "ratlibc" which is for "ratfor",
apparently a subset of fortran. Sadly its not named libratc.
> > 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?
See above, I delete it before linking executables, because the shared
version is named sanely (blush).
> > 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?
Its from libc6, I just don't know what its for. Its libc6.so.6 is
about the same size as the /lib one. I don't understand why .. I
thought "/lib", "/usr/lib" were the magic words.
> > 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.
I don't understand how upstream can justify *not* implementing shared
> Yep, exactly. Got to love scientific code... ;-)
Scientific indeed. For your added amusement, a gem I just ran across
when disabling the disabling of warnings:
xyencode (x, y)
int x, y;
char obuf [SZ_VECT];
sprintf (obuf, DEV_VECT, x, y);