This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sid build issues


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]