From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31170 invoked by alias); 23 Aug 2009 18:02:23 -0000 Received: (qmail 30791 invoked by uid 22791); 23 Aug 2009 18:02:21 -0000 X-SWARE-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS,URIBL_BLACK X-Spam-Check-By: sourceware.org Received: from mail.gmx.net (HELO mail.gmx.net) (213.165.64.20) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sun, 23 Aug 2009 18:02:10 +0000 Received: (qmail invoked by alias); 23 Aug 2009 18:02:06 -0000 Received: from xdsl-87-78-160-69.netcologne.de (EHLO localhost.localdomain) [87.78.160.69] by mail.gmx.net (mp064) with SMTP; 23 Aug 2009 20:02:06 +0200 Received: from ralf by localhost.localdomain with local (Exim 4.69) (envelope-from ) id 1MfHOG-0004S5-VL; Sun, 23 Aug 2009 20:02:04 +0200 Date: Sun, 23 Aug 2009 18:02:00 -0000 From: Ralf Wildenhues To: "Frank Ch. Eigler" Cc: sid@sources.redhat.com, binutils@sourceware.org Subject: Re: sid build issues Message-ID: <20090823180204.GA17089@gmx.de> References: <20090818054018.GD28254@gmx.de> <20090818191351.GB19793@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090818191351.GB19793@redhat.com> User-Agent: Mutt/1.5.20 (2009-08-09) Mailing-List: contact sid-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00009.txt.bz2 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