The Mach-O linker, used on Mac OS X, does not understand -R<directory> (actually
-rpath). Bugpoint wants to use it to link in shared libraries in the current
directory. It is unclear whether an equivalent option exists, though you can
specify the full pathnames of specific dynamic libraries on the command line for
what appears to be the same effect (not completely sure about this.)

This is really a problem in lib/Support/ToolRunner.cpp.

Note that to implement this, we should have an autoconf test to determine what
the appropriate flags are to pass into the linker.  Alternatively, perhaps we
can use (gasp in fear) libtool to do this for us.

I'm adding John to the CC line, as he's the resident guru on this type stuff
(though he might be afraid to admit it :)

-Chris 

What Chris means is, in ToolRunner.cpp:302 we have, in GCC::ExecuteProgram():

  GCCArgs.push_back("-Wl,-R.");            // Search this dir for .so files

Since we are already passing the names of the shared libraries to gcc,
perhaps it would suffice simply to
1) pass the names of the shared libraries as full pathnames, and
2) avoid adding the -Wl,-R. option, #ifndef HAVE_GCC_RPATH_OPTION.

-> me, because I have the test machine. :-)

That won't work.  The program will link just fine, but the resultant program
will not work unless '.' is in the LD_LIBRARY_PATH.

-Chris

I think it's the passing of the full path to the library that performs the
equivalent magic on Mac OS X, but I'll test that out to make sure.

As a first step, we'll need an autoconf test for whether a program will link
successfully with "-Wl,-R.".

I checked in additions to the configure script to define HAVE_LINK_R if the
linker supports the -R option.  Would someone be able to give this a spin on Darwin?

Bugpoint no longer passes -R to the linker, so this bug is technically fixed.
If I figure out that something is wrong with the shared library support 
(and there probably is something wrong with it), I will open a separate bug for
that issue. Thanks for your help guys.