libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 1 compiler (called from 2 symbolic links) -> 2 different libtool scr


From: Ethan Mallove
Subject: Re: 1 compiler (called from 2 symbolic links) -> 2 different libtool scripts
Date: Mon, 4 Aug 2008 16:52:12 -0400
User-agent: Mutt/1.5.17 (2007-11-01)

On Mon, Aug/04/2008 10:06:59PM, Ralf Wildenhues wrote:
> * Ethan Mallove wrote on Thu, Jul 24, 2008 at 06:17:05PM CEST:
> > On Thu, Jul/24/2008 09:51:20AM, Peter O'Gorman wrote:
> > > Ethan Mallove wrote:
> > > > Is it possible the libtool macros do things differently
> > > > depending on a symlink name?
> > > 
> > > The test is:
> > > case $cc_basename in
> > > CC*)
> > > 
> > > So this does not match 'sunCC'.
> > > 
> > > I guess we can change the test to match sunCC*|CC*).
> > 
> > That would be very helpful.
> > 
> > Could the test check the filename of the link target?
> 
> Not such a good idea; we've been suggesting people as
> workaround to add a symlinked name, to fool libtool (e.g.,
> gcc -> mpiCC or so).  Checking the link target would
> defeat that.
> 
> If checking the name is not good enough, then verbose/help
> output should be used for determining.  It is already in
> some cases.

Any thoughts on using the pre-defined compiler macros listed
at http://predef.sourceforge.net/precomp.html? Then the
compiler writers can change their symlinks and verbose/help
output all they want without affecting libtool macros. The
workaround would be setting CFLAGS, e.g., to spoof libtool
into detecting Sun Studio though *actually* using GNU:

  $ ./configure CFLAGS="-U__GNUC__ -D__SUNPRO_C ..."

Regards,
Ethan


> 
> Cheers,
> Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]