Bug 438332 – =dev-libs/libatomic_ops-1.2-r1 calls AR directly

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Vicente Olivert Riera (RETIRED) 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 (RETIRED) 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) 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) 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 (RETIRED) 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) 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 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 (RETIRED) 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 (RETIRED) 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 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 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 2013-01-25 17:33:27 UTC]

this is fixed in libatomic-7.2d