diff options
author | Guy Harris <guy@alum.mit.edu> | 2015-01-19 16:47:55 -0800 |
---|---|---|
committer | Guy Harris <guy@alum.mit.edu> | 2015-01-20 00:49:01 +0000 |
commit | c3ad53f9ad9c060a7079c0f8f93f3e99af5c77af (patch) | |
tree | d345c0a28d8bf057fc6c7295964491d303596cc7 | |
parent | 7c69079fb9fbffeb62271bd1d9f34a561b9b5117 (diff) |
Fix one item.
We *do* get the absolute path of the executable, so we *could* look for
"run" right before the executable name. The issue is that there's not
the stronger libtool-imposed convention that the executable is in
".libs", so the chances of a false positive or false negative are
higher.
Change-Id: Ib2d5f370d50fee07479c4ffe6f90ba4a91c7f271
Reviewed-on: https://code.wireshark.org/review/6676
Reviewed-by: Guy Harris <guy@alum.mit.edu>
-rw-r--r-- | README.cmake | 20 |
1 files changed, 13 insertions, 7 deletions
diff --git a/README.cmake b/README.cmake index 8b7a0cf188..33481efcf8 100644 --- a/README.cmake +++ b/README.cmake @@ -170,14 +170,20 @@ What needs to be done? itself. autofoo includes libtool in our case, so what you're running from the build directory is a script that then runs the executable, and the executable is in a .libs directory; the code that checks for - "running from the build directory?" checks for that. - - We could perhaps check for the pathname containing "run/", although - that wouldn't help if we ran it while *in* the "run" directory; - getting an absolute path for the executable would be necessary for - that. + "running from the build directory?" checks for that. The actual + executable isn't supposed to be run directly - it's expected to be run + by the wrapper script and might not even work if run directly, as it + won't find the relevant shared libraries. + + We could perhaps check for the executable being in a "run" directory + instead, if the build drops it there. However, it might be possible + to copy the executable to another directory and have it run, so the + guarantee that it's in a "run" directory might not be as strong. - Get plugins loading when running *shark from the build directory. - That might involve handling ".libs" and "run" differently. + That might involve handling ".libs" and "run" differently. The chance + that a random directory the executable was ultimately placed in would + be named "run" might also be a bit bigger than the chance that it's + named ".libs". - Get cross-compilation working (or ensure it does). It works with autofoo. - Handle -DFORTIFY_SOURCE=2 appropriately. (Do a Web search for "cmake fortify" for some information.) |