This is the mail archive of the
mailing list for the SID project.
Re: sid build issues
- From: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: sid at sources dot redhat dot com, binutils at sourceware dot org
- Date: Sun, 23 Aug 2009 20:02:04 +0200
- Subject: Re: sid build issues
- References: <20090818054018.GD28254@gmx.de> <20090818191351.GB19793@redhat.com>
* Frank Ch. Eigler wrote on Tue, Aug 18, 2009 at 09:13:51PM CEST:
> > 1) I've see weird, not easily reproducible failures of
> > make -jN
> > at least with --enable-maintainer-mode. Does anybody use it, is it
> > supposed to work? Are people aware of the issues, or should I report
> > them?
> I don't recall specific problems there. I appreciate you trying to
> work through them.
OK, will try. Found a couple already, but they weren't sid specific.
> > 2) Within sid, the link fails on x86_64 if I use neither --enable-shared
> > nor --disable-shared: [...]
> > I'm unsure as to the Right Way[tm] to fix this: sid/configure.in checks
> > whether $enable_shared was set to no, or checks whether
> > $ac_cv_libstdcxx_shared is != yes. [...]
> We'd like --enable-shared by default.
That's not sufficient to determine a solution to this issue, though:
the build-libiberty doesn't create a shared library unless it is passed
--enable-shared. Do you mean with this that build-libiberty should
enable shared if neither --enable-shared nor --disable-shares is passed?
If yes, then I guess that needs discussion needs a libiberty maintainer.
If no, then I don't understand how you can enable shared in sid when it
is not enabled in libiberty.
> > 3) I see a few (thousand) warnings of the form:
> > | ../../../../../src/sid/component/cgen-cpu/sh/sh5-compact-decode.cxx:221: warning: deprecated conversion from string constant to 'char*'
> > in several sid source files. Is there interest in fixing them, or
> > adding whatever command line argument make g++ permissive enough, to the
> > compile command lines?
> These files were generated by cgen. An eyeballing of the sources
> indicates that we have "const char*"s where they should be, so it
> should work. Perhaps cgen should spit out char's instead for those
> struct fields.
The problem isn't the "const char*" in the struct mep_idesc, but the
char* in CGEN_BITSET that is being initialized with string constants
like "\x80". This is defined in include/opcode/cgen-bitset.h.
> > 5) When building with --enable-maintainer-mode, and xsltproc 1.1.24
> > installed, I get lots of ignored errors (one per xml file) of the form
> > | xsltproc --output hw-visual-lcd.html ../../../../src/sid/component/lcd/../component_html.xsl ../../../../src/sid/component/lcd/hw-visual-lcd.xml
> > | runtime error: file ../../../../src/sid/component/lcd/../component_html.xsl line 21 element param
> > | Unexpected XSLT element 'param'.
> > | runtime error: file ../../../../src/sid/component/lcd/../component_html.xsl line 22 element choose
> > | Variable 'body' has not been declared.
> > | xmlXPathCompOpEval: parameter error
> > They somehow seem to be ignored by make however.
> I'll try to beat some xml/xslt cobwebs out of my brain to figure out
> which part of that pipeline is erroneous.