Discussion:
gdb moxie build failure
(too old to reply)
Joel Sherrill
2014-08-18 22:14:52 UTC
Permalink
Raw Message
Hi

gdb on the head has moxie-rtems fail like this:

echo "/* generated by Makefile */" > tmp-hw.h
/bin/sh ../../../binutils-gdb/sim/moxie/../common/create-version.sh
../../../binutils-gdb/sim/moxie/.. x86_64-unknown-linux-gnu
moxie-rtems4.11 version.c
sim_hw=""; \
for hw in $sim_hw ; do \
echo "extern const struct hw_descriptor dv_${hw}_descriptor[];" ; \
done >> tmp-hw.h
dtc -O dtb -o moxie-gdb.dtb ../../../binutils-gdb/sim/moxie/moxie-gdb.dts
make[3]: dtc: Command not found
echo "const struct hw_descriptor *hw_descriptors[] = {" >> tmp-hw.h
make[3]: *** [moxie-gdb.dtb] Error 127
make[3]: *** Waiting for unfinished jobs....
sim_hw=""; \
for hw in $sim_hw ; do \

Is dtc a required tool that is not checked for? Is the output in the tree
but not timestamped? maintainer only tool?

Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
***@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Mike Frysinger
2014-08-19 05:38:20 UTC
Permalink
Raw Message
Post by Joel Sherrill
echo "/* generated by Makefile */" > tmp-hw.h
/bin/sh ../../../binutils-gdb/sim/moxie/../common/create-version.sh
../../../binutils-gdb/sim/moxie/.. x86_64-unknown-linux-gnu
moxie-rtems4.11 version.c
sim_hw=""; \
for hw in $sim_hw ; do \
echo "extern const struct hw_descriptor dv_${hw}_descriptor[];" ; \
done >> tmp-hw.h
dtc -O dtb -o moxie-gdb.dtb ../../../binutils-gdb/sim/moxie/moxie-gdb.dts
make[3]: dtc: Command not found
echo "const struct hw_descriptor *hw_descriptors[] = {" >> tmp-hw.h
make[3]: *** [moxie-gdb.dtb] Error 127
make[3]: *** Waiting for unfinished jobs....
sim_hw=""; \
for hw in $sim_hw ; do \
Is dtc a required tool that is not checked for? Is the output in the tree
but not timestamped? maintainer only tool?
yeah, you need dtc for moxie. it's been this way forever ? for people
building from git, i think it's fine. it also leads me to a topic i've been
meaning to start for a while, so let's fork the thread.

what issues are there with making the sim use the existing dtc project ? the
dtc tool is licensed under the GPL-2 or later, and the libfdt library is dual
licensed (BSD-2 & GPL-2 or later).
http://www.devicetree.org/Device_Tree_Compiler

the reason i ask is that the existing sim code uses device tree style logic
heavily as it comes from the ppc sim import/commonization logic. afaik, this
codebase is somewhat a predecessor of the dtc codebase -- they both originated
at IBM, and the ppc sim is dated mid-1990's while dtc is dated mid-2000. i'm
not saying they necessarily share actual code, but they certainly have shared
lineage above that. at this point though, the syntax has diverged quite a
bit, so i'd love to just gut all the logic in sim and use the common dtc
package as that's what the rest of the world is using now. it'd also make it
easier to share device tree definitions between projects (sim/u-
boot/linux/etc...).

importing dtc in directly would be my preference, but iiuc, people would
prefer to only import FSF owned projects. i know that ship sailed long ago
with the sim codebase (large portions of it are not owned by the FSF), but
still the FSF seems to want to keep that from expanding further.

so i guess that leaves us with linking against a system copy. i'm fine with
that too. thoughts ?
-mike
Joel Brobecker
2014-08-19 06:25:57 UTC
Permalink
Raw Message
Post by Mike Frysinger
so i guess that leaves us with linking against a system copy. i'm fine with
that too. thoughts ?
Do I understand correctly that this is the status quo?
--
Joel
Mike Frysinger
2014-08-20 09:33:16 UTC
Permalink
Raw Message
Post by Joel Brobecker
Post by Mike Frysinger
so i guess that leaves us with linking against a system copy. i'm fine
with that too. thoughts ?
Do I understand correctly that this is the status quo?
gdb links against system libs which the FSF has no control over:
- python
- xz-utils (lzma)
- expat
- zlib

this last one is also included directly in the gcc tree (also the sourceware
tree in the past iirc)

gcc links to non-FSF 3rd party libs, albeit doesn't bundle them

so after talking to myself, i guess the issue isn't so much with using the
system copy of dtc as it is with making it a hard requirement (which is
different from how the other packages use 3rd party libs -- they're all
optional). might be able to reduce the requirement so only the hw layers hard
depend on it, but i'm not sure if even that is possible.
-mike
Joel Brobecker
2014-08-20 09:53:47 UTC
Permalink
Raw Message
Post by Mike Frysinger
so after talking to myself, i guess the issue isn't so much with using
the system copy of dtc as it is with making it a hard requirement
(which is different from how the other packages use 3rd party libs --
they're all optional). might be able to reduce the requirement so
only the hw layers hard depend on it, but i'm not sure if even that is
possible.
OK. Is that dependency on dtc something new? Or was it there already
for certain sims and not others?

Dependency requirements like these should be discussed on a
case-per-case basis, I think. And the answers to the questions
you ask above (can it be made optional, what functionality gets
lost, etc) definitely influence the decision.
--
Joel
Loading...