On Thu, Sep 19, 2013 at 02:23:29PM +0200, Ludovic Courtès wrote:
> Hello,
>
> I’m wondering about the asymptotic behavior of the current policy:
> aren’t all modules going to be LGPLv2+ as time tends to +∞?
Speaking as a gnulib *user* I would be happy to see this happen.
The specific pain point
[adding bug-gnulib]
On 09/22/2013 07:08 AM, Dagobert Michelsen wrote:
>
> The latest release is no longer compilable with Sun Studio 12.3 compiler as it
> automatically uses GCC-specific flags:
>
>> /opt/solarisstudio12.3/bin/cc -D_STDC_C99= -fdiagnostics-show-option
>> -funit-at-a-time -xO3
Eric Blake wrote:
> On 09/22/2013 07:08 AM, Dagobert Michelsen wrote:
>
>> >
>> > The latest release is no longer compilable with Sun Studio 12.3 compiler
>> > as it
>> > automatically uses GCC-specific flags:
I don't observe this behavior on my host (Sun Studio 12.3,
Solaris 10 sparc). I get
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-warn
Eric Blake wrote:
> is this
> something where you can tackle the gnulib patch faster than I can?
I can test something easily, yes, but I'm not sure what
direction you're headed here.
On 09/12/2013 04:26 PM, Eric Blake wrote:
> http://lwn.net/Articles/436012/ documents that many distros
> are now preferring to use /run rather than /var/run for
> storage of pid files and other per-process temporary files
> that must not be cleaned out during arbitrary TMPDIR sweeps.
> As such, th
Hi Erik,
Am 23.09.2013 um 16:27 schrieb Paul Eggert :
> Eric Blake wrote:
>> On 09/22/2013 07:08 AM, Dagobert Michelsen wrote:
>>
The latest release is no longer compilable with Sun Studio 12.3 compiler
as it
automatically uses GCC-specific flags:
>
> I don't observe this b
"Richard W.M. Jones" skribis:
> On Thu, Sep 19, 2013 at 02:23:29PM +0200, Ludovic Courtès wrote:
>> Hello,
>>
>> I’m wondering about the asymptotic behavior of the current policy:
>> aren’t all modules going to be LGPLv2+ as time tends to +∞?
>
> Speaking as a gnulib *user* I would be happy to s
On 09/23/2013 09:32 AM, Paul Eggert wrote:
> Eric Blake wrote:
>> is this
>> something where you can tackle the gnulib patch faster than I can?
>
> I can test something easily, yes, but I'm not sure what
> direction you're headed here.
Basically, gl_WARN_ADD in gnulib/m4/warnings.m4 is trying to
On 09/23/13 08:40, Eric Blake wrote:
> -fdiagnostics-show-option is very useful for gcc; perhaps we
> should tweak m4/manywarnings.m4 to add it to the set of warnings probed
> by default when gcc warnings are enabled
I'm not familiar with that option. Isn't it the default behavior
for GCC nowada
On 09/23/2013 11:21 AM, Paul Eggert wrote:
> On 09/23/13 08:40, Eric Blake wrote:
>
>> -fdiagnostics-show-option is very useful for gcc; perhaps we
>> should tweak m4/manywarnings.m4 to add it to the set of warnings probed
>> by default when gcc warnings are enabled
>
> I'm not familiar with that
That change is fine.
Hi Dago,
Thanks for the analysis.
On Sep 23, 2013, at 10:07 PM, Dagobert Michelsen
wrote:
> I didn't enable gcc-warnings, but as it turns out this flag is automatically
> enabled when $srcdir/.git is present:
>
> AC_ARG_ENABLE([gcc-warnings],
> [AS_HELP_STRING([--enable-gcc-warnings],
>
On 09/23/2013 09:28 AM, Gary V. Vaughan wrote:
>
> Clearly, it should at least check whether the compiler is actually gcc before
> piling
> on the flags, although I don't think it is serious enough to warrant another
> release.
>
> Eric, do you mind if I revert that change in branch-1.4 in case
Hi Eric,
On Sep 24, 2013, at 10:07 AM, Eric Blake wrote:
> On 09/23/2013 09:28 AM, Gary V. Vaughan wrote:
>>
>> Clearly, it should at least check whether the compiler is actually gcc
>> before piling
>> on the flags, although I don't think it is serious enough to warrant another
>> release.
>
15 matches
Mail list logo
