sid build issues

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

sid build issues

Ralf Wildenhues
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 | Threaded
Open this post in threaded view
|

Re: sid build issues

Ralf Wildenhues
More sid build issues (thanks Matthias for the 'make -jN' hint!)


6) sid/component/cgen-cpu/mep/Makefile.in comes from Automake 1.9.5;
regenerating it with 1.9.6 leads to this error,
when building on i686-pc-linux-gnu:

| make[7]: *** No rule to make target `mep-ivc2.lo', needed by `libmep.la'.  Stop.
| make[7]: Leaving directory `/tmp/b-386/sid/component/cgen-cpu/mep'

The last ChangeLog entry regarding this Makefile.am is

| 2009-04-30  DJ Delorie  <[hidden email]>
|
|         * Makefile.am: Regenerate.
|         * Makefile.in: Regenerate.
|         * common_model.cxx: Regenerate.
[...]
|         * ivc2-cop.cxx: New.
|         * ivc2-cpu.h: New.
|         * ivc2.h: New.

OK to apply the patch below?

Thanks,
Ralf

sid/component/cgen-cpu/mep/ChangeLog:
2009-08-18  Ralf Wildenhues  <[hidden email]>

        * Makefile.am (CPU_SOURCES): Replace mep-ivc2.cxx with
        ivc2-cop.cxx.
        * Makefile.in: Regenerate.

diff --git a/sid/component/cgen-cpu/mep/Makefile.am b/sid/component/cgen-cpu/mep/Makefile.am
index 54741c6..180901f 100644
--- a/sid/component/cgen-cpu/mep/Makefile.am
+++ b/sid/component/cgen-cpu/mep/Makefile.am
@@ -11,7 +11,7 @@ CXXFLAGS = $(TOP_CXXFLAGS) -DHAVE_CONFIG_H
 
 pkgdata_DATA = hw-cpu-mep.txt
 
-CPU_SOURCES = mep-core1-decode.cxx mep-core1-sem.cxx mep-core1-model.cxx mep-cop1-16-decode.cxx mep-cop1-16-sem.cxx mep-cop1-16-model.cxx mep-cop1-32-decode.cxx mep-cop1-32-sem.cxx mep-cop1-32-model.cxx mep-cop1-48-decode.cxx mep-cop1-48-sem.cxx mep-cop1-48-model.cxx mep-cop1-64-decode.cxx mep-cop1-64-sem.cxx mep-cop1-64-model.cxx mep-ivc2.cxx
+CPU_SOURCES = mep-core1-decode.cxx mep-core1-sem.cxx mep-core1-model.cxx mep-cop1-16-decode.cxx mep-cop1-16-sem.cxx mep-cop1-16-model.cxx mep-cop1-32-decode.cxx mep-cop1-32-sem.cxx mep-cop1-32-model.cxx mep-cop1-48-decode.cxx mep-cop1-48-sem.cxx mep-cop1-48-model.cxx mep-cop1-64-decode.cxx mep-cop1-64-sem.cxx mep-cop1-64-model.cxx ivc2-cop.cxx
 
 libmep_la_SOURCES = mep.cxx common_model.cxx mep-decode.cxx mep-sem.cxx mep-model.cxx $(CPU_SOURCES)
 libmep_la_LDFLAGS =



7) On Cygwin, a native src build with
  --disable-shared --disable-binutils

fails (after fixing or working around previously mentioned errors)
inside sid/ with:

| Making all in fpu
| make[8]: Entering directory `/tmp/build/sid/component/bochs/cpu/fpu'
| if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../../../../src/sid/component/bochs/cpu/fpu -I../.. -I../../../../../../src/sid/component/bochs/cpu/fpu/../.. -I../../../../../../src/sid/component/bochs/cpu/fpu -I../../../../../../src/sid/component/bochs/cpu/fpu/stubs -DUSE_WITH_CPU_SIM -DPARANOID -DNO_ASSEMBLER    -g -O2 -MT wmFPUemu_glue.lo -MD -MP -MF ".deps/wmFPUemu_glue.Tpo" -c -o wmFPUemu_glue.lo ../../../../../../src/sid/component/bochs/cpu/fpu/wmFPUemu_glue.cc; \
| then mv -f ".deps/wmFPUemu_glue.Tpo" ".deps/wmFPUemu_glue.Plo"; else rm -f ".deps/wmFPUemu_glue.Tpo"; exit 1; fi
|  g++ -DHAVE_CONFIG_H -I. -I../../../../../../src/sid/component/bochs/cpu/fpu -I../.. -I../../../../../../src/sid/component/bochs/cpu/fpu/../.. -I../../../../../../src/sid/component/bochs/cpu/fpu -I../../../../../../src/sid/component/bochs/cpu/fpu/stubs -DUSE_WITH_CPU_SIM -DPARANOID -DNO_ASSEMBLER -g -O2 -MT wmFPUemu_glue.lo -MD -MP -MF .deps/wmFPUemu_glue.Tpo -c ../../../../../../src/sid/component/bochs/cpu/fpu/wmFPUemu_glue.cc -o wmFPUemu_glue.o
| In file included from ../../../../../../src/sid/component/bochs/cpu/fpu/fpu_emu.h:82,
|                  from ../../../../../../src/sid/component/bochs/cpu/fpu/wmFPUemu_glue.cc:32:
| ../../../../../../src/sid/component/bochs/cpu/fpu/stubs/asm/sigcontext.h:17: error: redefinition of `struct _fpstate'
| /usr/include/cygwin/signal.h:18: error: previous definition of `struct _fpstate'
| make[8]: *** [wmFPUemu_glue.lo] Error 1
| make[8]: Leaving directory `/tmp/build/sid/component/bochs/cpu/fpu'
| make[8]: Entering directory `/tmp/build/sid/component/bochs/cpu'
| make[8]: *** No rule to make target `fpu/libfpu.la', needed by `libcpu.la'.  Stop.

Here, the _fpstate in sid has a 'struct _fpreg _st[8]; unsigned long
status;' where cygwin has a 'char _st[80]; unsigned long nxst;'.

Help?

Thanks,
Ralf
Reply | Threaded
Open this post in threaded view
|

Re: sid build issues

DJ Delorie-2

> OK to apply the patch below?

Yes, please.  Thanks!

> sid/component/cgen-cpu/mep/ChangeLog:
> 2009-08-18  Ralf Wildenhues  <[hidden email]>
>
> * Makefile.am (CPU_SOURCES): Replace mep-ivc2.cxx with
> ivc2-cop.cxx.
> * Makefile.in: Regenerate.
Reply | Threaded
Open this post in threaded view
|

Re: sid build issues

Frank Ch. Eigler
In reply to this post by Ralf Wildenhues
Hi -

> 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?

I don't recall specific problems there.  I appreciate you trying to
work through them.


> 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.


> 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.


> 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?  [...]

It used to be, back when cygwin's libtool was iffy.

> 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.

That would be great.


> 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.

I'll try to beat some xml/xslt cobwebs out of my brain to figure out
which part of that pipeline is erroneous.


- FChE
Reply | Threaded
Open this post in threaded view
|

Re: sid build issues

Ralf Wildenhues
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