From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: sid@sources.redhat.com, binutils@sourceware.org
Subject: Re: sid build issues
Date: Sun, 23 Aug 2009 18:02:00 -0000 [thread overview]
Message-ID: <20090823180204.GA17089@gmx.de> (raw)
In-Reply-To: <20090818191351.GB19793@redhat.com>
Hello,
* 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.
Thanks!
Ralf
prev parent reply other threads:[~2009-08-23 18:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-18 5:40 Ralf Wildenhues
2009-08-18 19:02 ` Ralf Wildenhues
2009-08-18 19:08 ` DJ Delorie
2009-08-18 19:13 ` Frank Ch. Eigler
2009-08-23 18:02 ` Ralf Wildenhues [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090823180204.GA17089@gmx.de \
--to=ralf.wildenhues@gmx.de \
--cc=binutils@sourceware.org \
--cc=fche@redhat.com \
--cc=sid@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).