Paul Edwards wrote:
> The thing is, I already know it has detected that I don't have
> strcasecmp. That's why it doesn't have HAVE_STRCASECMP
> defined in the config.h. You are right that I don't have a linker,
> but the compile with error-on-no-prototype is working fine - I
> can see the result in config.h.
Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.
This gets set during the macro call
AC_REPLACE_FUNCS($funcs)
in configure.ac, which gets replaced by the following code
in configure (GCC 3.4):
for ac_func in $funcs
do
as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
echo "$as_me:$LINENO: checking for $ac_func" >&5
echo $ECHO_N "checking for $ac_func... $ECHO_C" >&6
[...]
if test `eval echo '${'$as_ac_var'}'` = yes; then
cat >>confdefs.h <<_ACEOF
#define `echo "HAVE_$ac_func" | $as_tr_cpp` 1
_ACEOF
else
LIBOBJS="$LIBOBJS $ac_func.$ac_objext"
fi
done
So if you do not have HAVE_STRCASECMP in config.h, you should
have been getting strcasecmp.o in LIBOBJS ...
> > Why would you define this by hand? The usual make process will
> > define PREFIX while building prefix.c, using the appropriate
> > value determined at configure time ...
>
> Because when my assemble and compile jobs start running on
> MVS, I would first of all need to put in a special define for that
> in the compile step for prefix - the only exception in fact. Secondly,
> I am running close to the 100-character limit of the PARM
> statement already, with the things I was forced to add:
>
> //ST2CMP PROC GCCPREF='GCC',MEMBER='',
> // PDPPREF='PDPCLIB',
> // COS1='-Os -S -ansi -pedantic-errors -remap -DHAVE_CONFIG_H',
> // COS2='-DIN_GCC -DPUREISO -o dd:out -'
>
> Having another define, just to define an empty string, seems very
> ugly indeed, even assuming it comes in under 100 characters.
Ah, OK.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
