SGI: Development

Hi,
because some Nekoware packages like neverball, audacity and so on require libtiff in version 3, is it possible to install it as addition to the libtiff version 4?

I have seen libtiff 3 in the archive part of nekoware, but if I want to install it, inst wants to uninstall version 4. I think version 4 will be needed by other packages?

Thanks in advance!

you could install the older one to an alternative location (inst/swmgr option -r) and put the files that have different names than what comes with the current version of the lib into one of your library paths

foetz wrote: you could install the older one to an alternative location (inst/swmgr option -r) and put the files that have different names than what comes with the current version of the lib into one of your library paths

He could try symlinking it first; ln -s libtiff.so.4 libtiff.so.3 - Of course the symlink won't be under installation control so it would need to be removed by hand when it's no longer needed. It might not work at all if features from version 3 have been sufficiently modified (or removed altogether) in version 4 (unlikely)...

yeah the symlink is worth a try. for some libs that's enough

Hi,

foetz wrote: you could install the older one to an alternative location (inst/swmgr option -r) and put the files that have different names than what comes with the current version of the lib into one of your library paths

Thank you very much! Using inst -f . -r /usr/oldlib/ worked fine. Now I can use LD_LIBRARY_PATH to set the old tiff version if I need it. Perfect!

The symlink variant sadly doesn't seem to work on libtiff. But with the separate version installed I am happy.

Btw, is setting LD_LIBRARY_PATH okay for IRIX? It is highly recommended not to do that on Solaris.

It's fairly commonly done (IRIX uses a bunch of different variables, LD_LIBRARY_PATH for O32, LD_LIBRARYN32_PATH for N32 and LD_LIBRARY64_PATH for N64 libraries)

For myself, it's more of a surprise that solaris has some issue with it. Care to elaborate on why? (I am not very familiar with Sun/Oracle)

Solaris uses a tool called "crle" to set up library paths.

https://blogs.oracle.com/ali/entry/avoi ... y_path_the

nongrato wrote: Solaris uses a tool called "crle" to set up library paths.

https://blogs.oracle.com/ali/entry/avoi ... y_path_the

well that blog article seems like defending the leave of a common path and searching excuses for doing so.
i've never used anything else but LD_LIBRARY_PATH and never had problems. as with most things, if used right you're fine. that whole thing reminds me of linux as in adding more stuff for doing the same just so that maybe it gets a little more dummy proof.

i don't like the direction solaris has taken in recent years. instead of useful stuff they added more bloat with not only zero advantages over previous methods but making it actually more messy and unhandy. replacing the init scripts with all that svc junk is a good example. ever tried adding a new start up service manually? what a pita

foetz wrote: well that blog article seems like defending the leave of a common path and searching excuses for doing so.

Well, my initial message was just a question. I didn't mean to say everyone should avoid ld_lib_path even on IRIX.

instead of useful stuff they added more bloat

That's why i stick with Solaris 9

To avaoid such problems, I just created a small script called /usr/local/bin/oldtiff.sh. It contains nothing more than:


Running it like

works perfect (Assuming that /usr/local/bin and /usr/nekoware/bin are in PATH)

I just created entries in the toolchest for neverball and so on running it just this way.

nongrato wrote:

foetz wrote: well that blog article seems like defending the leave of a common path and searching excuses for doing so.

Well, my initial message was just a question. I didn't mean to say everyone should avoid ld_lib_path even on IRIX.

of course, my comment wasn't aimed at your direction

nongrato wrote: Btw, is setting LD_LIBRARY_PATH okay for IRIX? It is highly recommended not to do that on Solaris.

I've run into problems setting it globally in Irix as well. There has been some discussion of that here, the site search might turn up the reasons.

eudatux'es method is more elegant but nowadays if I run into a program that needs an LD_LIBRARY setting, I just make a little wrapper script for it.

In my oppionion it is a wrapper script. It is just usable for any desired program without changing it.

http://xahlee.info/UnixResource_dir/_/ldpath.html

hamei wrote: http://xahlee.info/UnixResource_dir/_/ldpath.html

eeww that's almost worst than the first article.
"In general, the whole concept of Unix's environment variables are bad. It is a symptom of unix's “solve it simply, quickly, brainlessly” philosophy." this sentence alone disqualifies the whole thing. the only brainless thing in this case is the author

env vars are very flexible and handy but it needs a tiny amount of brain power to use them right. a person not up to that shouldn't be admin of anything.

The X Windows Disaster chapter of the Unix Haters Handbook has some truly hilarious things to say about environment variables...

Unfortunately, Don Hopkin's online version of the chapter has scores of really bad typos but here it is nonetheless (otherwise the whole manual is available as a pdf in serveral places on the webs):

http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html

oh yeah, something named "...haters" should be very objective and well founded

on a more serious note, of course as with most things you can find good and bad attributes. the crucial part is the weighting.
but no matter what it's about the vast majority of cases come down to who is using it and how. a program created with a humble dose of common sense used by somebody in a similar way should be just fine. and with slightly more common sense env vars can even offer neat possibilities