public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/108287] New: AVR build: gcc/config/avr/t-avr tries to edit the source tree
@ 2023-01-04 18:02 nicow.mattia at gmail dot com
2023-01-04 18:08 ` [Bug target/108287] " pinskia at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: nicow.mattia at gmail dot com @ 2023-01-04 18:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
Bug ID: 108287
Summary: AVR build: gcc/config/avr/t-avr tries to edit the
source tree
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: nicow.mattia at gmail dot com
Target Milestone: ---
This only occurs when building for target=avr.
As per the build instructions, I'm building GCC out of the source tree. The
configure call looks like this:
```
$src/configure \
--target=avr \
--prefix=$out \
...
```
Here, `$src` is a RO directory, and the build will eventually fail like this:
```
...
g++ -std=gnu++11
/nix/store/7m0zk6xl14rkgi420mxyl0klssf7dhnb-gcc-src-patched/gcc/config/avr/gen-avr-mmcu-texi.cc
-o gen-avr-mmcu-texi
./gen-avr-mmcu-texi >
/nix/store/7m0zk6xl14rkgi420mxyl0klssf7dhnb-gcc-src-patched/gcc/doc/avr-mmcu.texi
/bin/sh:
/nix/store/7m0zk6xl14rkgi420mxyl0klssf7dhnb-gcc-src-patched/gcc/doc/avr-mmcu.texi:
Permission denied
```
The culprit is `gcc/config/avr/t-avr` at line 94:
```
$(srcdir)/doc/avr-mmcu.texi: gen-avr-mmcu-texi$(build_exeext)
$(RUN_GEN) ./$< > $@
```
I'm currently using the following patch to work around the issue:
```
diff --git a/gcc/config/avr/t-avr b/gcc/config/avr/t-avr
index deadbeef..deadbeef 100644
--- a/gcc/config/avr/t-avr 2023-01-03 21:56:23
+++ b/gcc/config/avr/t-avr 2023-01-03 21:56:32
@@ -91,9 +91,6 @@
$(srcdir)/config/avr/avr-arch.h $(TM_H)
$(CXX_FOR_BUILD) $(CXXFLAGS_FOR_BUILD) $< -o $@ $(INCLUDES)
-$(srcdir)/doc/avr-mmcu.texi: gen-avr-mmcu-texi$(build_exeext)
- $(RUN_GEN) ./$< > $@
-
s-device-specs: gen-avr-mmcu-specs$(build_exeext)
rm -rf device-specs
mkdir device-specs && cd device-specs && $(RUN_GEN) ../$<
```
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/108287] AVR build: gcc/config/avr/t-avr tries to edit the source tree
2023-01-04 18:02 [Bug other/108287] New: AVR build: gcc/config/avr/t-avr tries to edit the source tree nicow.mattia at gmail dot com
@ 2023-01-04 18:08 ` pinskia at gcc dot gnu.org
2023-01-04 18:08 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-04 18:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The best fix is do something similar to aarch64 in config/aarch64/t-aarch64:
$(srcdir)/config/aarch64/aarch64-tune.md: s-aarch64-tune-md; @true
s-aarch64-tune-md: $(srcdir)/config/aarch64/gentune.sh \
$(srcdir)/config/aarch64/aarch64-cores.def
$(SHELL) $(srcdir)/config/aarch64/gentune.sh \
$(srcdir)/config/aarch64/aarch64-cores.def > \
tmp-aarch64-tune.md
ifneq ($(strip $(ENABLE_MAINTAINER_RULES)),)
$(SHELL) $(srcdir)/../move-if-change tmp-aarch64-tune.md \
$(srcdir)/config/aarch64/aarch64-tune.md
else
@if ! cmp -s tmp-aarch64-tune.md \
$(srcdir)/config/aarch64/aarch64-tune.md; then \
echo "aarch64-tune.md has changed; either"; \
echo "configure with --enable-maintainer-mode"; \
echo "or copy tmp-aarch64-tune.md to
$(srcdir)/config/aarch64/aarch64-tune.md"; \
exit 1; \
fi
endif
$(STAMP) s-aarch64-tune-md
I suspect the issue is rather the timestamp on the files is incorrect causing
the trying of generating of the file.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/108287] AVR build: gcc/config/avr/t-avr tries to edit the source tree
2023-01-04 18:02 [Bug other/108287] New: AVR build: gcc/config/avr/t-avr tries to edit the source tree nicow.mattia at gmail dot com
2023-01-04 18:08 ` [Bug target/108287] " pinskia at gcc dot gnu.org
@ 2023-01-04 18:08 ` pinskia at gcc dot gnu.org
2023-01-04 18:11 ` nicow.mattia at gmail dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-04 18:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-01-04
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/108287] AVR build: gcc/config/avr/t-avr tries to edit the source tree
2023-01-04 18:02 [Bug other/108287] New: AVR build: gcc/config/avr/t-avr tries to edit the source tree nicow.mattia at gmail dot com
2023-01-04 18:08 ` [Bug target/108287] " pinskia at gcc dot gnu.org
2023-01-04 18:08 ` pinskia at gcc dot gnu.org
@ 2023-01-04 18:11 ` nicow.mattia at gmail dot com
2023-01-21 12:33 ` gjl at gcc dot gnu.org
2023-01-21 12:34 ` gjl at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: nicow.mattia at gmail dot com @ 2023-01-04 18:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
--- Comment #3 from Nicolas Mattia <nicow.mattia at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> The best fix is do something similar to aarch64 in config/aarch64/t-aarch64:
> $(srcdir)/config/aarch64/aarch64-tune.md: s-aarch64-tune-md; @true
> s-aarch64-tune-md: $(srcdir)/config/aarch64/gentune.sh \
> $(srcdir)/config/aarch64/aarch64-cores.def
> $(SHELL) $(srcdir)/config/aarch64/gentune.sh \
> $(srcdir)/config/aarch64/aarch64-cores.def > \
> tmp-aarch64-tune.md
> ifneq ($(strip $(ENABLE_MAINTAINER_RULES)),)
> $(SHELL) $(srcdir)/../move-if-change tmp-aarch64-tune.md \
> $(srcdir)/config/aarch64/aarch64-tune.md
> else
> @if ! cmp -s tmp-aarch64-tune.md \
> $(srcdir)/config/aarch64/aarch64-tune.md; then \
> echo "aarch64-tune.md has changed; either"; \
> echo "configure with --enable-maintainer-mode"; \
> echo "or copy tmp-aarch64-tune.md to
> $(srcdir)/config/aarch64/aarch64-tune.md"; \
> exit 1; \
> fi
> endif
> $(STAMP) s-aarch64-tune-md
>
> I suspect the issue is rather the timestamp on the files is incorrect
> causing the trying of generating of the file.
I see you already confirmed, so let me re-confirm. Not only is the `$src`
directory read-only, but all timestamps are set to the epoch.
I'm happy to contribute the fix but will need some hand holding!
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/108287] AVR build: gcc/config/avr/t-avr tries to edit the source tree
2023-01-04 18:02 [Bug other/108287] New: AVR build: gcc/config/avr/t-avr tries to edit the source tree nicow.mattia at gmail dot com
` (2 preceding siblings ...)
2023-01-04 18:11 ` nicow.mattia at gmail dot com
@ 2023-01-21 12:33 ` gjl at gcc dot gnu.org
2023-01-21 12:34 ` gjl at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: gjl at gcc dot gnu.org @ 2023-01-21 12:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
--- Comment #4 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Well, updating or creating some auto-generated files is intentional.
What's not supported as of GCC documentation is configure'ing in the source
tree:
https://gcc.gnu.org/install/configure.html
> First, we **highly** recommend that GCC be built into a separate directory
> from the sources which does not reside within the source tree.
> This is how we generally build GCC; building where srcdir == objdir
> should still work, but doesn’t get extensive testing; building where
> objdir is a subdirectory of srcdir is unsupported.
The reason why it does not work for you might be:
1) Maybe you changed avr-mcus.def to support more devices. This change will
trigger more changes, for example to auto-generated documentation (texi) bits.
This means you are basically a maintainer, which in turn means you migth have
more jobs to do, or tools to use than a simple user who just builds GCC from
source.
2) When you get the sources from some repo like git, the checked-out sources
might have timestamps that don't reflect their true state. This triggers make
to re-build auto-generated files, even though no prerequisite was changed and
the targets need not be rebuilt.
To fix this, run
./contrib/gcc_update --touch
from the top-level source dir. This script will touch some source files and
fix their timestamps. You obviously need write permission for that.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug target/108287] AVR build: gcc/config/avr/t-avr tries to edit the source tree
2023-01-04 18:02 [Bug other/108287] New: AVR build: gcc/config/avr/t-avr tries to edit the source tree nicow.mattia at gmail dot com
` (3 preceding siblings ...)
2023-01-21 12:33 ` gjl at gcc dot gnu.org
@ 2023-01-21 12:34 ` gjl at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: gjl at gcc dot gnu.org @ 2023-01-21 12:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108287
--- Comment #5 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
...ok, yes, building outside srcdir won't fix this one. But points 1) and 2)
still apply.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-01-21 12:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-04 18:02 [Bug other/108287] New: AVR build: gcc/config/avr/t-avr tries to edit the source tree nicow.mattia at gmail dot com
2023-01-04 18:08 ` [Bug target/108287] " pinskia at gcc dot gnu.org
2023-01-04 18:08 ` pinskia at gcc dot gnu.org
2023-01-04 18:11 ` nicow.mattia at gmail dot com
2023-01-21 12:33 ` gjl at gcc dot gnu.org
2023-01-21 12:34 ` gjl at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).