Re: gtyp-input.list should contain absolute paths.
* Basile STARYNKEVITCH wrote on Fri, Jul 03, 2009 at 03:51:00PM CEST: > > The patch below solves the issue, but the generated gtype-input.list > contains too much empty blank lines. Any suggestions on how to solve > this? > +## compute the realpath of above GTFILES - keeping language tags as before > +REALGTFILES = $(foreach f, $(GTFILES), $(if $(patsubst [%],,$f), > $(realpath $f), $f)) In general please get your mailer to not mangle long lines in patches. In this case, the mangling helped to provide the clue: you have too much white space in this line, try using this instead: REALGTFILES := $(foreach f, $(GTFILES),$(if $(patsubst [%],,$f),$(realpath $f),$f)) because those extra spaces show up in the output. Cheers, Ralf
Re: g-socket.adb error
On Fri, 2009-07-03 at 13:47 -0500, Joel Sherrill wrote: > Hi, > > Apparently no one has hit this case. RTEMS does > not have two error codes that g-socket.adb > maps back. From s-oscons.ads: > >ESHUTDOWN : constant := -1; -- Cannot send once > shutdown >ESOCKTNOSUPPORT : constant := -1; -- Socket type not > supported > > This results in a compilation error in g-socket.adb > in the switch since they both have the same value: > > g-socket.adb:1775:15: duplication of choice value at line 1773 > > Any thoughts? Just above the case there is already one case of duplicate error code handled by an explicit "if" instead of "case": if EAGAIN /= EWOULDBLOCK and then Error_Value = EAGAIN then return Resource_Temporarily_Unavailable; end if; I guess moving from case to if would be an appropriate way to fix this RTEMS issue (assuming this is the only conflict), Thomas is in Cc. Laurent
Re: -print-* command-line switches misbehave or are misdocumented
Eli Zaretskii writes: > Some of the -print-* command-line switches either don't work as > advertised or their documentation should be made more clear. > > All of the examples below are with the following version of GCC: > > gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > I also tested with this version, with the same results. > > gcc (GCC) 3.4.2 (mingw-special) > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. Hi Eli. I'm sure you know that those are old versions of gcc, although your comments are still generall apropos. > Please tell whether I should submit a bug report for some or all of > the below. These options are generally intended for use by compiler developers, not by end users. I think it would be good to provide better documentation. But it's not high priority nor particularly interesting. Opening a bug report wouldn't hurt, but I doubt anybody would jump on it. > 1. -print-multi-directory: Documentation is confusing and unclear. > > The manual says: > > `-print-multi-directory' >Print the directory name corresponding to the multilib selected by >any other switches present in the command line. This directory is >supposed to exist in `GCC_EXEC_PREFIX'. > > But without having ``multilib'' explained anywhere else in the > manual, let alone having a cross-reference here to such a > description, there's no way to understand what this switch does. I agree that this documentation is completely useless. multilib is documented, somewhat, in the internals manual. http://gcc.gnu.org/onlinedocs/gccint/Target-Fragment.html A reference over there would be reasonable. > 2. -print-multi-lib: Same issue as with the previous switch. Same answer. > 3. -print-prog-name: Works only for some programs; manual text > misleading. > > The manual says: > > `-print-prog-name=PROGRAM' >Like `-print-file-name', but searches for a program such as `cpp'. > > It fails to say what programs will this work with. The example it > gives, `cpp' doesn't work: > > e...@fencepost:~$ gcc -print-prog-name=cpp > cpp Yeah, that's a clear doc bug. It used to work with "cpp", but not with current gcc releases. > Similarly, it doesn't work with `gcc' itself, which seems a pity, > as it doesn't allow to write scripts that discover where GCC > lives. If you are using cachecc or distcc, the question of where GCC lives is somewhat ambiguous in any case. Ian
Re: gtyp-input.list should contain absolute paths.
Basile STARYNKEVITCH writes: >@: $(call write_entries_to_file,$(realpath $(GTFILES)),tmp-gi.list) >$(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list >$(STAMP) s-gtyp-input In general, one should try to avoid changing a user specified relative path to an absolute path. In this case, the user specification comes from how they invoked configure. Absolute paths have different behaviour in automount environments. It's OK to temporarily change from a relative to an absolute path, but changing to an absolute path and writing that to a file should be avoided when possible. It's not clear to me why plugins need to deal with gtyp-input.list. I thought we were trying to make it possible to build plugins with a set of installed header files. If plugins need to read gtyp-plugin.list, they need access to the complete source code. In that case, can't they just apply the same transformations that gengtype itself applies? Ian
Re: -print-* command-line switches misbehave or are misdocumented
Ian Lance Taylor wrote: > Eli Zaretskii > 3. -print-prog-name: Works only for some programs; manual text >> misleading. >> >> The manual says: >> >> `-print-prog-name=PROGRAM' >> Like `-print-file-name', but searches for a program such as `cpp'. >> >> It fails to say what programs will this work with. The example it >> gives, `cpp' doesn't work: >> >> e...@fencepost:~$ gcc -print-prog-name=cpp >> cpp > > Yeah, that's a clear doc bug. It used to work with "cpp", but not with > current gcc releases. > >> Similarly, it doesn't work with `gcc' itself, which seems a pity, >> as it doesn't allow to write scripts that discover where GCC >> lives. > > If you are using cachecc or distcc, the question of where GCC lives is > somewhat ambiguous in any case. Well, the simple rule is "It can tell you where any program that gcc might invoke lives", isn't it? That would explain why it can locate cc1, ld and as, but not gcc or ls, and why it used to be able to locate cpp when it used to invoke cpp, but not since. cheers, DaveK
Re: -print-* command-line switches misbehave or are misdocumented
> Date: Sun, 05 Jul 2009 00:33:44 +0100 > From: Dave Korn > CC: Eli Zaretskii , gcc@gcc.gnu.org > > >> e...@fencepost:~$ gcc -print-prog-name=cpp > >> cpp > > > > Yeah, that's a clear doc bug. It used to work with "cpp", but not with > > current gcc releases. > > > >> Similarly, it doesn't work with `gcc' itself, which seems a pity, > >> as it doesn't allow to write scripts that discover where GCC > >> lives. > > > > If you are using cachecc or distcc, the question of where GCC lives is > > somewhat ambiguous in any case. > > Well, the simple rule is "It can tell you where any program that gcc might > invoke lives", isn't it? That would explain why it can locate cc1, ld and as, > but not gcc or ls, and why it used to be able to locate cpp when it used to > invoke cpp, but not since. Granted, I know very well why it doesn't work with cpp and gcc. But I was talking about _user_documentation_, and from the user's point of view (as opposed to GCC programmer/hacker POV), the distinction is not quite obvious. Either the docs should be fixed to make that clear, or (better) the code should be modified to support all related programs.
Re: gtyp-input.list should contain absolute paths.
Ian Lance Taylor wrote:
Basile STARYNKEVITCH writes:
@: $(call write_entries_to_file,$(realpath $(GTFILES)),tmp-gi.list)
$(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list
$(STAMP) s-gtyp-input
In general, one should try to avoid changing a user specified relative
path to an absolute path. In this case, the user specification comes
from how they invoked configure. Absolute paths have different
behaviour in automount environments. It's OK to temporarily change from
a relative to an absolute path, but changing to an absolute path and
writing that to a file should be avoided when possible.
It's not clear to me why plugins need to deal with gtyp-input.list.
In plugin mode (for the few plugins using PLUGIN_REGISTER_GGC_ROOTS),
gengtype needs a file list. So a plugin build (in its own directory)
would want to run (in Makefile syntax)
$(GCCBUILD)/gcc/gengtype -p $(GCCSOURCE)/gcc
$(GCCBUILD)/gcc/gtype-input.list plugin.c
However, this won't work, because the gtype-input.list contains (even
when GCC was configured with absolute paths) a few relative file paths
(notably auto-host.h).
I
thought we were trying to make it possible to build plugins with a set
of installed header files. If plugins need to read gtyp-plugin.list,
they need access to the complete source code.
Yes, but a Makefile for a plugin cannot even use the
$(GCCBUILD)/gcc/gtype-input.list it should transform it to transform
relative paths to absolute ones, and that is painful.
In that case, can't they
just apply the same transformations that gengtype itself applies?
I don't understand what transformations are you referring to.
However, there might be another solution: have the gcc/Makefile.in
generate both the current gtype-input.list and another
gtype-input-absolute.list which contains only absolute paths, and
document that plugins could use that gtype-input-absolute.list (perhaps
adding a caveat about automounters).
What do you think??
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
