http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49178
--- Comment #3 from Jay Veeramony <jay.veeramony at nrlssc dot navy.mil>
2011-05-26 20:42:08 UTC ---
When I try to build and compile my code, autoconf is creating the configure
file that does the following:
----------------------
# Compile and link our simple test program by passing a flag (argument
# 1 to this macro) to the Fortran compiler in order to get
# "verbose" output that we can then parse for the Fortran linker
# flags.
ac_save_FCFLAGS=$FCFLAGS
FCFLAGS="$FCFLAGS $ac_cv_prog_fc_v"
eval "set x $ac_link"
shift
$as_echo "$as_me:${as_lineno-$LINENO}: $*" >&5
# gfortran 4.3 outputs lines setting COLLECT_GCC_OPTIONS, COMPILER_PATH,
# LIBRARY_PATH; skip all such settings.
ac_fc_v_output=`eval $ac_link 5>&1 2>&1 |
sed '/^Driving:/d; /^Configured with:/d;
'"/^[_$as_cr_Letters][_$as_cr_alnum]*=/d"`
$as_echo "$ac_fc_v_output" >&5
FCFLAGS=$ac_save_FCFLAGS
-----------------------
so when the space is seen, a blank seems to get assigned.
(In reply to comment #2)
> What exactly is the problem? Is the gfortran driver invoking a subprocess
> with separate "-l" and "gfortran" arguments? The code in gcc.c that does
>
> case OPT_l:
> /* POSIX allows separation of -l and the lib arg; canonicalize
> by concatenating -l with its arg */
> add_infile (concat ("-l", arg, NULL), "*");
> do_save = false;
> break;
>
> is supposed to act after lang_specific_driver has modified the command
> line, and should avoid that issue. Or is something processing the
> "Driving" line? I thought that line was human-readable output (complete
> with translation of the word "Driving"); it certainly isn't unambiguous in
> the presence of arguments containing spaces or newlines. If there are
> defined requirements on the "Driving" line, the code that outputs it
> should be adjusted to follow those requirements.
