* Re: gdb/gnulib problems with BSD operating systems [not found] <32726.6318876811$1333031278@news.gmane.org> @ 2012-03-30 20:35 ` Tom Tromey 2012-03-30 21:35 ` Joel Brobecker 0 siblings, 1 reply; 11+ messages in thread From: Tom Tromey @ 2012-03-30 20:35 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Pierre> gmake all-gdb Pierre> fails in Pierre> build/gdb/gnulib Pierre> This seems to come from the fact that Pierre> build/gdb/gnulib/Makefile Pierre> contains a line with Pierre> MAKE = make Pierre> so that despite being calls from gmake, Pierre> it calls BSD style make executable Pierre> that doesn't know how to handle some GNU specific stuff. Pierre> Is this an error in the configure script of GDB, Pierre> or should I specify which make I intent to use Pierre> differently? Try adding MAKE to FLAGS_TO_PASS in gdb/Makefile. I suspect that would help. Otherwise, you can tell configure that you plan to use gmake, like ".../configure MAKE=gmake". That will write the proper value into the various Makefiles. (But you shouldn't have to do this.) Tom ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb/gnulib problems with BSD operating systems 2012-03-30 20:35 ` gdb/gnulib problems with BSD operating systems Tom Tromey @ 2012-03-30 21:35 ` Joel Brobecker 2012-03-30 22:07 ` Joel Brobecker 0 siblings, 1 reply; 11+ messages in thread From: Joel Brobecker @ 2012-03-30 21:35 UTC (permalink / raw) To: Tom Tromey; +Cc: Pierre Muller, gdb > Otherwise, you can tell configure that you plan to use gmake, like > ".../configure MAKE=gmake". That will write the proper value into the > various Makefiles. (But you shouldn't have to do this.) This one doesn't work, as far as I can tell. Pierre and I both tried it two different ways, and configure still replaces @MAKE@ by make in gnulib/Makefile :-( (a bug, if you ask me, just don't know where). -- Joel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb/gnulib problems with BSD operating systems 2012-03-30 21:35 ` Joel Brobecker @ 2012-03-30 22:07 ` Joel Brobecker 2012-03-31 12:08 ` Pierre Muller [not found] ` <37068.5830399909$1333195740@news.gmane.org> 0 siblings, 2 replies; 11+ messages in thread From: Joel Brobecker @ 2012-03-30 22:07 UTC (permalink / raw) To: Tom Tromey; +Cc: Pierre Muller, gdb > > Otherwise, you can tell configure that you plan to use gmake, like > > ".../configure MAKE=gmake". That will write the proper value into the > > various Makefiles. (But you shouldn't have to do this.) > > This one doesn't work, as far as I can tell. Pierre and I both > tried it two different ways, and configure still replaces @MAKE@ > by make in gnulib/Makefile :-( (a bug, if you ask me, just don't > know where). I researched this a little bit, and I figured out why it did not work for me. I was calling configure with MAKE=gmake, but that has not effect because the top-level configure does not set MAKE. So, when I ran "make" (instead of gmake), it just implicitly set the MAKE variable to "make" rather than "gmake", and then calls our configure script passing that implicit MAKE=make value, which is not what Pierre wants. On the other hand, if I do (on x86_64-linux): % /path/to/gdb/configure % /home/brobecke/gmake Here is what I find in gnulib's Makefile: MAKE = /home/brobecke/gmake In other words, it should work out of the box without having to set anything by hand, as long as you use gmake as the top-level make program. -- Joel ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: gdb/gnulib problems with BSD operating systems 2012-03-30 22:07 ` Joel Brobecker @ 2012-03-31 12:08 ` Pierre Muller 2012-03-31 18:17 ` Pierre Muller [not found] ` <24504.7532058836$1333217860@news.gmane.org> [not found] ` <37068.5830399909$1333195740@news.gmane.org> 1 sibling, 2 replies; 11+ messages in thread From: Pierre Muller @ 2012-03-31 12:08 UTC (permalink / raw) To: 'Joel Brobecker', 'Tom Tromey'; +Cc: gdb > -----Message d'origine----- > De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la part > de Joel Brobecker > Envoyé : samedi 31 mars 2012 00:08 > À : Tom Tromey > Cc : Pierre Muller; gdb@sourceware.org > Objet : Re: gdb/gnulib problems with BSD operating systems > > > > Otherwise, you can tell configure that you plan to use gmake, like > > > ".../configure MAKE=gmake". That will write the proper value into the > > > various Makefiles. (But you shouldn't have to do this.) > > > > This one doesn't work, as far as I can tell. Pierre and I both > > tried it two different ways, and configure still replaces @MAKE@ > > by make in gnulib/Makefile :-( (a bug, if you ask me, just don't > > know where). > > I researched this a little bit, and I figured out why it did not > work for me. I was calling configure with MAKE=gmake, but that has > not effect because the top-level configure does not set MAKE. > So, when I ran "make" (instead of gmake), it just implicitly set > the MAKE variable to "make" rather than "gmake", and then calls > our configure script passing that implicit MAKE=make value, which > is not what Pierre wants. > > On the other hand, if I do (on x86_64-linux): > > % /path/to/gdb/configure > % /home/brobecke/gmake > > Here is what I find in gnulib's Makefile: > > MAKE = /home/brobecke/gmake > > In other words, it should work out of the box without having to > set anything by hand, as long as you use gmake as the top-level > make program. You are right, do a simple gmake does work. However, I am used to do gmake all-gdb and I checked by removing everything it does fail if you use gmake all-gdb instead of gmake ... Pierre Muller GDB pascal language maintainer ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: gdb/gnulib problems with BSD operating systems 2012-03-31 12:08 ` Pierre Muller @ 2012-03-31 18:17 ` Pierre Muller [not found] ` <24504.7532058836$1333217860@news.gmane.org> 1 sibling, 0 replies; 11+ messages in thread From: Pierre Muller @ 2012-03-31 18:17 UTC (permalink / raw) To: 'Pierre Muller', 'Joel Brobecker', 'Tom Tromey' Cc: gdb > > % /path/to/gdb/configure > > % /home/brobecke/gmake > > I was wondering if the fact of adding a full path could have an influence. So I tested 4 variants (on GDB-7.4 sources) Variant 1) Using just 'gmake' Variant 2) Using '/usr/local/bin/gmake' Variant 3) Using 'gmake all-gdb' Variant 4) Using '/usr/local/bin/gmake all-gdb' Clearly, only variants 1 and 2 complete successfully, while variants using all-gdb do have MAKE = make instead of MAKE = 'gmake as called, i.e. with or without path' There are differences in the gdb/Makefile's (see below) but I have no idea if this explains the failure with all-gdb target. Pierre Muller GDB pascal language maintainer [pierre@freelove832 ~]$ diff -c test-gmake/gdb/Makefile test-gmake-all-gdb/gdb/Makefile *** test-gmake/gdb/Makefile Sat Mar 31 08:38:04 2012 --- test-gmake-all-gdb/gdb/Makefile Sat Mar 31 08:43:46 2012 *************** *** 55,62 **** LN_S = ln -s INSTALL = /usr/bin/install -c ! INSTALL_PROGRAM = /usr/bin/install -c ! INSTALL_DATA = /usr/bin/install -c -m 644 DESTDIR = --- 55,62 ---- LN_S = ln -s INSTALL = /usr/bin/install -c ! INSTALL_PROGRAM = ${INSTALL} ! INSTALL_DATA = ${INSTALL} -m 644 DESTDIR = *************** *** 107,113 **** YLWRAP = $(srcdir)/../ylwrap # where to find makeinfo, preferably one designed for texinfo-2 ! MAKEINFO = makeinfo --split-size=5000000 MAKEINFOFLAGS = --split-size=5000000 MAKEINFO_EXTRA_FLAGS = MAKEINFO_CMD = $(MAKEINFO) $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS) --- 107,113 ---- YLWRAP = $(srcdir)/../ylwrap # where to find makeinfo, preferably one designed for texinfo-2 ! MAKEINFO = makeinfo MAKEINFOFLAGS = --split-size=5000000 MAKEINFO_EXTRA_FLAGS = MAKEINFO_CMD = $(MAKEINFO) $(MAKEINFOFLAGS) $(MAKEINFO_EXTRA_FLAGS) *************** *** 2197,2217 **** # simpler scheme. # ! ifeq ($(DEPMODE),depmode=gcc3) # Note that we put the dependencies into a .Tpo file, then move them # into place if the compile succeeds. We need this because gcc does # not atomically write the dependency output file. ! override COMPILE.post = -c -o $@ -MT $@ -MMD -MP \ ! -MF $(DEPDIR)/$(basename $(@F)).Tpo ! override POSTCOMPILE = @mv $(DEPDIR)/$(basename $(@F)).Tpo \ ! $(DEPDIR)/$(basename $(@F)).Po ! else ! override COMPILE.pre = source='$<' object='$@' libtool=no \ ! DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC) # depcomp handles atomicity for us, so we don't need a postcompile # step. ! override POSTCOMPILE = ! endif # A list of all the objects we might care about in this build, for # dependency tracking. --- 2197,2217 ---- # simpler scheme. # ! #ifeq ($(DEPMODE),depmode=gcc3) # Note that we put the dependencies into a .Tpo file, then move them # into place if the compile succeeds. We need this because gcc does # not atomically write the dependency output file. ! #override COMPILE.post = -c -o $@ -MT $@ -MMD -MP \ ! # -MF $(DEPDIR)/$(basename $(@F)).Tpo ! #override POSTCOMPILE = @mv $(DEPDIR)/$(basename $(@F)).Tpo \ ! # $(DEPDIR)/$(basename $(@F)).Po ! #else ! #override COMPILE.pre = source='$<' object='$@' libtool=no \ ! # DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC) # depcomp handles atomicity for us, so we don't need a postcompile # step. ! #override POSTCOMPILE = ! #endif # A list of all the objects we might care about in this build, for # dependency tracking. *************** *** 2221,2233 **** # Ensure that generated files are created early. Use order-only # dependencies if available. They require GNU make 3.80 or newer, # and the .VARIABLES variable was introduced at the same time. ! ifdef .VARIABLES ! $(all_object_files): | $(generated_files) ! else $(all_object_files) : $(generated_files) ! endif # Dependencies. ! -include $(patsubst %.o, $(DEPDIR)/%.Po, $(all_object_files)) ### end of the gdb Makefile.in. --- 2221,2233 ---- # Ensure that generated files are created early. Use order-only # dependencies if available. They require GNU make 3.80 or newer, # and the .VARIABLES variable was introduced at the same time. ! #ifdef .VARIABLES ! #$(all_object_files): | $(generated_files) ! #else $(all_object_files) : $(generated_files) ! #endif # Dependencies. ! #-include $(patsubst %.o, $(DEPDIR)/%.Po, $(all_object_files)) ### end of the gdb Makefile.in. ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <24504.7532058836$1333217860@news.gmane.org>]
* Re: gdb/gnulib problems with BSD operating systems [not found] ` <24504.7532058836$1333217860@news.gmane.org> @ 2012-04-02 14:18 ` Tom Tromey 2012-04-05 9:44 ` Pierre Muller 0 siblings, 1 reply; 11+ messages in thread From: Tom Tromey @ 2012-04-02 14:18 UTC (permalink / raw) To: Pierre Muller; +Cc: 'Joel Brobecker', gdb >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Pierre> There are differences in the gdb/Makefile's (see below) Pierre> but I have no idea if this explains the Pierre> failure with all-gdb target. These differences look harmless to me. The biggest one is disabling dependency tracking, since that requires GNU make -- at configure time. Tom ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: gdb/gnulib problems with BSD operating systems 2012-04-02 14:18 ` Tom Tromey @ 2012-04-05 9:44 ` Pierre Muller 2012-04-10 15:05 ` Joel Brobecker 0 siblings, 1 reply; 11+ messages in thread From: Pierre Muller @ 2012-04-05 9:44 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: 'Joel Brobecker', gdb I was looking in the wrong file, I should have compared build/gdb/config.log. I think that I now understood the reason of the different behavior: Using gmake or gmake all Result in MAKE=gmake being passed to configure script in sub-directories via the all phony target that uses RECURSE_FLAGS_TO_PASS for each subdirectory configure call while using gmake all-gdb uses configure-gdb phony target that also calls gdb/configure but without using RECURSE_FLAGS_TO_PASS Thus, the two former get MAKE=gmake environment while the MAKE is not set for the last case. In such case, gdb/configure looks for make in the pass and thus find the BSD make which later fails at build/gdb/gnulib level. It is probably related to some recent change in the top level configure... I have no clue if and how this should be fixed. Especially as top Makefile contains the lines: 691-# We leave this in just in case, but it is not needed anymore. 692:RECURSE_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS) Pierre Muller > -----Message d'origine----- > De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la part > de Tom Tromey > Envoyé : lundi 2 avril 2012 16:18 > À : Pierre Muller > Cc : 'Joel Brobecker'; gdb@sourceware.org > Objet : Re: gdb/gnulib problems with BSD operating systems > > >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: > > Pierre> There are differences in the gdb/Makefile's (see below) > Pierre> but I have no idea if this explains the > Pierre> failure with all-gdb target. > > These differences look harmless to me. > The biggest one is disabling dependency tracking, since that requires > GNU make -- at configure time. > > Tom ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb/gnulib problems with BSD operating systems 2012-04-05 9:44 ` Pierre Muller @ 2012-04-10 15:05 ` Joel Brobecker 0 siblings, 0 replies; 11+ messages in thread From: Joel Brobecker @ 2012-04-10 15:05 UTC (permalink / raw) To: Pierre Muller; +Cc: 'Tom Tromey', gdb > It is probably related to some recent change in > the top level configure... It seems so indeed. > I have no clue if and how this should be fixed. > Especially as top Makefile contains the lines: > 691-# We leave this in just in case, but it is not needed anymore. > 692:RECURSE_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS) The top-level configure is maintained by GCC, so hopefully someone on the GCC list would be able to give us a hint? -- Joel ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <37068.5830399909$1333195740@news.gmane.org>]
* Re: gdb/gnulib problems with BSD operating systems [not found] ` <37068.5830399909$1333195740@news.gmane.org> @ 2012-04-02 14:17 ` Tom Tromey 0 siblings, 0 replies; 11+ messages in thread From: Tom Tromey @ 2012-04-02 14:17 UTC (permalink / raw) To: Pierre Muller; +Cc: 'Joel Brobecker', gdb >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Pierre> You are right, Pierre> do a simple Pierre> gmake Pierre> does work. Pierre> However, I am used to do Pierre> gmake all-gdb Pierre> and I checked by removing everything Pierre> it does fail if you use Pierre> gmake all-gdb Pierre> instead of Pierre> gmake Pierre> ... I wonder whether changing the top-level Makefile so that "MAKE" is in HOST_EXPORTS would help. I believe this will cause MAKE to be set in the subdir configure environment. Tom ^ permalink raw reply [flat|nested] 11+ messages in thread
* gdb/gnulib problems with BSD operating systems @ 2012-03-29 14:27 Pierre Muller 2012-03-29 16:21 ` Joel Brobecker 0 siblings, 1 reply; 11+ messages in thread From: Pierre Muller @ 2012-03-29 14:27 UTC (permalink / raw) To: gdb I tried to compile gdb (7.4 release and current CVS) on openbsd/netbsd/freebsd systems (with i386 cpus, but this is probably not relevant). I get into the same problem for all three systems: gmake all-gdb fails in build/gdb/gnulib This seems to come from the fact that build/gdb/gnulib/Makefile contains a line with MAKE = make so that despite being calls from gmake, it calls BSD style make executable that doesn't know how to handle some GNU specific stuff. Changing the line in build/gdb/gnulib/Makefile to MAKE = gmake is enough to allow me to complete compilation of GDB successfully, but I was wondering if there is not some error somewhere. I tried to do a global configure for which I added an explicit ../src/configure MAKE=gmake but even this wasn't able to get the correct value into build/gdb/gnulib/Makefile Is this an error in the configure script of GDB, or should I specify which make I intent to use differently? Pierre Muller GDB pascal language maintainer ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb/gnulib problems with BSD operating systems 2012-03-29 14:27 Pierre Muller @ 2012-03-29 16:21 ` Joel Brobecker 0 siblings, 0 replies; 11+ messages in thread From: Joel Brobecker @ 2012-03-29 16:21 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb > Is this an error in the configure script of GDB, > or should I specify which make I intent to use > differently? Just a shot in the dark, have you tried: % make MAKE=gmake ? I tried "MAKE=gmake [...]/configure" and got the same result, and I haven't looked at why. Probably something in gnulib's configury. But if the above doesn't work, as a last resort, you could create a link from gmake to make somewhere in your home, and add that to the front of your PATH. -- Joel ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-04-10 15:05 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <32726.6318876811$1333031278@news.gmane.org> 2012-03-30 20:35 ` gdb/gnulib problems with BSD operating systems Tom Tromey 2012-03-30 21:35 ` Joel Brobecker 2012-03-30 22:07 ` Joel Brobecker 2012-03-31 12:08 ` Pierre Muller 2012-03-31 18:17 ` Pierre Muller [not found] ` <24504.7532058836$1333217860@news.gmane.org> 2012-04-02 14:18 ` Tom Tromey 2012-04-05 9:44 ` Pierre Muller 2012-04-10 15:05 ` Joel Brobecker [not found] ` <37068.5830399909$1333195740@news.gmane.org> 2012-04-02 14:17 ` Tom Tromey 2012-03-29 14:27 Pierre Muller 2012-03-29 16:21 ` Joel Brobecker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).