mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-11-21 01:12:32 +08:00
caf606c90d
My previous nm patch handled all cases but one -- if the user set NM in the environment to a path which contained an option, libtool's nm detection tries to run nm against a copy of nm with the options in it: e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle". This is unlikely to be desirable: in this case we should run "/usr/bin/nm --blargle /usr/bin/nm". Furthermore, as part of this nm has to detect when the passed-in $NM contains a path, and in that case avoid doing a path search itself. This too was thrown off if an option contained something that looked like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run "nm -B../prev-gcc nm" which rarely works well (and indeed it looks to see whether that nm exists, finds it doesn't, and wrongly concludes that nm -p or whatever does not work). Fix all of these by clipping all options (defined as everything including and after the first " -") before deciding whether nm contains a path (but not using the clipped value for anything else), and then removing all options from the path-modified nm before looking to see whether that nm existed. NM=my-nm now does a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM=/usr/bin/my-nm now avoids a path search and runs e.g. /usr/bin/my-nm -B /usr/bin/my-nm NM="my-nm -p../wombat" now does a path search and runs e.g. /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search: ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm This seems to be all combinations, including those used by GCC bootstrap (which, before this commit, fails to bootstrap when configured --with-build-config=bootstrap-lto, because the lto plugin is now using --export-symbols-regex, which requires libtool to find a working nm, while also using -B../prev-gcc to point at the lto plugin associated with the GCC just built.) Regenerate all affected configure scripts. * libtool.m4 (LT_PATH_NM): Handle user-specified NM with options, including options containing paths. |
||
|---|---|---|
| .. | ||
| common | ||
| config | ||
| doc | ||
| gp-display-html | ||
| libcollector | ||
| src | ||
| testsuite | ||
| acinclude.m4 | ||
| aclocal.m4 | ||
| configure | ||
| configure.ac | ||
| Makefile.am | ||
| Makefile.in | ||
| README | ||
What is gprofng?
Gprofng is the GNU Next Generation profiler for analyzing the performance
of Linux applications. Gprofng allows you to:
- Profile C / C++ / Java / Scala applications without needing to recompile
- Profile multi-threaded applications
- Analyze and compare multiple experiments
- Use time-based sampling and / or hardware event counters
Building gprofng
Gprofng is distributed with binutils. To build gprofng, you build binutils.
Overview:
1. Set paths
2. Verify prerequisites
3. Git clone
4. Configure, make, and make install
Details follow for each of these.
1. Set paths
If you are configuring binutils for the default location, it will use:
/usr/local
In your shell initialization procedure, set your paths using commands
similar to these:
export PATH=/usr/local/bin:$PATH
export MANPATH=/usr/local/share/man:$MANPATH
export INFOPATH=/usr/local/share/info/:$INFOPATH
2. Verify prerequisites
To build a recent version of binutils, it is useful to have a developer
system with the most recent compilers, libraries, and operating system.
Development systems will typically already include most of these:
bison bison-devel bzip2 elfutils-debuginfod-client-devel
expat-devel flex gcc gcc-c++ git-core git-core-doc gmp-devel
help2man libbabeltrace-devel libipt-devel m4 make mpfr-devel
ncurses-devel perl-Data-Dumper tar texinfo xz zlib-devel
java-17-openjdk-devel
CAUTION: The list of prerequisites changes depending on your operating system
and changes as binutils evolves. The list above is a snapshot of the useful
packages in early 2022 for Red Hat Enterprise Linux and Oracle Linux.
Your system may use other packages; for example, you may be able to use a
different version of Java than shown above. If there are failures, you may
need to search for other packages as described in the "Hints" section below.
3. Git clone
Select a binutils repository and a branch that you would like
to start from. For example, to clone from the master at
sourceware.org, you could say:
git clone http://sourceware.org/git/binutils-gdb.git CloneDir
4. Configure, make, and install
There are many options for configure (see: configure --help). For example,
--prefix sets the destination, as described in the "Hints" section below.
If the default destination /usr/local is acceptable for your needs, then
after the clone operation finishes, you can simply say:
mkdir build
cd build
../CloneDir/configure
make
sudo make install
Getting started
To start using gprofng, see the tutorial available by saying:
info gprofng
Hints and tips for building binutils
- Use the script(1) command to write a log of your build.
- If you run multiple commands at once (for example: make --jobs=10) then you
should also use make option:
--output-sync
Without --output-sync, the log would be difficult to interpret.
- Search the log for errors and warnings, for example:
configure: WARNING: <package> is missing or unusable; some features
may be unavailable.
The above message suggests that <package> may be needed on your system.
- Sometimes the above message is not sufficiently specific to guide you to
the right package. In the directory where the failure happens, config.log
may identify a specific missing file, and your package manager may allow
you to search for it. For example, if build/gprofng/config.log shows that
javac is missing, and if your package manager is dnf, you could try:
dnf --repo='*' whatprovides '*/javac'
- You can set a custom destination directory using configure --prefix.
This is useful if you prefer not to change /usr/local, or if you are not
allowed to do so. If you set a custom prefix, be sure to change all three
paths mentioned in the PATH section above.