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 <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/ Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
