Re: shared libraries

[Justin Pryzby <justinpryzby@users.sourceforge.net>]

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
libs..

> 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:

	char *
	xyencode (x, y)
	int x, y;
	{
	    char obuf [SZ_VECT];

	    sprintf (obuf, DEV_VECT, x, y);
	    return (obuf);
	}

Justin