public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: Sam James <sam@gentoo.org>,
	gcc-patches@gcc.gnu.org, Gerald Pfeifer <gerald@pfeifer.com>
Subject: Re: [PATCH] Notes on the warnings-as-errors change in GCC 14
Date: Thu, 15 Feb 2024 16:20:24 +0000	[thread overview]
Message-ID: <874je9ofzv.fsf@gentoo.org> (raw)
In-Reply-To: <87le7laeyo.fsf@oldenburg.str.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]


Florian Weimer <fweimer@redhat.com> writes:

> * Sam James:
>
>> It's fine if you leave this out, but consider mentioning the common
>> pitfall of autoconf projects not including config.h consistently before
>> all inclues. We could also mention AC_USE_SYSTEM_EXTENSIONS.
>
> I added: 
>
> “
> Alternatively, projects using using Autoconf
> could enable <code>AC_USE_SYSTEM_EXTENSIONS</code>.
> ”
>
> <config.h> inclusion is a larger issue, I think, best addressed by
> future diagnostics.

OK, works for me. We should discuss some options for the latter at some
point though (I think we could do it for libc cases where it matters for
LFS at least) but that's for another time.

>
>>> +<p>
>>> +When building library code on GNU systems, it was possible to call
>>> +undefined (not just undeclared) functions and still run other code in
>>> +the library, particularly if ELF lazy binding was used.  Only
>>> +executing the undefined function call would result in a lazy binding
>>> +error and program crash.
>>
>> Maybe explicitly refer to the bfd linker's relaxed behaviour so it
>> sounds less mysterious.
>
> Like this?
>
> “
> <p>
> When building library code on GNU systems,
> <a href="https://sourceware.org/binutils/docs-2.42/ld/Options.html#index-_002d_002dallow_002dshlib_002dundefined">it was possible to call
>   undefined (not just undeclared) functions</a>
> and still run other code in the library, particularly if ELF lazy binding
> was used.  Only executing the undefined function call would result in a
> lazy binding error and program crash.
> ”

Sounds good, thanks.

>
> Thanks,
> Florian

best,
sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

  reply	other threads:[~2024-02-15 16:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02 16:59 Florian Weimer
2024-02-02 18:08 ` Jonathan Wakely
2024-02-15 15:57   ` Florian Weimer
2024-02-02 19:06 ` Jonathan Wakely
2024-02-08  7:04 ` Sam James
2024-02-15 16:07   ` Florian Weimer
2024-02-15 16:20     ` Sam James [this message]
2024-02-09 23:07 ` Gerald Pfeifer
2024-02-15 16:22   ` Florian Weimer
2024-02-15 22:58     ` Gerald Pfeifer
2024-02-15 16:49   ` Florian Weimer
2024-02-10 11:00 ` Gerald Pfeifer
2024-02-15 16:44   ` Florian Weimer
2024-02-16 21:23     ` Gerald Pfeifer

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=874je9ofzv.fsf@gentoo.org \
    --to=sam@gentoo.org \
    --cc=fweimer@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gerald@pfeifer.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).