| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Solaris output is the following:
```
$ ldd /lib/libxml2.so
libz.so.1 => /lib/libz.so.1
libm.so.2 => /lib/libm.so.2
libc.so.1 => /lib/libc.so.1
```
While on Linux
```
$ ldd /usr/lib/libxml2.so
linux-vdso.so.1 (0x00007ffe02bbe000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f03ab852000)
libicuuc.so.64 => /usr/lib/libicuuc.so.64 (0x00007f03ab67a000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f03ab463000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f03ab23d000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f03ab0f7000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f03aaf34000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f03ab9fd000)
libicudata.so.64 => /usr/lib/libicudata.so.64 (0x00007f03a94ee000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f03a94cd000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f03a92e5000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f03a92cb000)
```
|
| | |
|
| |
|
|
|
| |
GetPrerequisites has now been superceded by file(GET_RUNTIME_DEPENDENCIES),
so add a deprecation notice stating such.
|
| |
|
|
|
|
| |
The `item` variable was the loop variable in the old code prior to
commit 3dfc8b9bd6 (GetPrerequisites: use if(IN_LIST) instead of foreach,
2019-05-09). The function argument `value` should be used instead.
|
| | |
|
| |
|
|
| |
Fixes: #18667
|
| |
|
|
| |
e.g. for cross-compilation with e.g. x86_64-pc-linux-gnu-ldd
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes: #16828
|
| |
|
|
|
| |
This commit removes hardcoded paths that are already given in the
platform files or in `UnixPath` on a global level.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to commit v3.4.0-rc1~264^2~1 (GetPrerequisites: Add error checks
for execute_process() calls, 2015-07-29), `get_prerequisites` would
simply warn on a missing binary and not update the result list at all.
That commit accidentally made the case an error. This was fixed by
commit v3.8.0-rc1~110^2 (GetPrerequisites: Do not fail on files we
cannot find, 2017-01-10), but the fix also cleared the result list.
Clearing the list is incorrect because it is supposed to be able to
accumulate results over multiple calls.
Remove the list clearing behavior to restore the original behavior on a
missing binary.
Fixes: #17306
|
| |
|
|
| |
Issue: #17007
|
| |
|
|
|
|
|
|
| |
I encountered an issue where not all prerequisites would be listed by
`get_prerequisites` since some of the prerequisites cannot be resolved
and are added to the list of unseen prerequisites. This has the side
effect of clearing the list of `prerequisites_var` and thus removes some
prerequisites from the list. Fix it.
|
| |
|
|
|
| |
Update hard-coded library paths in bundled CMake Modules for libx32 as
used with x32-abi.
|
| |
|
|
| |
Fixes #16625.
|
| |\
| |
| |
| |
| | |
a7c5d5fb GetPrerequisites: Exclude delay load dependencies on Windows
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With some Windows toolchains we use `objdump` which does not mention
delay load dependencies in its output. Therefore, to get consistent
behavior we should always ignore them.
Use the `dumpbin` message "Image has the following delay load
dependencies" that precedes the delay load dependencies to recognize and
skip them. Fortunately, this message is not translated to the current
locale (at least on "Windows 7 French", "Windows 10 French" and "Windows
Server 2008 R2 French").
Fixes: #16241
|
| |/
|
|
|
|
|
|
|
|
|
| |
Historically we have always warned and skipped missing files. Since
commit v3.4.0-rc1~264^2~1 (GetPrerequisites: Add error checks for
execute_process() calls, 2015-07-29) we fail instead, but this was not
an intentional part of that change. Restore the warn-only behavior so
that missing system libraries (e.g. during cross-compiling) do not cause
failure.
Closes: #16523
|
| |
|
|
|
| |
`find_program` does not work with `${a};${b}` as a search path.
Use separate arguments to `PATHS`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
|
| |
|
|
|
|
|
|
|
|
| |
The matching expression added by commit v3.5.0-rc1~33^2
(GetPrerequisites: Define api-ms-win-* files as system libraries,
2016-01-19) did not account for absolute paths to the UCRT libraries.
We already recognize absolute paths to the MSVC runtime libraries.
Do this for UCRT libraries too.
Issue: #16240
|
| |\
| |
| |
| |
| | |
a2d5c25a GetPrerequisites: Fix regression in gp_resolved_file_type
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit v3.6.0-rc1~287^2 (GetPrerequisites: Fix
gp_resolved_file_type on non-canonical paths, 2016-03-08) we
accidentally convert relative paths (e.g. system dll file names) to
absolute paths even when we do not know the base directory. Fix this by
canonicalizing only paths that are already absolute.
Closes: #16240
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
When using `grep` to filter the output, add the `-a` flag to tell
it never to treat the output as binary. Otherwise when LANG != C
in the environment the non-ascii text may break the filter.
|
| | |
| |
| |
| |
| |
| |
| | |
Automate with:
find Modules -type f -print0 | xargs -0 perl -i -0pe \
's/set\(([a-zA-Z0-9_]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'
|
| | | |
|
| |/
|
|
|
|
| |
Extend the optimization from commit v3.4.0-rc1~264^2 (GetPrerequisites:
Optionally filter "objdump" output for speed, 2015-07-29) to work
on Windows by using `findstr` in place of `grep`.
|
| | |
|
| |
|
|
|
|
| |
The `VS*COMNTOOLS` environment variables specify locations of VS tools
and are set during the VS installation. Use them in addition to the
hard-coded default install locations.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Canonicalize the input paths so we treat them both consistently,
in particular when comparing them via string operations. This
is needed for calls like
fixup_bundle("${CMAKE_INSTALL_PREFIX}/../test" ...)
Suggested-by: Benjamin Ballet <bballet@ivsweb.com>
|
| |
|
|
| |
Suggested-by: Gilles Khouzam <gillesk@microsoft.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As dumpbin.exe is no longer reliable for gcc libraries on MinGW because
it crashes on many common libraries like libgcc_s and libgfortran it is
now necessary too resort to using objdump for DLL dependency walking.
Using objdump has a secondary problem in that it generates a lot of
output for large libraries and causes fixup_bundle() to take many
minutes to process what took fractions of a second with
"dumpbin.exe /dependents".
Add a 'grep' pre-filter in the execute_process() command pipeline to
reduce this output to a minimum for a several orders of magnitude speed
up. If grep is not available just use the full output.
As there does not seem to be a reliable way of detecting MinGW, callers
of fixup_bundle() may have to set the variable gp_tool to "objdump" if
dumpbin.exe is installed on the build machine to stop it using the
broken MS dumpbin.exe for library dependency walking.
|
| |
|
|
|
| |
Add return status checks to external command invocations so that they do
not fail silently producing incomplete install packages.
|
| |
|
|
| |
ARGV# could be defined from a parent scope.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Detect PIE binaries with newer 'file' (5.22). It no longer prints
"(uses shared libraries)" but does print "interpreter":
# file 5.19
$ file /usr/bin/su
/usr/bin/su: ... shared object, ..., dynamically linked (uses shared libs), ...
# file 5.22
$ file /usr/bin/su
/usr/bin/su: ... shared object, ..., dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, ...
|
| |
|
|
|
|
| |
These all test the same variable for different values, so only one of them can
ever be true. This also allows to completely remove one variable that only
flagged if one of the conditions matched.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done by gathering LC_RPATH commands for main bundle executable and
using it for @rpath lookup in dependent frameworks.
All functions that need to carry rpaths to now take optional <rpaths> argument.
This enabled apps using @rpath to be bundled correctly, which will be necessary
for upcoming Qt 5.4 that will use @rpath for all frameworks.
Check that install_name_tool has -delete_rpath before using it.
Otherwise it will fail with Xcode 3.x on 10.5 which has no -delete_rpath
option for install_name_tool command, that was first introduced in 10.6
SDK, even that 10.5 supports LC_RPATH and @rpath.
|
| |
|
|
|
| |
Mac OS X dyld placeholders should be always prefixes, otherwise this can lead
to some undefined behavior.
|
| |
|
|
| |
The simple replacement is much faster.
|
| | |
|
| |
|
|
|
|
|
|
| |
Run the convert-help.bash script to convert documentation:
./convert-help.bash "/path/to/CMake-build/bin"
Then remove it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VS IDE sets the environment variable VS_UNICODE_OUTPUT when
executing build rules in order to tell MS tools to report output through
a back door instead of through stdout/stderr. Unset this variable so
that CMake can capture or properly redirect all output from processes it
runs even when running inside a VS IDE build environment.
This generalizes the special cases fixed by commit 80d045b0 (When
GetPrerequisites.cmake runs dumpbin while running inside the VS IDE...,
2008-05-01) and commit 44aff73d (ExternalProject: Avoid bleed-through
output when logging, 2011-01-06), so drop special handling of
VS_UNICODE_OUTPUT in those instances.
|
| |
|
|
| |
Signed-off-by: Michael Tänzer <neo@nhng.de>
|
| |
|
|
|
|
| |
Make it usable on MinGW without Visual Studio installed.
Signed-off-by: Michael Tänzer <neo@nhng.de>
|
| |
|
|
|
|
| |
Make them usable in the gp_tool selection heuristic.
Signed-off-by: Michael Tänzer <neo@nhng.de>
|
