public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dave Korn <dave.korn.cygwin@gmail.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: Caroline Tice <cmtice@google.com>,
	 GCC Patches <gcc-patches@gcc.gnu.org>,
	libstdc++@gcc.gnu.org, Diego Novillo <dnovillo@google.com>,
	 Luis Lozano <llozano@google.com>,
	Bhaskar Janakiraman <bjanakiraman@google.com>
Subject: Re: [PATCH, updated] Vtable pointer verification, runtime library changes (patch 3 of 3)
Date: Fri, 08 Mar 2013 08:13:00 -0000	[thread overview]
Message-ID: <51399E1B.2070200@gmail.com> (raw)
In-Reply-To: <CAH6eHdRvVP9hY3BLbzQmpFCB6UhQ-NfC_WfnAdySDr+Q6MgrLQ@mail.gmail.com>

On 08/03/2013 00:11, Jonathan Wakely wrote:
> On 7 March 2013 23:53, Caroline Tice wrote:

>> I believe this patch addresses all of your comments; I modified the
>> configure.ac files to generate the configures, and I fixed the
>> spelling mistakes in the comments.  I still get the warnings when
>> generating the Makefile.in files from the Makefile.am files, but the
>> resulting files seem to be correct, and I don't know how to make the
>> warnings go away.
>>
>> Please review this patch and let me know if it will be ok to commit
>> when GCC opens up again.
> 
> I'd like to know if someone with better automake skills than I have
> can do anything about that warning, but otherwise that looks OK to me,
> thanks.

  Looks like libvtv___la_LIBADD is still being defined in the else clause.
I'm also getting warnings for src/c++11/Makefile.am about EXTRA_VTV_LDFLAGS,
which may need renaming to avoid confusing automake:

src/c++11/Makefile.am:70: variable `EXTRA_VTV_LDFLAGS' is defined but no
program or
src/c++11/Makefile.am:70: library has `EXTRA_VTV' as canonical name (possible
typo)
src/c++98/Makefile.am:152: variable `EXTRA_VTV_LDFLAGS' is defined but no
program or
src/c++98/Makefile.am:152: library has `EXTRA_VTV' as canonical name (possible
typo)

  Also, it should generally contain only .lo and .la object and libraries to
link against.  From the automake manual:

> 8.3.7 _LIBADD, _LDFLAGS, and _LIBTOOLFLAGS
> As shown in previous sections, the ‘library_LIBADD’ variable should be used
> to list extra libtool objects (‘.lo’ files) or libtool libraries (‘.la’)
> to add to library. The ‘library_LDFLAGS’ variable is the place to list
> additional libtool linking flags, such as ‘-version-info’, ‘-static’, and a
> lot more.

  So putting a dir path into LIBADD and then concatenating -L and including it
wholesale in some other flag variable seems incorrect.

  Also, both that and the top-level change looks dubious to me.  The libtool
subdir isn't necessarily called '.libs' on all platforms, and you should never
need to reach into it(*).  Likewise LIBVTV_FLAGS.  Instead of adding
-lvtv_init or -lvtv_stubs to the linker flags, I think you're supposed to add
the corresponding .la files to the relevant LIBADD variable.  And w.r.t. the
top-level change, I think it may turn out to be unneeded altogether once the
libtool stuff is correct.

  It also looks odd to me that linker flags are being added into a CXXFLAGS
variable (EXTRA_VTV_LDFLAGS via VTV_CXXFLAGS) rather than the corresponding
LDFLAGS.

  I'm not a libtool expert, I've just been told to avoid similar dubious
practices in patches I've submitted in the past.

  And one minor nit, it is conventional not to include the generated files
(Makefile.in, configure) in patches.  They should autogenerate exactly the
same everywhere and it saves clutter.

    cheers,
      DaveK
-- 
(*) - I see a couple of cases have slipped through already, I think we should
avoid adding any more.

  reply	other threads:[~2013-03-08  8:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-25 19:31 Caroline Tice
2013-02-25 19:53 ` Caroline Tice
2013-02-25 21:15   ` Jonathan Wakely
2013-02-25 22:44     ` Caroline Tice
2013-02-25 22:49       ` Jonathan Wakely
2013-03-07 23:53     ` Caroline Tice
2013-03-08  0:12       ` Jonathan Wakely
2013-03-08  8:13         ` Dave Korn [this message]
2013-05-21  2:01         ` Benjamin De Kosnik

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=51399E1B.2070200@gmail.com \
    --to=dave.korn.cygwin@gmail.com \
    --cc=bjanakiraman@google.com \
    --cc=cmtice@google.com \
    --cc=dnovillo@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=llozano@google.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).