>Eric Lemings wrote:
>
>> Travis Vitek wrote:
>>
>> Is this something that we want?
>
>Yeah after futher deliberation, I think you're right.
>We probably don't want to specify the full path name
>and either omit the path altogether or use the
>@executable_path form.
>
>Question though. Is the STDCXX library relocatable (in terms
>of install directory) on other platforms?
Yes. If the platform requires that the library be available at the
location provided to -rpath, then the path that the library is at when
the application is build must remain the same, but I believe that most
platforms fall back to LD_LIBRARY_PATH (or equivalent) if the library is
not found in the directory specified with -rpath.
Martin may have more information on this.
>I do know that Darwin/MacOS X packages ("bundles" they're called) are
>installed and work quite a bit differently than most other Unix OSes.
>On most Unix systems, hypothetical package `Foo` distributed with
>install files `bin/foo`, `lib/libfoo.so`, and `include/foo.h` are
>usually installed in /usr or /usr/local (or some other standard
>location) along with many other package files. The equivalent package
>on Darwin/MacOS X would be installed in its own package directory: e.g.
>`/Applications/Foo/bin/foo`, `/Applications/Foo/lib/libfoo.so` (with a
>.dylib link), and `/Applications/Foo/include/foo.h`.
>
Bundles are essentially application installs. The include the
application and any resources [libraries, headers, images, ...] that
they are intended to work with. When dealing with an application
installation it makes a little sense to require that the library is in a
specific location or relative to the executable. It appears to be an
attempt to avoid the unix version of 'dll hell' where multiple versions
of the same library have to coexist.
Travis
>Brad.
>
