bug#20082: new warning from ar on rawhide systems

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Eric Blake-3
When compiling libvirt (and probably other packages) on Fedora rawhide
systems, I'm seeing a new warning message on every link line.

# rpm -q libtool gcc binutils
libtool-2.4.6-1.fc23.x86_64
gcc-5.0.0-0.16.fc23.x86_64
binutils-2.25-6.fc23.x86_64

For an example of the warning during a 'make V=1':

> libtool: link: rm -fr  .libs/libvirt_driver_qemu_impl.a .libs/libvirt_driver_qemu_impl.la
> libtool: link: ar cru .libs/libvirt_driver_qemu_impl.a qemu/.libs/libvirt_driver_qemu_impl_la-qemu_agent.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_capabilities.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_command.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_domain.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_cgroup.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hostdev.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hotplug.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_conf.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_process.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_migration.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_text.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_json.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_driver.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_interface.o
> ar: `u' modifier ignored since `D' is the default (see `U')
> libtool: link: ranlib .libs/libvirt_driver_qemu_impl.a

Reading 'man ar', it looks like a relatively new binutils invention, one
that Fedora chose to flip on by default, but also one that might be
worth using even when ar is built with 'U' rather than 'D' as the default:

>        D   Operate in deterministic mode.  When adding files and the archive
>            index use zero for UIDs, GIDs, timestamps, and use consistent file
>            modes for all files.  When this option is used, if ar is used with
>            identical options and identical input files, multiple runs will
>            create identical output files regardless of the input files'
>            owners, groups, file modes, or modification times.
>
>            If binutils was configured with --enable-deterministic-archives,
>            then this mode is on by default.  It can be disabled with the U
>            modifier, below.
Is it worth teaching automake to change ARFLAGS to be 'crD' instead of
'cru' when it is detected that ar is new enough to support deterministic
libraries, in part to shut up the warning message being printed on every
single libtool link line?  (Note that I would explicitly include 'D',
because even though Fedora chose to make 'D' the default, other distros
may choose to make 'U' the default).  Or conversely, do we want ARFLAGS
to be 'cruU', to force non-deterministic mode, since any speedups made
possible by timestamp comparison ('u') are only possible in
non-deterministic mode?  Does the use of 'u' buy us much measurable time
when repeatedly and incrementally linking large libraries, where the new
'D' mode is forced to link everything instead of just the new inputs?
And of course there's the question of how easy is it to detect that ar
is new enough to understand the 'D'/'U' dichotomy?

I've already asked on libtool, and they suggested it is an automake issue.

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




signature.asc (617 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Pavel Raiskup
On Wednesday 11 of March 2015 10:07:33 Eric Blake wrote:

> When compiling libvirt (and probably other packages) on Fedora rawhide
> systems, I'm seeing a new warning message on every link line.
>
> # rpm -q libtool gcc binutils
> libtool-2.4.6-1.fc23.x86_64
> gcc-5.0.0-0.16.fc23.x86_64
> binutils-2.25-6.fc23.x86_64
>
> For an example of the warning during a 'make V=1':
>
> > libtool: link: rm -fr  .libs/libvirt_driver_qemu_impl.a .libs/libvirt_driver_qemu_impl.la
> > libtool: link: ar cru .libs/libvirt_driver_qemu_impl.a qemu/.libs/libvirt_driver_qemu_impl_la-qemu_agent.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_capabilities.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_command.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_domain.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_cgroup.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hostdev.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hotplug.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_conf.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_process.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_migration.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_text.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_json.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_driver.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_interface.o
> > ar: `u' modifier ignored since `D' is the default (see `U')
> > libtool: link: ranlib .libs/libvirt_driver_qemu_impl.a
>
> Reading 'man ar', it looks like a relatively new binutils invention, one
> that Fedora chose to flip on by default, but also one that might be
> worth using even when ar is built with 'U' rather than 'D' as the default:
>
> >        D   Operate in deterministic mode.  When adding files and the archive
> >            index use zero for UIDs, GIDs, timestamps, and use consistent file
> >            modes for all files.  When this option is used, if ar is used with
> >            identical options and identical input files, multiple runs will
> >            create identical output files regardless of the input files'
> >            owners, groups, file modes, or modification times.
> >
> >            If binutils was configured with --enable-deterministic-archives,
> >            then this mode is on by default.  It can be disabled with the U
> >            modifier, below.
>
> Is it worth teaching automake to change ARFLAGS to be 'crD' instead of
> 'cru' when it is detected that ar is new enough to support deterministic
> libraries, in part to shut up the warning message being printed on every
> single libtool link line?  (Note that I would explicitly include 'D',
> because even though Fedora chose to make 'D' the default, other distros
> may choose to make 'U' the default).  Or conversely, do we want ARFLAGS
> to be 'cruU', to force non-deterministic mode, since any speedups made
> possible by timestamp comparison ('u') are only possible in
> non-deterministic mode?  Does the use of 'u' buy us much measurable time
> when repeatedly and incrementally linking large libraries, where the new
> 'D' mode is forced to link everything instead of just the new inputs?

From GNU ar code I assume that having the 'u' might save some file opening
and closing, because only files with newer timestamp are opened to be
copyied into new archive with 'u'.  Files with mtime lower than the
corresponding archive member are copyied directly from (already opened)
old archive.

If at least one member was updated on the disk before calling 'ar cru',
_new_ archive is created (no in place update of archive).  When no file
was changed, GNU ar does not touch existing archive.  In Makefile
(precisely defined dependencies) this is not useful optimization however..

So probably the worst slowdown would be an 'ar' task to update archive
consisting of a big amount of small files when only one has changed.

FTR, Automake uses 'cru' since at least ~1994 initial commit in git, cmake
uses 'cr' only.

> And of course there's the question of how easy is it to detect that ar
> is new enough to understand the 'D'/'U' dichotomy?

Not sure.  Probably ./configure check like '--version works' && 'GNU in
--version' && 'ar crD' could be enough..

However, having best-effort determinism in Automake does not guarantee
determinism of final result..  Is it worth the trouble?  I could imagine
some general './configure --enable-deterministic-build', but then I would
expect the configure to fail if the 'D' option is not available..

Having used 'cru' with optional 'cruU' could have at least a small benefit
that the default behavior would behave consistently at least on boxes
running GNU ar..  which is not the actual state.

IMO, removing the 'u' optimization for everybody is the easiest thing to
do.  Its suboptimal because 'u' is probably portable enough it has worked
for automake for 20+ year.. and we would remove it just to silence warning
on some platforms .. but ..

> I've already asked on libtool, and they suggested it is an automake issue.

The link to make it complete:
http://lists.gnu.org/archive/html/bug-libtool/2015-02/msg00014.html

Pavel




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Eric Blake-3
On 03/27/2015 09:48 AM, Pavel Raiskup wrote:

> So probably the worst slowdown would be an 'ar' task to update archive
> consisting of a big amount of small files when only one has changed.
>
> FTR, Automake uses 'cru' since at least ~1994 initial commit in git, cmake
> uses 'cr' only.
>
>> And of course there's the question of how easy is it to detect that ar
>> is new enough to understand the 'D'/'U' dichotomy?
>
> Not sure.  Probably ./configure check like '--version works' && 'GNU in
> --version' && 'ar crD' could be enough..
Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
'cru', so that projects that want to silence the warning now can do so
without waiting on automake to catch up?  (Remember, the warning is live
on rawhide systems now, and even if we release a new automake with a
patch to change the default, there are TONS of packages built with older
automake that will still warn until such time as autoreconf is run on
those packages to update them to the newer automake)

>
> However, having best-effort determinism in Automake does not guarantee
> determinism of final result..  Is it worth the trouble?  I could imagine
> some general './configure --enable-deterministic-build', but then I would
> expect the configure to fail if the 'D' option is not available..
>
> Having used 'cru' with optional 'cruU' could have at least a small benefit
> that the default behavior would behave consistently at least on boxes
> running GNU ar..  which is not the actual state.

So you are arguing that 'crD' is smarter than 'cruU' if we bother to
detect new enough binutils, but that 'cr' is just about as effective and
then we don't have to worry about the detection at all.  And if I
understand correctly, the warning occurs if we use just 'cru' but the
binutils defaulted to 'D' (rather amusing, that 'cruD' is the spelling
that warns).

Next step - how to patch automake.  I'm not familiar enough with the
internals to quickly find the location to patch, if someone else is able
to do it quickly.

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


signature.asc (617 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Pavel Raiskup
[+cc back libtool bug; as fixing automake does not seem to be enough]

On Friday 27 of March 2015 10:51:36 Eric Blake wrote:

> On 03/27/2015 09:48 AM, Pavel Raiskup wrote:
>
> > So probably the worst slowdown would be an 'ar' task to update archive
> > consisting of a big amount of small files when only one has changed.
> >
> > FTR, Automake uses 'cru' since at least ~1994 initial commit in git, cmake
> > uses 'cr' only.
> >
> >> And of course there's the question of how easy is it to detect that ar
> >> is new enough to understand the 'D'/'U' dichotomy?
> >
> > Not sure.  Probably ./configure check like '--version works' && 'GNU in
> > --version' && 'ar crD' could be enough..
>
> Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
> 'cru', so that projects that want to silence the warning now can do so
> without waiting on automake to catch up?  (Remember, the warning is live
> on rawhide systems now, and even if we release a new automake with a
> patch to change the default, there are TONS of packages built with older
> automake that will still warn until such time as autoreconf is run on
> those packages to update them to the newer automake)

Agreed here, while trying to look at possible patch, I found that libtool
historically does not respect automake's ARFLAGS, it has its own AR_FLAGS:
http://lists.gnu.org/archive/html/libtool/2008-05/msg00050.html
So fixing automake does not help for libtool-enabled projects, and, in some
situations users could need AR_FLAGS=X ARFLAGS=X, but yes - still easy to
define on per-project basis.

FTR, Libtool uses AR_FLAGS from ~2000 (commit 8300de4c54e6f04f0d), automake
ARFLAGS from ~2003 (commit a71b3490639831ca).

This is probably different issue, but sync is needed..  having two variables
doing the same is pain.   What about make libtool respect the ARFLAGS also
even though it is younger variable?  Just because ARFLAGS looks more
consistently with other *FLAGS.  The proposal would be to make ARFLAGS and
AR_FLAGS synonyms (possibly marking AR_FLAGS obsoleted).  Could we do the
same for automake?

> > However, having best-effort determinism in Automake does not guarantee
> > determinism of final result..  Is it worth the trouble?  I could imagine
> > some general './configure --enable-deterministic-build', but then I would
> > expect the configure to fail if the 'D' option is not available..
> >
> > Having used 'cru' with optional 'cruU' could have at least a small benefit
> > that the default behavior would behave consistently at least on boxes
> > running GNU ar..  which is not the actual state.
>
> So you are arguing that 'crD' is smarter than 'cruU' if we bother to detect
> new enough binutils, but that 'cr' is just about as effective and then
> we don't have to worry about the detection at all.

I _personally_ feel it this way.

If we are not able to guarantee deterministic $AR _everywhere_ it looks
fighting non-determinism via additional configure time checks (in default
case) is worthless; we can let the decision up to binutils or user.

> And if I understand correctly, the warning occurs if we use just 'cru' but
> the binutils defaulted to 'D' (rather amusing, that 'cruD' is the spelling
> that warns).

Yes, 'cruD' warns, nice!

> Next step - how to patch automake.  I'm not familiar enough with the
> internals to quickly find the location to patch, if someone else is able
> to do it quickly.

I was about to propose the patch, but I will need a bit more time to
re-think the libtool consistency issue, to ideally fix this together.
If there is no other problem .. or somebody faster to do the proposal.

Pavel




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Pavel Raiskup
[+cc Ralf]

On Friday 27 of March 2015 21:43:14 Pavel Raiskup wrote:

> On Friday 27 of March 2015 10:51:36 Eric Blake wrote:
> > Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
> > 'cru', so that projects that want to silence the warning now can do so
> > without waiting on automake to catch up?  (Remember, the warning is live
> > on rawhide systems now, and even if we release a new automake with a
> > patch to change the default, there are TONS of packages built with older
> > automake that will still warn until such time as autoreconf is run on
> > those packages to update them to the newer automake)
>
> Agreed here, while trying to look at possible patch, I found that libtool
> historically does not respect automake's ARFLAGS, it has its own AR_FLAGS:
> http://lists.gnu.org/archive/html/libtool/2008-05/msg00050.html
> So fixing automake does not help for libtool-enabled projects, and, in some
> situations users could need AR_FLAGS=X ARFLAGS=X, but yes - still easy to
> define on per-project basis.
>
> FTR, Libtool uses AR_FLAGS from ~2000 (commit 8300de4c54e6f04f0d), automake
> ARFLAGS from ~2003 (commit a71b3490639831ca).
>
> This is probably different issue, but sync is needed..  having two variables
> doing the same is pain.   What about make libtool respect the ARFLAGS also
> even though it is younger variable?  Just because ARFLAGS looks more
> consistently with other *FLAGS.  The proposal would be to make ARFLAGS and
> AR_FLAGS synonyms (possibly marking AR_FLAGS obsoleted).  Could we do the
> same for automake?
Sorry for the delay.  I tried to look at it, but I accidentally found the
old topic: https://www.mail-archive.com/bug-libtool@.../msg01198.html
.. where Ralf describes that we should be careful of merging ARFLAGS and
AR_FLAGS variables - but I don't understand it correctly, tbh:

On Mon, 20 Aug 2007 14:00:21 -0700  Ralf Wildenhues wrote:
> Ah, so the chance of reconciliation with Automake's ARFLAGS just got a
> wee bit better.  Except that Automake uses
>   $(AR) $(ARFLAGS) LIBRARY OBJECTS...
>
> and Libtool would like to not have a space after ${ARFLAGS}, if it wants
> to support the w32 LIB program.

Because within actual Libtool, if there is $AR_FLAGS used there is always
something like  '$AR<space>$AR_FLAGS<space>...'.  It means the space _is_
already there.

Why would user want to use 'make "ARFLAGS=cru "' (I mean calling something
like 'ar "cru " ...'), Ralf?  Or anybody?

I tried to prepare the patch, but thats probably wrong.  It would be nice
if somebody could comment,

Thanks, Pavel

0001-libool.m4-incorporate-ARFLAGS-variable.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Peter Rosin
On 2015-04-17 17:54, Pavel Raiskup wrote:

> [+cc Ralf]
>
> On Friday 27 of March 2015 21:43:14 Pavel Raiskup wrote:
>> On Friday 27 of March 2015 10:51:36 Eric Blake wrote:
>>> Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
>>> 'cru', so that projects that want to silence the warning now can do so
>>> without waiting on automake to catch up?  (Remember, the warning is live
>>> on rawhide systems now, and even if we release a new automake with a
>>> patch to change the default, there are TONS of packages built with older
>>> automake that will still warn until such time as autoreconf is run on
>>> those packages to update them to the newer automake)
>>
>> Agreed here, while trying to look at possible patch, I found that libtool
>> historically does not respect automake's ARFLAGS, it has its own AR_FLAGS:
>> http://lists.gnu.org/archive/html/libtool/2008-05/msg00050.html
>> So fixing automake does not help for libtool-enabled projects, and, in some
>> situations users could need AR_FLAGS=X ARFLAGS=X, but yes - still easy to
>> define on per-project basis.
>>
>> FTR, Libtool uses AR_FLAGS from ~2000 (commit 8300de4c54e6f04f0d), automake
>> ARFLAGS from ~2003 (commit a71b3490639831ca).
>>
>> This is probably different issue, but sync is needed..  having two variables
>> doing the same is pain.   What about make libtool respect the ARFLAGS also
>> even though it is younger variable?  Just because ARFLAGS looks more
>> consistently with other *FLAGS.  The proposal would be to make ARFLAGS and
>> AR_FLAGS synonyms (possibly marking AR_FLAGS obsoleted).  Could we do the
>> same for automake?
>
> Sorry for the delay.  I tried to look at it, but I accidentally found the
> old topic: https://www.mail-archive.com/bug-libtool@.../msg01198.html
> .. where Ralf describes that we should be careful of merging ARFLAGS and
> AR_FLAGS variables - but I don't understand it correctly, tbh:
>
> On Mon, 20 Aug 2007 14:00:21 -0700  Ralf Wildenhues wrote:
>> Ah, so the chance of reconciliation with Automake's ARFLAGS just got a
>> wee bit better.  Except that Automake uses
>>   $(AR) $(ARFLAGS) LIBRARY OBJECTS...
>>
>> and Libtool would like to not have a space after ${ARFLAGS}, if it wants
>> to support the w32 LIB program.
>
> Because within actual Libtool, if there is $AR_FLAGS used there is always
> something like  '$AR<space>$AR_FLAGS<space>...'.  It means the space _is_
> already there.
>
> Why would user want to use 'make "ARFLAGS=cru "' (I mean calling something
> like 'ar "cru " ...'), Ralf?  Or anybody?
>
> I tried to prepare the patch, but thats probably wrong.  It would be nice
> if somebody could comment,

Microsofts archiver (lib.exe) uses a syntax like:

  lib -extract:file.o archive.lib

where -extract: was thought to be the content of $AR_FLAGS.

But since then, I added the ar-lib helper to Automake, which hides
these brain-damaged flags that lib expects.

Cheers,
Peter




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Pavel Raiskup
On Friday 17 of April 2015 18:07:57 Peter Rosin wrote:

> On 2015-04-17 17:54, Pavel Raiskup wrote:
> > I tried to prepare the patch, but thats probably wrong.  It would be nice
> > if somebody could comment,
>
> Microsofts archiver (lib.exe) uses a syntax like:
>
>   lib -extract:file.o archive.lib
>
> where -extract: was thought to be the content of $AR_FLAGS.
>
> But since then, I added the ar-lib helper to Automake, which hides
> these brain-damaged flags that lib expects.
Thanks for the info, Peter.

Any objections against attached patches?

Pavel

0001-libool.m4-incorporate-ARFLAGS-variable.patch (2K) Download Attachment
0002-ARFLAGS-use-cr-instead-of-cru-by-default.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Pavel Raiskup
On Saturday 18 of April 2015 11:50:31 Pavel Raiskup wrote:

> On Friday 17 of April 2015 18:07:57 Peter Rosin wrote:
> > On 2015-04-17 17:54, Pavel Raiskup wrote:
> > > I tried to prepare the patch, but thats probably wrong.  It would be nice
> > > if somebody could comment,
> >
> > Microsofts archiver (lib.exe) uses a syntax like:
> >
> >   lib -extract:file.o archive.lib
> >
> > where -extract: was thought to be the content of $AR_FLAGS.
> >
> > But since then, I added the ar-lib helper to Automake, which hides
> > these brain-damaged flags that lib expects.
>
> Thanks for the info, Peter.
And the patch against Automake attached now, sorry for the delay.

Pavel

0001-ARFLAGS-use-cr-instead-of-cru-by-default.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: bug#19967: bug#20082: new warning from ar on rawhide systems

Pavel Raiskup
In reply to this post by Pavel Raiskup
On Saturday 18 of April 2015 11:50:31 Pavel Raiskup wrote:

> On Friday 17 of April 2015 18:07:57 Peter Rosin wrote:
> > On 2015-04-17 17:54, Pavel Raiskup wrote:
> > > I tried to prepare the patch, but thats probably wrong.  It would be nice
> > > if somebody could comment,
> >
> > Microsofts archiver (lib.exe) uses a syntax like:
> >
> >   lib -extract:file.o archive.lib
> >
> > where -extract: was thought to be the content of $AR_FLAGS.
> >
> > But since then, I added the ar-lib helper to Automake, which hides
> > these brain-damaged flags that lib expects.
>
> Thanks for the info, Peter.
>
> Any objections against attached patches?

Not sure whether some review has been done, so pinging once more to get
some attention.  Otherwise I'll probably push those changes.

Thanks, Pavel




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: bug#19967: bug#20082: new warning from ar on rawhide systems

Pavel Raiskup
On Wednesday 17 of June 2015 09:22:31 Pavel Raiskup wrote:
> Not sure whether some review has been done, so pinging once more to get
> some attention.  Otherwise I'll probably push those changes.

OK, I updated the patches a bit more and now just holding them in
praiskup-ARFLAGS branch for a while.

I noticed that at this moment 'gnulib' decides what will be the default
ARFLAGS, not libtool (since the time libtool started to be dependant on
gnulib -- and thus calls automatically GL_EARLY).

To gnulib guys:  I haven't done proper analysis yet.  Is the
gl_PROG_AR_RANLIB really expected to be called for *each* 'gnulib'
dependant project?  If yes, could we possibly at least set the ARFLAGS
default value to 'cr' instead of 'cru'?  See [1,2] for context.

From libtool POV I'm not sure what is correct approach, should we let
gnulib do the decission about ARFLAGS, or should I rather somehow by-pass
the gl_PROG_AR_RANLIB.  Similarly automake (theoretically, AFAIK it does
not depend on gnulib yet), there is also some logic regarding ARFLAGS
variable..

[1] https://lists.gnu.org/archive/html/bug-libtool/2015-02/msg00014.html
[2] https://lists.gnu.org/archive/html/bug-automake/2015-03/msg00004.html

Thanks, Pavel




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: [gnulib PATCH]: new warning from ar on rawhide systems

Pavel Raiskup
On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote:
> To gnulib guys:  I haven't done proper analysis yet.  Is the
> gl_PROG_AR_RANLIB really expected to be called for *each* 'gnulib'
> dependant project?  If yes, could we possibly at least set the ARFLAGS
> default value to 'cr' instead of 'cru'?  See [1,2] for context.

This becomes painfully complicated, sorry to bothering you - just trying
to make this ARFLAGS/AR_FLAGS mess resolved.  I would appreciate any help.

Seems like the gl_PROG_AR_RANLIB was added by commit 2b14869442bc.

Do you think the attached gnulib patches are reasonable then?  First makes
the gl_PROG_AR_RANLIB a bit more conservative and the second sets the
ARFLAGS default to 'cr'.

Pavel

0001-gnulib-common.m4-fix-gl_PROG_AR_RANLIB-AM_PROG_AR-cl.patch (3K) Download Attachment
0002-gnulib-common.m4-change-the-ARFLAGS-default-to-cr.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: bug#19967: bug#20082: new warning from ar on rawhide systems

Pavel Raiskup
In reply to this post by Pavel Raiskup
close 19967 2.4.6.9-41812
--

On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote:
> On Wednesday 17 of June 2015 09:22:31 Pavel Raiskup wrote:
> > Not sure whether some review has been done, so pinging once more to get
> > some attention.  Otherwise I'll probably push those changes.
>
> OK, I updated the patches a bit more and now just holding them in
> praiskup-ARFLAGS branch for a while.

ARFLAGS default has been fixed in gnulib recently, I've pushed this to
libtool.  Only automake looks like it needs a fix.

Pavel




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Pavel Raiskup
In reply to this post by Pavel Raiskup
On Tuesday 02 of June 2015 16:22:50 Pavel Raiskup wrote:

> On Saturday 18 of April 2015 11:50:31 Pavel Raiskup wrote:
> > On Friday 17 of April 2015 18:07:57 Peter Rosin wrote:
> > > On 2015-04-17 17:54, Pavel Raiskup wrote:
> > > > I tried to prepare the patch, but thats probably wrong.  It would be nice
> > > > if somebody could comment,
> > >
> > > Microsofts archiver (lib.exe) uses a syntax like:
> > >
> > >   lib -extract:file.o archive.lib
> > >
> > > where -extract: was thought to be the content of $AR_FLAGS.
> > >
> > > But since then, I added the ar-lib helper to Automake, which hides
> > > these brain-damaged flags that lib expects.
> >
> > Thanks for the info, Peter.
>
> And the patch against Automake attached now, sorry for the delay.

Has anyone looked at this patch so far?  Reviews are appreciated.  As a
downstream maintainer I keep getting questions when this is going to be
fixed.

Thanks, Pavel




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#20082: new warning from ar on rawhide systems

Ralph Corderoy
> Has anyone looked at this patch so far?  Reviews are appreciated.  As
> a downstream maintainer I keep getting questions when this is going to
> be fixed.

Also a problem with automake 1.15-2 on Arch Linux.
Annoying if one's attempting to get "silent" builds that produce no
output if all's well.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy



Loading...