On Mon, Jul 20, 2009 at 1:39 PM, Clinton Stimpson <[email protected]>wrote:
> > Thanks. Do you know if gp_resolve_item handles 64 and 32 bit binaries > correctly on Windows? Definitely not. On Windows, it uses find_program to find the dlls in the PATH or in a list of directories provided by the caller... This is only based on dll name, so it could potentially return improper results (with respect to 32- and 64-bit dlls). You can either: fix gp_resolve_item to consider the bit-ness of the result, or provide a cmake function named "gp_resolve_item_override" in which you deliver the result in your own code. Preferably, add code to gp_resolve_item to match the bit-ness of the result with the bit-ness of the input... (Personally, I would really like to see a general CMake solution to the problem of matching library bit-ness for Win32 and Win64 uses of find_library / find_program.... That may be a bit beyond the scope of what you're hoping to achieve here though.) Keep up the good work! Sounds like you are making progress on this stuff... :-) David > > "dumpbin /dependents" is used and it doesn't return full paths like ldd > does on Linux, or otool on Mac. > I put both in my PATH, so I can run both 32 and 64 bit programs. I just > wanted to make sure I was getting the right .dll when I copy it into my > installation directory. > > Clint > > David Cole wrote: > >> On Fri, Jul 17, 2009 at 6:48 PM, David Cole <[email protected]<mailto: >> [email protected]>> wrote: >> >> No. It's supposed to return the actual string that is referenced >> by the thing being analyzed. But you can call gp_resolve_item to >> get the full path... (There is a reason for this, although I can't >> remember what it is at the moment... If I think of it, I'll reply >> again.) >> >> >> I thought of/remembered the reason, so I'm replying again: >> >> The get_prerequisites function needs to return items exactly as they are >> referenced in the executable being analyzed such that ...... later on, the >> caller can use that string as an input to install_name_tool for replacing it >> with something like "@executable_path/...." -- if the item were returned >> resolved, then we would have to re-analyze the executable later to figure >> out which string in the otool output corresponds to the resolved item... (Or >> keep a map of them around, as is done in BundleUtilities...) >> >> >> >> >> From commentary in the middle of the get_prerequisites function: >> >> # Use the raw_item as the list entries returned by this >> function. Use the >> # gp_resolve_item function to resolve it to an actual full >> path file if >> # necessary. >> # >> set(item "${raw_item}") >> >> >> HTH, >> David >> >> >> On Fri, Jul 17, 2009 at 6:40 PM, Clinton Stimpson >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> Is get_prerequisites() supposed to return absolute paths all >> the time? >> For example, on the Mac, I've got some frameworks in >> /Library/Frameworks that I may want to copy if they might not >> exist on other Macs. When I call get_prerequisites(), getting >> "foo.framwork/" instead of "/Library/Frameworks/foo.framework/" >> >> Clint >> >> David Cole wrote: >> >> So I would love to see a corollary to >> BundleUtilities.cmake for Mac on Windows and Linux, too. >> >> Using GetPrerequisites to gather the set of dependent >> files is obviously the first step. >> >> Then, on Windows, a function that installs all the >> dependent dlls to the same location as the executable >> would be awesome. >> >> On Linux, I guess you would have to make sure everything >> you depend on is either already installed in its install >> path, or aware of your install path, or uses >> LD_LIBRARY_PATH -- the issues here are the ones I am least >> familiar with (compared to Windows and Mac anyhow). >> >> I don't think this should ever be fully automated because >> of licensing and coyright issues. Technically, it is easy >> to gather the set of required files to make something work >> on a practical level. The issue will be: "hey, you're not >> allowed to copy *that* dll" because of such and such >> non-technical reason... >> >> Having said all this, and that I would love to see it, I >> must admit: it is not presently on the radar for any CMake >> developers as far as I know. So, as always: patches >> welcome. :-) >> >> >> HTH, >> David >> >> >> On Fri, Jul 17, 2009 at 3:05 PM, Clinton Stimpson >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] >> >> <mailto:[email protected]>>> wrote: >> >> So I'm using GetPrequisites.cmake to gather dependencies. >> Are there any examples, tips, etc.. for using this? >> >> With the results I'm getting back, I do a >> file(INSTALL ... ) because that's what I see in the >> cmake_installcmake file. Should it be documented? >> But these files I'm getting back are soft links to the real >> library. And the file(INSTALL ... ) just puts a >> softlink in my >> installation directory instead of a real library. >> >> Is there some higher level cmake function I should be >> calling to >> install libraries on Unix/Linux, similar to how there is >> BundleUtilties.cmake for Mac? Or ideally, is there one >> function I >> can use on all platforms to install some prerequisites? >> >> Thanks, >> Clint >> >> _______________________________________________ >> Powered by www.kitware.com <http://www.kitware.com> >> <http://www.kitware.com> >> >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake >> >> >> >> _______________________________________________ >> Powered by www.kitware.com <http://www.kitware.com> >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake >> >> >> >> >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
