[CMake] new rpath support

Zachary Pincus zpincus at stanford.edu
Mon Feb 27 00:26:07 EST 2006


Thanks for the reply.

Here's what I'm trying to do in a cross-platform way, hopefully with  
cmake. I am creating several shared libraries (python modules,  
actually), which share some runtime code. Thus, each module needs to  
link to a secondary shared object that contains this runtime.

What are my options for making sure that when one of these python  
modules is loaded, the dynamic loader will be able to locate the  
shared runtime module? I see the following, of which (3) seems  
optimal, except that I'm not sure I can do that on windows.

The options:
(1) Set with PATH (win) or LD_LIBRARY_PATH (unix) environment  
variable to tell the loader where to look. This has to be done before  
the program starts, so the onus is on the user to make sure these are  
set right. That's a pain.

(2) Install the library to a standard location where the loader knows  
to look. This is /usr/lib or /usr/local/lib on unix. I'm not sure how  
to do this in windows -- does the dll go somewhere and the import  
library go somewhere else? Not sure. Anyhow, globally installing  
something seems nasty (and requires admin privileges).

(3) Install the library in a location with a known relative path to  
the python modules. On OS X, link the *runtime library* with an  
install_name containing this relative path. On other unix, link each  
*python module* with an rpath containing that relative path. (Is this  
right??) On windows... is this even possible?

Any help at all would be appreciated. This is all in furtherance of  
my work in getting shiny new updates to the ITK wrappers working.

Thanks again and in advance,
Zach




On Feb 26, 2006, at 7:46 PM, William A. Hoffman wrote:

> At 05:01 PM 2/26/2006, Zachary Pincus wrote:
>> Hi folks,
>>
>> A quick question about the support for adding custom rpaths (and on
>> darwin, install_names) to shared libraries that Brad is adding to  
>> CMake:
>>
>> Is there a windows equivalent to rpaths at all? Will dlls created
>> with these options also be loadable at that rpath? Or is it the case
>> taht on Windows there is no support for loading dll's from anywhere
>> but the executable's directory, or locations on PATH?
>
> Windows has no rpath, so there will be no support for it.
>
> -Bill
>
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake



More information about the CMake mailing list