How to use LD_LIBRARY_PATH et al properly

You want to avoid setting those variables, as you see. $rpath should point to the library when you compile the binary that is supposed to link to it, so then the path becomes hard-coded.

Here is more info:

http://qin.laya.com/techcoding_help/dyliblinking.html

I could not get the paths to work with mono either - I ended up putting the names and the full paths of everything not in /usr/local/lib into the config files. I built mono from the source and that seems to work better than their pre-built stuff for the Macintosh, but installing gtk is a pain. On the other hand, it took only a few changes to get a large C# program from the PC to run under mono - very nice.

Why are you using macports? This is the 2nd or 3rd message I've seen regarding problems with LDLIBRARYPATH and macports/fink. It seems to me that they only cause trouble. Anything in macports can be configured, made, and installed in all the standard locations.

Aussie Susan wrote:
Why use MacPorts/Fink? I guess it's because I don't want to manually install the 80 dependencies (not including Mono and MonoDevelop).

Nobody ever said programming was easy:)

Elsewhere on the Internet I've seen several items saying that using the LD_xxx and DYLD_xxx environment variables cause problems whenever they are used.

I'm sure this is true of LD_xxx, as this is a macports/fink thing. I think DYLD_xxx will only cause problems if used incorrectly.

I'm guessing that the MacPorts/Fink aspect is a bit is a side issue, at least in this case.

Your guess is as good as mine. I see MacPorts/Fink as just an unnecessary convenience, and an invasive one at that.

I don't consider myself to be a dynamic library expert on any platform. I do know a little bit, however. You are telling me that a basic OS functionality, DYLD_xxx doesn't behave as it should. You are also telling me you've installed a monolithic software package that heavily mucks with DYLD_xxx.

If you had a problem installing any one of those 82 dependencies, I would be interested in finding out why it is broken and how to fix it. I believe that any well-written POSIX package should compile and run on MacOS X and I'm willing to do it myself if I have to. MacOS shouldn't need any "helpers".

But with macports/fink, there is nothing I can or want to do. If their software doesn't work, you need to ask them for support. I'm sorry if I'm a bit harsh. If people have programming questions, I like to download and try out the stuff myself because I always learn something. But I'm not going to install anything that could potentially put my own development system at risk. If there isn't any decent support from macports, you can always try Apple's mailing lists. Just be sure to use the very nice archive search feature before posting a new message. As harsh as I might be, that is nothing compared to some those people.

Fink does not set those paths. It is against their packaging requirements. IIRC, people have posted here with fink or darwinports packages breaking because OTHER software maliciously sets those variables.

gtk+2 on fink is straightforward and works great. I put in a fink package called glossy_P that gives gtk+2 programs an aqua-like appearance.

Aussie Susan wrote:
I'm not saying that I have installed anything that uses or requires LD_xxx or DYLD_xxx variables to work. I have installed Mozilla which 'seems' (from my limited experience with OS X and UNIX in general - I'm from the old VAX/VMS days!) to install its libraries in places that are not on the 'normal' search paths.

I know less about Mozilla than you. But I do know that MacOS X doesn't even have to use search paths. You can embed a dynamic library inside an application bundle and then use the installnametool to tell the application where to find it.

Mozilla is a hard one. The macports version could be all screwy. The "original" version could be just as, if not more, screwy. The bigger the project, the more apt they are to make up their own rules and ways of doing things.

This means that:
1) I must be missing something in my understanding of how to install Mozilla and I'm inadvertently letting it something wrong (I always thought the general extract/configure/make/make-install pattern is sufficient until you want to do something beyond the usual)

This is a possibility. There could be something special you need to set in configure to make it (MonoDevelop) work with Mozilla. Or Mono might only work with version 4.1.03-RC2 (for example) of Mozilla on OSX. I don't know. The research I did the other day before getting on my anti-macports soapbox was all from 2005. You may have to track down those 2005-vintage packages before it will work.

2) I have a lack of understanding of how software is expected to work on OS X/UNIX

#2 is certainly true and actually forms the basis of my original question.

The same is true for me. In particular, Apple would prefer people to make Frameworks. What little I do with dynamic libraries I do very carefully because I know how easy they are to break. The fact that you've gotten 81/82 working is remarkable.

The only issue I have with downloading and installing however many packages is finding them in the first place. Again it is probably because I have not yet come to 'think' like a UNIX programmer, I have to use Google to try to locate the distribution for a piece of software, download it, extract it, try the ./configure command and wade through all of the 'can't find XXX with a version number >= n.n.n' type messages, go back to the Internet to try to locate each package, down load it..... all while trying to keep track of where I am.

Yes, that is a problem. Macports is a solution to that problem. However, it (or any similar product) causes its own set of problems. Back before MacOS X days, when I was trying to use Linux, I tried to use all the Linux tools that did the same thing as Macports. You want to install project C, that depends on B, that depends on A, version 2.0. Fine, you let the "portage/etc" tool do all the work and project C is running. However, your DHCP client needed project A, version 1.2 and your Internet doesn't work anymore. Repeat.

The nice thing about the Linux tools is that they work using the standard locations, usually /usr/local. Again, usually, you don't have to mess with LD LIBRARYPATH to get something in /usr/local working.

My Solaris experience tells me that anything requiring a change to LD LIBRARYPATH is going to cost at least $20,000 and run horribly.

It seems to me that, if this work has already been done, then why reinvent the wheel.

I certainly appreciate the ability to gain access to a vast resource pool of programs and information that is around in the UNIX world, but I'm struggling with understanding how it is supposed to work. Where ever you go, you come across GIT, RPM, Fink, MacPorts, and a variety of other systems that all try to solve this same problem so I can't be alone.

The only thing I don't like about Fink and MacPorts is that they use that strange /opt location. The Linux tools like RPM and portage use /usr/local. I would actually really like to have a package manager that kept track of all the open-source packages I've installed, as long as I was sure each installation was a vanilla installation identical to what I would have done by hand. Plus, the Linux tools have been around for a lot longer and are much more robust (and even they break things on a regular basis). Finally, I know you aren't alone. I see a fairly regular stream of people having problems with open-source tools they've installed using macports/fink. I try it on my system (without macports/fink) and it works perfectly. Not much else I can do in that case. They need to ask the macports/fink people for help.

All this still comes back to my original question: where can I get a 'beginner guide' to how the dynamic loader works, how should it work, what is expected of programs to make it work, what variations can be allowed and what should never be even thought of!

I don't think such a thing exists. There is probably a multi-volume 'expert guide' though.

I strongly suspect that the last time Mono worked on OS X was 2005. The core tools and dependencies have evolved since then, but nobody bothered to update it all for MacOS X. Apple threw Intel into the Mix and things don't work anymore. There maybe some hard-core Mono/OSX people who do know how to get it working, but I don't think they are on this discussion forum.

That si why I think the packaging software is a bit is a side issue. The only reason I mentioned it is to try to give you some idea of the context of my question (in other discussions I am often frustrated when someone asks a question but does not give enough context to answer it properly - I would rather be able to ignore information given to me than have to go back and ask for more information).

No problem. I would much rather have long, descriptive messages that the two-liners "I hacked it. It's broken. Can you fix it?" posts.

Sorry about the 'rant'. I really do appreciate the fact that you are trying to help me.

I like rants:) I will do what I can, but I don't think I'm really qualified. The sad fact is that the Mac just isn't as well supported in the open source world. The Linux situation isn't that much better, but it is different. There is always some existing Linux configuration that will work, it just may take you 8-9 tries. On MacOS X, the only working configuration may be the one that you hack up.

For example, there is a nice package (that shall remain nameless) that is supposed to give you the full power of Cocoa in Perl. I'm a big Perl fan so I jumped on it. The latest version was labelled "Now working on Intel Macs!" I found one particular function call that didn't work. I was puzzed and investigated. I worked several hours hacking things up trying to get this one particular function call (out of many) to work. My thinking was that is this one random function is broken, how many others are? Finally, at 2 in the morning I gave up and send an e-mail to the maintainer saying I found found what I thought was a bug, hoping he might know more. He responded right away with a message saying "Yes, it doesn't work on Intel Macs after all. It needs a different library."

I'm confident I could put that new library in and get it working, but I just have other things to do. I've spent too much time on it already. I'll just do my little tools in Objective-C for now and keep Cocoa out of Perl. That is my typical experience. So, if you are having trouble with a project that is much larger than the one I've described, you should probably contact the maintainers and see if it even works at all, and what you need to do to make it work.

One of the components needed is Mozilla and it builds (form the Macports port) correctly. However it places a .dylib in /opt/local/lib/mozilla-1.7.12/libgtkembedmoz.dylib and there are no links (hard or soft - at least as far as I can tell) to this file from somewhere else.

I'm just guessing (I have never built gtk-related things on MacOSX), but how about using "mozilla-devel" instead of "mozilla"?

I didn't read this carefully the first time. The reason there are no LINKS to the library is the path to the library is hard-coded in the binary (or else the DYLIDLIBRARYPATH is set in a wrapper shell script).