This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
- From: "fxcoudert at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Sep 2007 09:33:48 -0000
- Subject: [Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
- References: <bug-21185-507@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-13 09:33 -------
I'm coming back to that issue...
(In reply to comment #4)
> I guess we could try to provide a graceful degradation for such systems...
> The use of dup() can probably be avoided if dup() isn't available
> without too much degradation in the library features.
I still think it's better than nothing. It will gives weird results when people
start closing preconnected units, but we can document that behaviour.
Otherwise, we can use another technique to create new descriptors for
stdin/stdout/stderr, but I can't think of something that would work easily.
> access() can probably be emulated, or at least its basic features.
libgfortran only use it with modes R_OK, W_OK and R_OK | W_OK. These uses can
be emulated with calls to open().
> For ftruncate(), however, I don't see how to make it work.
ftruncate() is now protected by HAVE_FTRUNCATE, so this one shouln't be a
problem any more.
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu dot
| |org
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-01-05 10:06:52 |2007-09-13 09:33:48
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185