Stable: 2.5.2
Development: 2.6-alpha3
Still have a problem building from SVN.
It was described previously here:
http://moc.daper.net/node/352
I also try to build with --without-sidplay2 but got the same error.
hiben, is it possible to fix it?
+ test -f Makefile
+ autopoint -f
+ aclocal -I m4
/usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG
/usr/share/aclocal/smpeg.m4:13: run info '(automake)Extending aclocal'
/usr/share/aclocal/smpeg.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
+ autoheader
+ automake -W all -a
/usr/share/automake-1.10/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL
/usr/share/automake-1.10/am/depend2.am: The usual way to define `am__fastdepCXX' is to add `AC_PROG_CXX'
/usr/share/automake-1.10/am/depend2.am: to `configure.in' and run `aclocal' and `autoconf' again.
decoder_plugins/sidplay2/Makefile.am: C++ source seen but `CXX' is undefined
decoder_plugins/sidplay2/Makefile.am: The usual way to define `CXX' is to add `AC_PROG_CXX'
decoder_plugins/sidplay2/Makefile.am: to `configure.in' and run `autoconf' again.
+ '[' 1 '!=' 0 ']'
+ cat
If you see errors it maight be necassary to install additional packages like
autoconf >= 2.60
automake >= 1.9
libltdl (libltdl3-dev debian package)
and all -devel packages mentioned in the README file
hiben
Sat, 2008-07-05 09:52
Permalink
I still can't reproduce this
I still can't reproduce this error...
This is my setup (in a virtual environment):
Arch Linux (Archlinux-i686-2007.08-2), Kernel 2.6.22-ARCH, autoconf 2.61, autoheader 2.61, automake 1.10, autopoint 0.17
I'll try to match your system if you can give me more information...
If you do not need the sidplay decoder you could try the following:
Take a fresh checkout of moc (or clean generated files)
In the file configure.in delete line 589 (decoder_plugins/sidplay2/Makefile)
Run autogen.sh
This should just rip out the sidplay2 decoder of the whole process.
Alternativly you could try this:
Again fresh checkout.
In configure.in below line 10 (AC_PROG_CC) add the line:
AC_PROG_CXX
Maybe this does the trick. It does not change anything for me here...
I would really like to fix this problem but I just don't see where it comes from... :-|
StormBlast
Sat, 2008-07-05 16:24
Permalink
Thahks for a fast reply.
Thahks for a fast reply. After removing sidplay from building I've got the same old error:Adding AC_PROG_CXX does nothing...
kernel 2.6.25.10
autoconf, autoheader 2.62
automake 1.10.1
autopoint 0.17
hiben
Sun, 2008-07-06 15:58
Permalink
Just another wild guess: I
Just another wild guess:
I had some trouble once with my local libtool disagreeing with some files from moc.
To solve it, I had to run the following command in mocs directory:
libtoolize --copy --force
And then the autogen.sh script.
I am no expert on this and sometimes I had to run 'libtoolize --copy --force' again or 'aclocal -Im4' to get everything running.
Maybe something works for you...
StormBlast
Fri, 2008-07-11 21:41
Permalink
Well, now I have this: gcc
Well, now I have this:
hiben
Sat, 2008-07-12 09:01
Permalink
Hmm... again not sure on this
Hmm... again not sure on this but:
Try copying the 'ltdl.c' and 'ltdl.h' files from your system into mocs source. On my system (Gentoo) they can be found in '/usr/share/libtool/libltdl/'.
For me, the ltdl files from mocs repository are working but maybe there is some incompatibility...
Fazi
Tue, 2008-07-15 16:43
Permalink
Got same problem, solved that
Got same problem, solved that way:
- clean checkout from svn
- using own patch, very similar to first posted one: http://pastebin.ca/1071372
- delete ltdl.c and ltdl.h from MOC sources (to force including system ones)
- run ./autogen.sh
- do NOT run libtoolize
- configure as usual and AFTER that copy system libtool (eg. /usr/bin/libtool) to MOC source directory, replacing those created by configure script
- make
It should do the trick with build, but I spotted a deadlock somewhere 3-4 seconds after starting MOC (maybe just something in my system), still tracing that.
updated: emmm, looks like deadlock when loading modules, probably caused by the new libtool (binary incompatible with prev. versions afaik).
You posted versions of various autobuild utilities, but what are your versions of libtool?
[fazi@F-NTB ~]$ libtool --help
[cutted]
host-triplet: i686-pld-linux-gnu
shell: /bin/sh
compiler: i686-pld-linux-gcc
compiler flags: -O2 -fno-strict-aliasing -fwrapv -march=i686 -mtune=pentium4 -gdwarf-2 -g2
linker: /usr/bin/ld (gnu? yes)
libtool: (GNU libtool) 2.2.4
automake: automake (GNU automake) 1.10.1
autoconf: autoconf (GNU Autoconf) 2.62
[fazi@F-NTB ~]$ gcc --version
gcc (PLD-Linux) 4.3.1 20080623 (release)
I think the build problem is with newest version of libtool.
StormBlast
Tue, 2008-07-15 19:25
Permalink
Thanks too much and all the
Thanks too much and all the blessings to you :)
Now everything is ok. Yes I think it is new libtool problem.
sryche
Sat, 2008-07-12 21:22
Permalink
diff -up ./Makefile.am.orig
diff -up ./Makefile.am.orig ./Makefile.am
--- ./Makefile.am.orig 2008-07-12 02:29:45.000000000 -0300
+++ ./Makefile.am 2008-07-12 02:38:16.474980460 -0300
@@ -41,8 +41,6 @@ mocp_SOURCES = log.c \
themes.h \
keys.c \
keys.h \
- ltdl.c \
- ltdl.h \
io.c \
io.h \
compat.c \
@@ -72,7 +70,7 @@ EXTRA_mocp_SOURCES = gnugetopt.h \
jack.h \
gettext.h
man_MANS = mocp.1
-mocp_LDADD = @EXTRA_OBJS@ @LIBINTL@
+mocp_LDADD = @EXTRA_OBJS@ @LIBINTL@ -lltdl
mocp_DEPENDENCIES = @EXTRA_OBJS@
mocp_LDFLAGS = @EXTRA_LIBS@ $(RCC_LIBS)
EXTRA_DIST = config.example mocp.1 THANKS keymap.example Doxyfile \
diff -up ./configure.in.orig ./configure.in
--- ./configure.in.orig 2008-07-12 02:29:45.000000000 -0300
+++ ./configure.in 2008-07-12 02:32:23.870980351 -0300
@@ -8,6 +8,7 @@ AC_PREREQ(2.59)
AC_CANONICAL_HOST
AC_PROG_CC
+AC_PROG_CXX
AC_PROG_INSTALL
AC_PROG_AWK
Try this Patch, and before autogen.sh, use "libtoolize -f"
There's the PKGBUILD for it, just for reference:
http://aur.archlinux.org/packages.php?ID=12793
hiben
Wed, 2008-07-16 08:09
Permalink
I just tested the
I just tested the 'libtool-theory' on my machine:
Updating from 1.5.26 to 2.2.4 results in the same error.
The patch also works for me.
I would vote for applying this patch and to the repository. Are there any side-effects to concern ?