bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANN] m4-1.4.17 released [stable]


From: Eric Blake
Subject: Re: [ANN] m4-1.4.17 released [stable]
Date: Mon, 23 Sep 2013 09:30:49 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

Hello Dago,

On 09/23/2013 09:07 AM, Dagobert Michelsen wrote:
> Hi Erik,

It's Eric, but you're not the first to make that mistake :)

>> I don't observe this behavior on my host (Sun Studio 12.3,
>> Solaris 10 sparc).  I get the bad behavior only if I run
>> 'configure' with the --enable-gcc-warnings option, and
>> a simple workaround is to not use that option.
> 
> I didn't enable gcc-warnings, but as it turns out this flag is automatically
> enabled when $srcdir/.git is present:

Then as a workaround, use './configure --disable-gcc-warnings' until we
fix the issue upstream.

> 
> However, when I browse git the automatic detection of .git is not in there:
>   
> http://git.savannah.gnu.org/gitweb/?p=m4.git;a=blob;f=configure.ac;h=2fe6d9e8189d4083b58ba10bfbbe558da15f393b;hb=c09a187c50f2f74e89d4d0991bdbd2c6846cc707

You're browsing the wrong branch.  It IS present on branch-1.4, which is
the source we used for cutting 1.4.17.

http://git.savannah.gnu.org/gitweb/?p=m4.git;a=blob;f=configure.ac;h=2defd94f;hb=f58fbbd8

> By coincidence we use git to apply patches in our build system
> to upstream sources if necessary, so this is the thing that
> confuses the build.

Makes sense; it's hard to tell whether you are in a git repository for
upstream development vs. a git repository that applies patches to a
released tarball.  Maybe we can make the default be even smarter by
recognizing a tarball-only file (ie. if .tarball-version exists, do NOT
blindly enable gcc warnings) - but that will still only mask the problem
of upstream gnulib's warning module getting the wrong answer for the Sun
compiler.

> When I disable using git in our buildsystem
> the compilation works fine. I would prefer a system that enabled flags
> explicitly and not by inspecting side effects but I can understand the
> current behaviour.

Yes, I'll patch m4 to use .tarball-version rather than just .git as the
witness for whether a development build is being attempted; but there's
still the matter of teaching gnulib's warning module how to recognize
that '-fdiagnostics-show-option' and '-funit-at-a-time' are NOT valid
warning flags for your compiler.  Does your compiler include any flag
that forces the compiler to reject unknown warning parameters with
non-zero exit status, instead of merely warning that they are being
ignored until link phase?

Paul, since you seem to have easy access to the same compiler, is this
something where you can tackle the gnulib patch faster than I can?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]