public inbox for sid@sourceware.org
 help / color / mirror / Atom feed
From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: sid@sources.redhat.com
Cc: binutils@sourceware.org
Subject: sid build issues
Date: Tue, 18 Aug 2009 05:40:00 -0000	[thread overview]
Message-ID: <20090818054018.GD28254@gmx.de> (raw)

Hello sid maintainers,

I'm trying to build the full src tree,
  ../src/configure && make

on x86_64-unknown-linux-gnu, without and with --enable-maintainer-mode
(before trying to update it to newer autotools).

A few things show up:

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?


2) Within sid, the link fails on x86_64 if I use neither --enable-shared
nor --disable-shared:

| make[7]: Entering directory `/tmp/build/sid/component/cgen-cpu'
| /bin/sh ./libtool --tag=CXX --mode=link g++ -g -O2     -o libcgencpu.la -rpath /usr/local/lib/sidcomp -module -no-undefined compCGEN.lo cgen-fpu.lo fp.lo tracedis.lo arm7t/libarm7t.la m32r/libm32r.la mep/libmep.la mt/libmt.la sh/libsh.la xstormy16/libxstormy16.la  -L../../../libiberty/pic -L../../../libiberty -liberty cgen-asm.lo cgen-dis.lo cgen-opc.lo dis-buf.lo dis-init.lo cgen-bitset.lo -lpthread -lm 
| ./libtool: line 1803: cd: ../../../libiberty/pic: No such file or directory
| libtool: link: cannot determine absolute directory name of `../../../libiberty/pic'
| make[7]: *** [libcgencpu.la] Error 1
| make[7]: Leaving directory `/tmp/build/sid/component/cgen-cpu'
| make[6]: *** [all-recursive] Error 1
| make[6]: Leaving directory `/tmp/build/sid/component/cgen-cpu'
| make[5]: *** [all] Error 2

Worse, however, the build continues after that instead of failing right
away (making the error harder to find than necessary).

With --enable-shared passed to toplevel configure, I get past this.

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.  However, testing $enable_shared for
"no" is not sufficient to fix the case where the user didn't pass either
of --enable-shared or --disable-shared.  So what would be the right
thing to happen in that case?


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?


4) sid has its own config/ directory in which it stores versions of
libtool.m4, ltmain.sh and other Autoconf macro files and helper scripts
different from those used in the rest of src.  Is that desirable?  Does
sid need to be buildable outside (independently) of the src tree?
I don't mind keeping a sid/config for stuff you'd like to override, but
it would be preferable if, for those files that are overridden in the
toplevel src/ (libtool.m4 and other macro files from libtool, ltmain.sh)
and from toplevel src/config, especially override.m4 which is needed for
Autoconf bugfixes and smooth transitions.

If you agree, then I'd work on a patch removing the duplicate files from
sid/config, and adding the necessary includes for src/ and src/config/
directories.


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
| make[6]: *** [hw-visual-lcd.html] Error 10
| rm hw-visual-lcd.html

They somehow seem to be ignored by make however.

Cheers,
Ralf

             reply	other threads:[~2009-08-18  5:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-18  5:40 Ralf Wildenhues [this message]
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

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=20090818054018.GD28254@gmx.de \
    --to=ralf.wildenhues@gmx.de \
    --cc=binutils@sourceware.org \
    --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).