aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorGuy Harris <guy@alum.mit.edu>2015-01-19 16:47:55 -0800
committerGuy Harris <guy@alum.mit.edu>2015-01-20 00:49:01 +0000
commitc3ad53f9ad9c060a7079c0f8f93f3e99af5c77af (patch)
treed345c0a28d8bf057fc6c7295964491d303596cc7
parent7c69079fb9fbffeb62271bd1d9f34a561b9b5117 (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.cmake20
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.)