<div class="gmail_quote">On Mon, Jul 20, 2009 at 2:12 PM, Clinton Stimpson <span dir="ltr"><<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Would the general cmake solution for find_program/find_library do something like this:<br>
dumpbin /headers {some.lib|some.dll|some.exe} | findstr "machine" ?<br>
I get either AMD64 or x86 in the output from that.</blockquote><div><br></div><div>Yes. Or something that's equivalent... More likely something that's equivalent because I don't think a hard dependency on dumpbin to provide core cmake functionality is such a good idea.</div>
<div><br></div><div>But... it also has to know which one you want. That's the more difficult part of the problem. Either we have to add args to the signature of find_program that says "only give me 64-bit results" (or 32-bit) or we have to have a way to infer what a caller of find_program is looking for. Adding args everywhere is probably the only "real" solution -- inferring things is always a bit dicey.</div>
<div><br></div><div>It's also more general than Win32 / Win64 -- if you are doing "FIND_LIBRARY" stuff, you want the libraries found to match the architecture of the thing you're building. Same thing applies to 32/64 on Linux and Mac and even ppc/intel on Mac ... and cross compiling and ... It's just a can of worms we have not opened yet.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
If find_program did it right, then gp_resolve_item would give me the right .dll file.<br>
<br>
Clint<br>
<br>
David Cole wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>
On Mon, Jul 20, 2009 at 1:39 PM, Clinton Stimpson <<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> <mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>>> wrote:<br>
<br>
<br>
Thanks. Do you know if gp_resolve_item handles 64 and 32 bit<br>
binaries correctly on Windows?<br>
<br>
<br>
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...<br>
<br>
(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.)<br>
<br>
Keep up the good work! Sounds like you are making progress on this stuff... :-)<br>
<br>
<br>
David<br>
<br>
<br>
<br>
<br>
"dumpbin /dependents" is used and it doesn't return full paths<br>
like ldd does on Linux, or otool on Mac.<br>
I put both in my PATH, so I can run both 32 and 64 bit programs.<br>
I just wanted to make sure I was getting the right .dll when I<br>
copy it into my installation directory.<br>
<br>
Clint<br>
<br>
David Cole wrote:<br>
<br>
On Fri, Jul 17, 2009 at 6:48 PM, David Cole<br>
<<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a> <mailto:<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a>><br>
<mailto:<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a><br>
<mailto:<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a>>>> wrote:<br>
<br>
No. It's supposed to return the actual string that is<br>
referenced<br>
by the thing being analyzed. But you can call<br>
gp_resolve_item to<br>
get the full path... (There is a reason for this, although<br>
I can't<br>
remember what it is at the moment... If I think of it, I'll<br>
reply<br>
again.)<br>
<br>
<br>
I thought of/remembered the reason, so I'm replying again:<br>
<br>
The get_prerequisites function needs to return items exactly<br>
as they are referenced in the executable being analyzed such<br>
that ...... later on, the caller can use that string as an<br>
input to install_name_tool for replacing it with something<br>
like "@executable_path/...." -- if the item were returned<br>
resolved, then we would have to re-analyze the executable<br>
later to figure out which string in the otool output<br>
corresponds to the resolved item... (Or keep a map of them<br>
around, as is done in BundleUtilities...)<br>
<br>
<br>
<br>
From commentary in the middle of the get_prerequisites<br>
function:<br>
<br>
# Use the raw_item as the list entries returned by this<br>
function. Use the<br>
# gp_resolve_item function to resolve it to an actual full<br>
path file if<br>
# necessary.<br>
#<br>
set(item "${raw_item}")<br>
<br>
<br>
HTH,<br>
David<br>
<br>
<br>
On Fri, Jul 17, 2009 at 6:40 PM, Clinton Stimpson<br>
<<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> <mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>><br></div></div><div><div></div><div>
<mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> <mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>>>><br>
wrote:<br>
<br>
<br>
Is get_prerequisites() supposed to return absolute<br>
paths all<br>
the time?<br>
For example, on the Mac, I've got some frameworks in<br>
/Library/Frameworks that I may want to copy if they<br>
might not<br>
exist on other Macs. When I call get_prerequisites(),<br>
getting<br>
"foo.framwork/" instead of<br>
"/Library/Frameworks/foo.framework/"<br>
<br>
Clint<br>
<br>
David Cole wrote:<br>
<br>
So I would love to see a corollary to<br>
BundleUtilities.cmake for Mac on Windows and Linux,<br>
too.<br>
<br>
Using GetPrerequisites to gather the set of dependent<br>
files is obviously the first step.<br>
<br>
Then, on Windows, a function that installs all the<br>
dependent dlls to the same location as the executable<br>
would be awesome.<br>
<br>
On Linux, I guess you would have to make sure<br>
everything<br>
you depend on is either already installed in its<br>
install<br>
path, or aware of your install path, or uses<br>
LD_LIBRARY_PATH -- the issues here are the ones I<br>
am least<br>
familiar with (compared to Windows and Mac anyhow).<br>
<br>
I don't think this should ever be fully automated<br>
because<br>
of licensing and coyright issues. Technically, it<br>
is easy<br>
to gather the set of required files to make<br>
something work<br>
on a practical level. The issue will be: "hey,<br>
you're not<br>
allowed to copy *that* dll" because of such and such<br>
non-technical reason...<br>
<br>
Having said all this, and that I would love to see<br>
it, I<br>
must admit: it is not presently on the radar for<br>
any CMake<br>
developers as far as I know. So, as always: patches<br>
welcome. :-)<br>
<br>
<br>
HTH,<br>
David<br>
<br>
<br>
On Fri, Jul 17, 2009 at 3:05 PM, Clinton Stimpson<br>
<<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> <mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>><br>
<mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a> <mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>>><br>
<mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a><br>
<mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>><br>
<br>
<mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a><br>
<mailto:<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>>>>> wrote:<br>
<br>
So I'm using GetPrequisites.cmake to gather<br>
dependencies.<br>
Are there any examples, tips, etc.. for using this?<br>
<br>
With the results I'm getting back, I do a<br>
file(INSTALL ... ) because that's what I see in the<br>
cmake_installcmake file. Should it be documented?<br>
But these files I'm getting back are soft links<br>
to the real<br>
library. And the file(INSTALL ... ) just puts a<br>
softlink in my<br>
installation directory instead of a real library.<br>
<br>
Is there some higher level cmake function I<br>
should be<br>
calling to<br>
install libraries on Unix/Linux, similar to how<br>
there is<br>
BundleUtilties.cmake for Mac? Or ideally, is<br>
there one<br>
function I<br>
can use on all platforms to install some<br>
prerequisites?<br>
<br>
Thanks,<br>
Clint<br>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>> <<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>><br>
<<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>><br>
<br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the<br>
CMake FAQ at:<br>
<a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a> <<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>><br>
<<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at:<br>
<a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
<br>
<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote></div><br>