* 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 gdb/gnulib problems with BSD operating systems 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
* 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
* 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
[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
[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
* 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
* 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-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 20:35 ` 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
[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
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 --
2012-03-29 14:27 gdb/gnulib problems with BSD operating systems Pierre Muller
2012-03-29 16:21 ` Joel Brobecker
[not found] <32726.6318876811$1333031278@news.gmane.org>
2012-03-30 20:35 ` 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
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).