public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Joseph Myers <joseph@codesourcery.com>
Cc: <cltang@codesourcery.com>,
	 Thomas Schwinge <thomas@codesourcery.com>,
	 <gcc-patches@gcc.gnu.org>, 	Paolo Bonzini <bonzini@gnu.org>,
	 DJ Delorie <dj@redhat.com>,
	 Nathanael Nerode	<neroden@gcc.gnu.org>,
	 Alexandre Oliva <aoliva@redhat.com>,
	 Ralf Wildenhues	<Ralf.Wildenhues@gmx.de>
Subject: Re: [PR other/79543] Fix GNU ld --version scanning to conform to the GNU Coding Standards
Date: Tue, 13 Aug 2019 18:25:00 -0000	[thread overview]
Message-ID: <ydd1rxpotr7.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <alpine.DEB.2.21.1908131707130.25014@digraph.polyomino.org.uk>	(Joseph Myers's message of "Tue, 13 Aug 2019 17:16:47 +0000")

Hi Joseph,

> However, I strongly encourage a followup to refactor this code 
> (*_CHECK_LINKER_FEATURES and *_ENABLE_SYMVERS that use it, not just the 
> fragment that determines the linker version number), which is evidently 
> duplicated far too much in different target library directories, into 
> common macros in a .m4 file in the top-level config/ directory, so it's 
> more maintainable in future.  (Note 1: I don't know what differences there 
> might be between the versions in different directories; that would need 
> investigating as part of such a refactoring; differences need not be 
> deliberate, they could easily have arisen by accident.  Note 2: although 
> libffi is maintained outside of GCC, I think such a refactoring should 
> still be applied to the libffi directory along with the others; standalone 
> libffi would simply need its own copy of the relevant .m4 file.  Note 3: 
> it should be possible to do such a refactoring bit by bit if that's more 
> approachable, rather than necessarily doing a complete refactoring of all 
> the definitions of all these macros at once.)

as it happens, I've been working on exactly this.  I'd noticed that
*_CHECK_LINKER_FEATURES enabled --gc-sections only with gld although
recent Solaris ld supports it as well.  What's worse, even with gld the
option is detected and used only for some of the libraries due to
inconsistencies between the different versions of the macro.

I'd meant to unify *_ENABLE_SYMVERS for a long time and this seemed the
perfect opportunity to do so, among others because several libs require
it from *_CHECK_LINKER_FEATURES to get the linker version info ;-(

On top of that, there are many different copies of the code that handles
--enable-version-specific-runtime-libs, sets toolexeclibdir and
--enable-generated-files-in-srcdir, as well as several instances of
*_CHECK_ATTRIBUTE_ALIAS, *_CHECK_ATTRIBUTE_DLLEXPORT, and
*_CHECK_ATTRIBUTE_VISIBILITY, and probably more that I've missed so
far.  Overall, we've created an incredible mess here, and I'm probably
partially responsible at least for the *_ENABLE_SYMVERS part.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

  reply	other threads:[~2019-08-13 17:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 16:48 Thomas Schwinge
2017-10-31  1:20 ` Joseph Myers
2019-07-04  8:29   ` Chung-Lin Tang
2019-07-16 14:45     ` [PR other/79543] Fix GNU ld --version scanning to conform to the GNU Coding Standards (ping) Chung-Lin Tang
2019-07-16 16:40       ` [OG9, committed] Re: [PR other/79543] Fix GNU ld --version scanning to conform to the GNU Coding Standards Chung-Lin Tang
2019-08-13 17:33     ` Joseph Myers
2019-08-13 18:25       ` Rainer Orth [this message]
2019-09-03 14:10       ` Chung-Lin Tang
2017-12-19 17:14 ` [og7] " Thomas Schwinge

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=ydd1rxpotr7.fsf@CeBiTec.Uni-Bielefeld.DE \
    --to=ro@cebitec.uni-bielefeld.de \
    --cc=Ralf.Wildenhues@gmx.de \
    --cc=aoliva@redhat.com \
    --cc=bonzini@gnu.org \
    --cc=cltang@codesourcery.com \
    --cc=dj@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=neroden@gcc.gnu.org \
    --cc=thomas@codesourcery.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).