public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Gallager <egall@gwmail.gwu.edu>
To: Jeff Law <law@redhat.com>
Cc: Sergei Trofimovich <slyfox@inbox.ru>,
	Gcc Patch List <gcc-patches@gcc.gnu.org>,
		Sergei Trofimovich <slyfox@gentoo.org>
Subject: Re: [PATCH] gcc/configure.ac: add --disable-systemtap switch
Date: Fri, 25 May 2018 14:02:00 -0000	[thread overview]
Message-ID: <CAMfHzOuNPdApKbyFuge_bt=U7rZ+CPzV2vhmwR6SvGn0K+WErA@mail.gmail.com> (raw)
In-Reply-To: <12da5584-932c-c277-5d1a-51ed5fc57b97@redhat.com>

On 5/24/18, Jeff Law <law@redhat.com> wrote:
> On 05/12/2018 08:00 AM, Sergei Trofimovich via gcc-patches wrote:
>> From: Sergei Trofimovich <slyfox@gentoo.org>
>>
>> Before the change systemtap probes were enabled
>> if target headers had sys/sdt.h at ./configure time.
>>
>> After the change explicitly ask to enable or disable
>> for probe support and not rely on automagic dependency
>> discovery.
> I'm not terribly concerned about the uninstalling systemtap while
> compiling gcc problem.   That seems like a package management problem on
> the distro side.
>
> 61257 does raise the issue of header file usability which is a much
> bigger concern.  c#1 indicates autoconf-2.70 introduces code which
> instead of testing for header file existence instead checks for
> usability.  So I'd rather see us moving towards making that happen
> rather than explicit enable/disable of systemtap headers/probes.
>
> jeff
>

I retracted c#1 in c#4. What autoconf-2.70 changes is how the
AC_CHECK_HEADERS macro is expanded. In current versions of autoconf,
AC_CHECK_HEADERS checks for header file usability, presence, and
existence, but allows the latter 2 to override the usability check. In
autoconf-2.70, however, AC_CHECK_HEADERS will *only* do the usability
check. However, after looking at the code in question, I found that
AC_CHECK_HEADERS is not even used here, but rather it just does `test
-f`. Thus the autoconf-2.70 changes won't automatically fix anything,
since `test -f` is at the shellcode level rather than the m4 level. So
we don't need to wait for it to be released, and probably shouldn't
anyways, considering how many years its release has been pending.

Eric

      reply	other threads:[~2018-05-25 13:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-12 17:37 Sergei Trofimovich via gcc-patches
2018-05-14 17:40 ` Joseph Myers
2018-05-24 22:35 ` Jeff Law
2018-05-25 14:02   ` Eric Gallager [this message]

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='CAMfHzOuNPdApKbyFuge_bt=U7rZ+CPzV2vhmwR6SvGn0K+WErA@mail.gmail.com' \
    --to=egall@gwmail.gwu.edu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=slyfox@gentoo.org \
    --cc=slyfox@inbox.ru \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).