gdb/gnulib problems with BSD operating systems

gdb/gnulib problems with BSD operating systems

[Pierre Muller]

  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

Re: gdb/gnulib problems with BSD operating systems

[Joel Brobecker]

>   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

Re: gdb/gnulib problems with BSD operating systems

[Tom Tromey]

>>>>> "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

Re: gdb/gnulib problems with BSD operating systems

[Joel Brobecker]

> 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

Re: gdb/gnulib problems with BSD operating systems

[Joel Brobecker]

> > 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

RE: gdb/gnulib problems with BSD operating systems

[Pierre Muller]

> -----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

RE: gdb/gnulib problems with BSD operating systems

[Pierre Muller]

> >     % /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.

Re: gdb/gnulib problems with BSD operating systems

[Tom Tromey]

>>>>> "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

RE: gdb/gnulib problems with BSD operating systems

[Pierre Muller]

  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

Re: gdb/gnulib problems with BSD operating systems

[Joel Brobecker]

> 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

Re: gdb/gnulib problems with BSD operating systems

[Tom Tromey]

>>>>> "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