[Top][All Lists]
[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