[Top][All Lists]

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

Re: Libtool strips out -tp=k8-32 PGI compiler flag in link mode

From: Christopher Hulbert
Subject: Re: Libtool strips out -tp=k8-32 PGI compiler flag in link mode
Date: Thu, 26 Mar 2009 15:26:30 -0400

On Thu, Mar 26, 2009 at 3:06 PM, Ralf Wildenhues <address@hidden> wrote:
> * Ethan Mallove wrote on Thu, Mar 26, 2009 at 04:17:11PM CET:
>> On Sat, Mar/21/2009 11:47:42AM, Ralf Wildenhues wrote:
>> > * Ralf Wildenhues wrote on Sat, Mar 21, 2009 at 11:41:20AM CET:
>> > > Thanks for the bug report.  A workaround should be to
>> > >   ./configure CC="pgcc -tp=k8-32"
>> > >
>> > > and the following patch should fix the issue.  Can you try both?
>> >
>> > Never mind; the `-tp PROCESSOR' gets reordered badly by libtool anyway,
>> > so only `-tp=PROCESSOR' is feasible.  Updated patch below.  OTOH,
>> > another workaround should be to pass -Wc,-tp=k8-32 to `libtool
>> > --mode=link'.
>> AM_CFLAGS seems to do the trick, e.g.,
>>   $ make AM_CFLAGS='-Wc,-tp=k8-32'
> Yes.  But that can cause problems with packages where the compiler is
> also called directly from make, without the libtool script in between.

Because I work with compilers that have flags libtool does not pass
through, it has become a habit for me to develop my
autoconf/automake/libtool packages where the file defines
variables LT_CFLAGS, LT_FCFLAGS, LT_LDFLAGS so that the user (usually
me) can pass flags that use the form -Xcompiler,flag and
-XCClinker,flag. All of my automake files pass $(LT_CFLAGS), etc. to
libtool libraries. Perhaps it would be beneficial to add some form of
these to standard libtool so that all packages using new libtool
provide a way for the user to get flags passed libtool if necessary.
It would actually be nice if that would be passed to libtool in a way
that the user (again me a lot) did not have to add the -Xcompiler,
-XCClinker, etc. to make sure they get passed through libtool. Perhaps
one of the LT macros would look at that configure variable and
substitute it with the proper flag quoting?

Another idea would be to somehow provide an option for a
user/developer to specify a file with a set of known compiler flags
that libtool could match against, but that might slow things down
unless it is only done once at configure and not for every compile,
link, etc.

Just some thoughts from another PGI user.


>> > --- a/libltdl/config/ltmain.m4sh
>> > +++ b/libltdl/config/ltmain.m4sh
>> > @@ -4497,8 +4497,9 @@ func_mode_link ()
>> >        # -F/path gives path to uninstalled frameworks, gcc on darwin
>> >        # -p, -pg, --coverage, -fprofile-* pass through profiling flag for 
>> > GCC
>> >        # @file GCC response files
>> > +      # -tp=* Portland pgcc target processor selection
>> >        -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| 
>> > \
>> > -      -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*)
>> > +      -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*)
>> >          func_quote_for_eval "$arg"
>> >     arg="$func_quote_for_eval_result"
>> >          func_append compile_command " $arg"
>> I am using the latest Libtool from the git repo (Fri Mar 20 16:42:25),
>> with the above "-tp" patch and libtoolize is stuck pegging my CPU at
>> 99%.  I assume I should have been applying the "-tp" patch to a stable
>> Libtool version, e.g., 2.2.6?
> That's really weird.   libtoolize doesn't have anything to do with this.
> I have meanwhile tested the patch myself with a PGI compiler set,
> applied against the latest git Libtool, and found no problems.
> Can you be more specific in where libtoolize hangs?  I.e., run the
> command that hangs manually, with --debug added.  Also, autom4te is used
> for creating the libtoolize script, so please state the Autoconf version
> you are using.
> Thanks,
> Ralf
> _______________________________________________

reply via email to

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