This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: (Fwd) Re: Absolute paths in BFD
- To: eliz at is dot elta dot co dot il
- Subject: Re: (Fwd) Re: Absolute paths in BFD
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 28 Apr 2000 15:28:28 -0700
- CC: snowball3 at bigfoot dot com, binutils at sourceware dot cygnus dot com
- References: <3908583E.11552.3CB4AE@localhost> <200004282205.SAA26918@indy.delorie.com>
Date: Fri, 28 Apr 2000 18:05:16 -0400 (EDT)
From: Eli Zaretskii <eliz@delorie.com>
> Date sent: 26 Apr 2000 15:31:54 -0700
> From: Ian Lance Taylor <ian@zembu.com>
>
> > A few months ago someone posted a series of patches to handle this very
> >
> problem. See: > >
> http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00584.html >
> http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00585.html >
> http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00586.html >
> http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00587.html >
> http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00588.html >
> http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00589.html >
> http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00590.html
>
> I feel like I would rather copy the names that gcc uses:
> IS_DIR_SEPARATOR, IS_PATH_SEPARATOR, HAVE_DOS_BASED_FILE_SYSTEM, etc.
>
> In fact, I said that a long time ago:
> http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00596.html
In the conversation that followed the above message, I told you that
the macros I used in my patches are used in other GNU projects, like
Texinfo and Grep. You then said that you were willing to accept them
as well. So I patiently waited for the patches to be
reviewed/accepted.
Whoops, sorry. I forgot about that.
binutils maintenance is not working well these days. I apologize. I
simply don't have time to fully consider patches.
If you want to reconsider that decision, I could rework the patches
(although I don't understand why the GCC's way of parameterizing these
macros is better than that of the other projects).
gcc's way is better because gcc and the binutils share the directories
include and libiberty. You've added a file to include, for example;
that file should really be added to the gcc repository as well.
But please give me
some hope that the new patches will be reviewed and committed to the
Binutils CVS tree somewhat faster than the previous ones. It can be
quite frustrating to go through all the coding and testing once again,
only to see the patches stuck in the queue for another 6 months ;-).
I wish I could give you that hope, but I can't. If the patch is
simple, I can approve it quickly. Otherwise, some other maintainer
has to do it.
> Testing something like DOSISH_FILENAMES in binutils/ar.c looks wrong.
> DOSISH_FILENAMES is meaningful on the host, but binutils/ar.c deals
> with files that are specific to the target.
The code fragments conditioned on DOSISH_FILENAMES in ar.c do not
contradict the original code (which considers forward slashes only),
they _augment_ it. That is, the code looks for forward slashes, and
then for backslashes.
So I don't think there's a problem here. But if you think this might
be a problem for Windows-hosted development environments whose targets
can be harmed by this code, I could make those fragments conditioned
on __DJGPP__, where the host and the target are the same.
Good point.
> The changes to binutils/strings.c and gprof/gmon_io.h assume that any
> system with O_BINARY has setmode and isatty, and I don't think that's
> true.
Please suggest an alternative. Would you like a separate definition
for setmode?
As for isatty, I'm not aware of a C library that doesn't have it. But
if you would like a separate macro for it, I can do that, too.
Yes, I think setmode could be a problem. It might be best to test for
that separately.
Ian