Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 438332

Summary: =dev-libs/libatomic_ops-1.2-r1 calls AR directly
Product: Gentoo Linux Reporter: Vicente Olivert Riera (RETIRED) <vincent>
Component: Current packagesAssignee: Gentoo Sound Team <sound>
Status: RESOLVED FIXED    
Severity: normal CC: c1pher
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=440274
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 243502    
Attachments: Fix for AR

Description Vicente Olivert Riera (RETIRED) gentoo-dev 2012-10-14 12:37:20 UTC
# grep ^ar libatomic_ops-1.2-r1\:20121014-123800.log 
ar cru libatomic_ops.a atomic_ops.o 
ar cru libatomic_ops_gpl.a atomic_ops_stack.o atomic_ops_malloc.o
Comment 1 Samuli Suominen gentoo-dev 2012-10-15 14:10:36 UTC
ar and ranlib are propably the only two ones not causing problems with cross-compiling despite not being linked with the chost

can you provide an example where this is an actual problem, and not just cosmetics?
Comment 2 Vicente Olivert Riera (RETIRED) gentoo-dev 2012-10-17 18:55:45 UTC
(In reply to comment #1)
> ar and ranlib are propably the only two ones not causing problems with
> cross-compiling despite not being linked with the chost
> 
> can you provide an example where this is an actual problem, and not just
> cosmetics?


Hello Samuli,

yes, I can provide an example about why it's better to use the AR enviroment variable instead of calling ranlib directly.
This is Gentoo, and it's known that Gentoo is one of the most flexible operative systems. So..., as a Gentoo user, I'd like to have the flexibility (or freedom) to use a different version of ar, or maybe a modified version of ar. So, I want to have the possiblity to keep the ar version installed by sys-devel/binutils, stored in /usr/bin/ar, and my custom version of ar, stored in /usr/local/bin/my_custom_ar.
If you let the ebuilds to call ar directly, my custom version will be never used. But, if you use the AR environment variable, I can easily edit the file /etc/env.d/04gcc-x86_64-pc-linux-gnu and add a line like this:
AR="/usr/local/bin/my_custom_ar"
...and my custom version of ar will be used. Same if I want to use a custom version of ranlib, or a different compiler...
Comment 3 Dane Smith (RETIRED) gentoo-dev 2012-10-18 00:26:52 UTC
Created attachment 326800 [details, diff]
Fix for AR

Fix for 1.2-r1.

It doesn't appear to still be a problem in 7.2d. I don't know what the current status of libatomic_ops is, so I don't know if this is worth fixing now or if it would be easier to just wait for the next stable version. Any input?
Comment 4 Samuli Suominen gentoo-dev 2012-10-18 09:14:36 UTC
and you are aware that autotools always hardcodes ar and ranlib, despite of setting AR or RANLIB?

that's at least what used to happen, unless something have changed since.
Comment 5 Vicente Olivert Riera (RETIRED) gentoo-dev 2012-10-25 23:05:15 UTC
(In reply to comment #4)
> and you are aware that autotools always hardcodes ar and ranlib, despite of
> setting AR or RANLIB?

I think that should not be allowed in Gentoo. What's your opinion?
Comment 6 Agostino Sarubbo gentoo-dev 2012-10-30 18:05:04 UTC
(In reply to comment #4)
> and you are aware that autotools always hardcodes ar and ranlib, despite of
> setting AR or RANLIB?
> 
> that's at least what used to happen, unless something have changed since.

As I said in 440274:

If Autotools is a crap, we are not forced to follow it.

The ebuild should respect the _SYSTEM_ AR, so the bug is valid.
Comment 7 Samuli Suominen gentoo-dev 2012-10-30 18:12:24 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > and you are aware that autotools always hardcodes ar and ranlib, despite of
> > setting AR or RANLIB?
> > 
> > that's at least what used to happen, unless something have changed since.
> 
> As I said in 440274:
> 
> If Autotools is a crap, we are not forced to follow it.
> 
> The ebuild should respect the _SYSTEM_ AR, so the bug is valid.

why? I see no reason to do so. cross-compiling works fine with the `ar`.
besides, half of the packages in tree use autotools, so that's a logical directive to follow. AR on Makefile only based build systems also includes the flags for it, there is no standard like 'ARFLAGS'
Comment 8 Samuli Suominen gentoo-dev 2012-10-30 18:16:10 UTC
actually, taking this back, later automake is actually respecting ARFLAGS unlike previous versions...

/usr/bin/automake-1.12:  &define_variable ('ARFLAGS', 'cru', INTERNAL);
Comment 9 SpanKY gentoo-dev 2012-10-30 20:04:38 UTC
ar/ranlib are not portable formats, so yes, we need to execute the target variant.  most people won't notice as they don't cross-compile between different operating systems.
Comment 10 Julian Ospald 2012-10-31 23:22:16 UTC
so this is actuallly an autotools bug?
Comment 11 SpanKY gentoo-dev 2012-11-15 18:36:45 UTC
(In reply to comment #10)

if you're creating libs, then you use libtool, and that handles ar/ranlib correctly.  automake seems a little wonky, but i'd have to poke more to see what it's doing exactly.  i think this is an uncommon case for projects to hit.
Comment 12 SpanKY gentoo-dev 2013-01-25 17:33:27 UTC
this is fixed in libatomic-7.2d