Re: libstdc++ configure fail due to -EL option

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 2532 bytes --]

On Monday 23 January 2012 17:37:34 Yann E. MORIN wrote:
> On Monday 23 January 2012 23:08:16 Mike Frysinger wrote:
> > On Monday 23 January 2012 16:08:39 Bryan Hundven wrote:
> > > On Wed, Jan 18, 2012 at 2:28 AM, Mike Frysinger wrote:
> > > > LDFLAGS should take the form as needed by the compiler driver.  i.e.
> > > > -Wl,-EL.
> > > 
> > > Well, we'd get the same error if we pass -Wl,-EL to ld, where that
> > > would fix it for passing to gcc.
> > 
> > yes, but generally speaking, you should not be invoking the linker.
> > everything should be going through the compiler driver.
> 
> <IMHO mode="rant">
> I don't care if everything "should be going through the compiler driver" or
> directly through the actual linker.

the problem is that people encode and select a variety of things at the 
compiler level without providing the equivalent linker settings.  such as 
sysroot, architecture, multilib, float abi, endian, etc...  by invoking 
everything through the compiler, all of that is taken care of for you.

> What I find dubious is to pass the LDFLAGS to the compiler driver. The
> LDFLAGS are for the linker. If one wants to use the compiler driver to do
> the link, I don't care, but then the LDFLAGS should first be appropriately
> munged to be suitable for the compiler driver, and not used as-is.

this violates the standard.  autotools and make pass LDFLAGS directly to the 
compiler driver, and most every other build system out there follows suite.  
attempting to fight the accepted standard is a waste of time :P.

(this ignores the linux kernel build system, but that is the exception, not 
the rule)

> It's in large parts the fault of gcc (the package) for providing a compiler
> _driver_ in the first place. *Either* it does its job, and only its job,
> to drive the _compilation_ (and preprocessing), and it is not used for
> other phases, such as linking, *or* it also accepts to _fully_ impersonate
> the linker. Currently, the gcc compiler driver recognises parts of the
> linker flags (eg. -static), but chokes on others (eg. --fatal-warnings),
> which makes it useless to effectively be called in-lieu of the linker.

forcibly splitting up the compiler and linker stages, as well as duplicating 
the flags (which don't have clear equivalents between `gcc` and `ld`) is a step 
back in time

> And what's worse, some packages are properly calling the linker 'ld', and
> needs LDFLAGS suitable for 'ld'

what packages (other than the kernel) ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]