361cb21935
An issue was reported here related to building GDB on MinGW: https://sourceware.org/pipermail/gdb/2020-September/048927.html It was suggested here: https://sourceware.org/pipermail/gdb/2020-September/048931.html that the solution might be to make use of $(LIB_GETRANDOM), a variable defined in the gnulib makefile, when linking GDB. In fact I think the issue is bigger than just LIB_GETRANDOM. When using the script binutils-gdb/gnulib/update-gnulib.sh to reimport gnulib there is a lot of output from gnulib's gnulib-tool. Part of that output is this: You may need to use the following makefile variables when linking. Use them in <program>_LDADD when linking a program, or in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library. $(FREXPL_LIBM) $(FREXP_LIBM) $(INET_NTOP_LIB) $(LIBTHREAD) $(LIB_GETLOGIN) $(LIB_GETRANDOM) $(LIB_HARD_LOCALE) $(LIB_MBRTOWC) $(LIB_SETLOCALE_NULL) $(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise What I think this is telling us is that we should be including the value of all these variables on the link line for gdb and gdbserver. The problem though is that these variables are define in gnulib's makefile, but are not (necessarily) defined in GDB's makefile. One solution would be to recreate the checks that gnulib performs in order to recreate these variables in both gdb's and gdbserver's makefile. Though this shouldn't be too hard, most (if not all) of these checks are in the form macros defined in m4 files in the gnulib tree, so we could just reference these as needed. However, in this commit I propose a different solution. Currently, in the top level makefile, we give gdb and gdbserver a dependency on gnulib. Once gnulib has finished building gdb and gdbserver can start, these projects then have a hard coded (relative) path to the compiled gnulib library in their makefiles. In this commit I extend the gnulib configure script to install a new makefile fragment in the gnulib build directory. This new file will have the usual variable substitutions applied to it, and so can include the complete list (see above) of all the extra libraries that are needed when linking against gnulib. In fact the new makefile fragment defines three variables, these are: LIBGNU: The path to the archive containing gnulib. Can be used as a dependency as when this file changes gdb/gdbserver should be relinked. LIBGNU_EXTRA_LIBS: A list of linker -l.... flags that should be included in the link line of gdb/gdbserver. These are libraries that $(LIBGNU) depends on. This list is taken from the output of gnulib-tool, which is run by our gnulib/update-gnulib.sh script. INCGNU: A list of -I.... include paths that should be passed to the compiler, these are where the gnulib headers can be found. Now both gdb and gdbserver can include the makefile fragment and make use of these variables. The makefile fragment relies on the variable GNULIB_BUILDDIR being defined. This is checked for in the fragment, and was already defined in the makefiles of gdb and gdbserver. gdb/ChangeLog: * Makefile.in: Include Makefile.gnulib.inc. Don't define LIBGNU or INCGNU. Make use of LIBGNU_EXTRA_LIBS when linking. gdbserver/ChangeLog: * Makefile.in: Include Makefile.gnulib.inc. Don't define LIBGNU or INCGNU. Make use of LIBGNU_EXTRA_LIBS when linking. gnulib/ChangeLog: * Makefile.gnulib.inc.in: New file. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Install the new file.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.