This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: cpplib: basename () fix


> (2) You can't use a run-this test for libiberty because it's built for
> the target also, where you can't run anything.  Plus, if you're cross
> building, you can't run "host" programs either.

It looks like the test is located with other run-this tests (eg.,
AC_PROG_CC_WORKS, AC_FUNC_ALLOCA and AC_FUNC_VFORK).  It only runs
if "setobjs" is empty.  Possibly, the test could be skipped if the
compiler doesn't work and "basename" would then be non-optional.
As it is, basename is added to LIBOBJS is the test fails for any
reason.

> (3) If the results of passing an empty string are undefined
> standards-wise, programs should be careful not to pass empty strings.
> Otherwise, we might as well make basename() non-optional in libiberty,
> for the day when all platforms "fix" their basename.  I hesitate to do
> this, as we'd then be promoting obsolete behavior.

The problem is not because the results of passing an empty string is
undefined standards-wise.  There are two incompatible variants for
basename: the glibc/libiberty name-with-directory variant and the XPG/POSIX
variant <http://www.opengroup.org/onlinepubs/007908799/xsh/basename.html>.
I highly doubt that the day will come where all platforms "fix" their
basename and adopt the glibc variant.

I think it is the wrong approach for user code to work around the
differences.  Gcc needs a collection of basic library routines which have
a defined behaviour.  The restriction of no run-tests for libiberty
seems extreme since this can be done in the most common situation where
the build, host and target are the same.

Some ports cause symbolic links from libiberty to the gcc directory
for needed routines such as alloca.  This is a hack since the include
and config files aren't exactly right.  Here is an example from a PA
build:

rm -f alloca.c
ln -s ../../gcc/../libiberty/alloca.c alloca.c
gcc  -DIN_GCC    -g  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include \
 -c alloca.c
alloca.c:94: warning: function declaration isn't a prototype
alloca.c:119: warning: function declaration isn't a prototype

There must be a better way.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]