Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Tom Tromey'" <tromey@redhat.com>
Cc: "'Joel Brobecker'" <brobecker@adacore.com>, <gdb@sourceware.org>
Subject: RE: gdb/gnulib problems with BSD operating systems
Date: Thu, 05 Apr 2012 09:44:00 -0000	[thread overview]
Message-ID: <000301cd1310$8fdaad50$af9007f0$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <877gxykyjq.fsf@fleche.redhat.com>

  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


  reply	other threads:[~2012-04-05  9:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000301cd1310$8fdaad50$af9007f0$@muller@ics-cnrs.unistra.fr' \
    --to=pierre.muller@ics-cnrs.unistra.fr \
    --cc=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox