Would the general cmake solution for find_program/find_library do
something like this:
dumpbin /headers {some.lib|some.dll|some.exe} | findstr "machine" ?
I get either AMD64 or x86 in the output from that.
If find_program did it right, then gp_resolve_item would give me the
right .dll file.
Clint
David Cole wrote:
On Mon, Jul 20, 2009 at 1:39 PM, Clinton Stimpson
<[email protected] <mailto:[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]>
<mailto:[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]>
<mailto:[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]>>
<mailto:[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>
<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>
<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
