Build system doesn't work with automake1.10

[olafvdspek]

Build system doesn't work with automake1.10

[GoogleCodeExporter]

That's very likely; old autotools have lots of issues that later versions have
improved on.

We try to make the code itself work on as old (and diverse) a platform as we can
practically support, but for maintainer tools, folks will need to use something
relatively recent.

Original comment by [email protected] on 2 May 2008 at 11:19

• Changed state: WontFix

[GoogleCodeExporter]

"That's very likely; old autotools have lots of issues that later versions have
improved on."

I think that's definitely understandable, but Automake 1.10 is actually a later
version than Automake 1.9...

Original comment by [email protected] on 14 Apr 2009 at 3:32

[GoogleCodeExporter]

Hmm, I guess new autotools have some issues too. :-)  I'm re-opening the bug.

Unfortunately, I don't have easy access to automake-1.10.  Can you attach to 
this bug
report, the Makefile that automake-1.10 generates?  Also, the files 'libtool' 
and
'ltmain.sh' from your top-level directory.

Also, if you could include the full output of the 'make' command, that would be
helpful as well.

Original comment by [email protected] on 14 Apr 2009 at 7:58

• Changed state: New

[GoogleCodeExporter]

I'm seeing the same issue here with automake 1.11

I've attached libtool, ltmain.sh, Makefile, and the make log. Let me know if 
you need
anything else. It seems to be something to do with the -xc, but removing that it
won't build either (it might be trying to link without C++ name-mangling?).

Original comment by [email protected] on 1 Oct 2009 at 5:41

Attachments:

• libtool.gz
• ltmain.sh.gz
• Makefile.gz
• makelog2.gz

[GoogleCodeExporter]

Thanks for all the data.  It does look like the -xc is the problem.  When I run 
the
link line manually that automake 1.11 generates (with -xc), I get the same 
error you see:
   g++ -xc -O0 -ggdb -Wall -o statemachine_test statemachine_test.o
statemachine_test-statemachine.o

When I take out the -xc, it works correctly.

OK, it looks like the problem is in my Makefile.am script.  I add -xc 
explicitly when
compiling statemachine.c, just as an extra test there's no c++ code 
accidentally in
there.  I do this via CXXFLAGS, which I understand only applies at compile 
time. 
However, in automake 1.10 and later, it seems to apply (sometimes?) at link 
time as well.

I'll have to look into the right fix.  For now, you can take the '-cx' lines 
out of
Makefile.am, and rerun automake.  That should fix things -- let me know if it 
doesn't.

Original comment by [email protected] on 1 Oct 2009 at 4:52

• Changed state: Accepted

[GoogleCodeExporter]

Removing the -cx I get problems with linking statemachine_test (see make output
below). Since statemachine_test.c is built with gcc (which seems right, its 
extension
is .c) then the .o has statemachine_encode_char etc as non-mangled symbols. 

If statemachine's meant to be callable from C should statemachine.h be wrapped 
in
extern "C" perhaps? I'm not sure the intent of it all though.

ghost3:~/ctemplate-0.95 make
make  all-am
make[1]: Entering directory `/home/matt/ctemplate-0.95'
gcc -DHAVE_CONFIG_H -I. -I./src  -I./src   -ggdb -Wall -D_FORTIFY_SOURCE=1 
-pipe -O2
-MT statemachine_test.o -MD -MP -MF .deps/statemachine_test.Tpo -c -o
statemachine_test.o `test -f 'src/tests/statemachine_test.c' || echo
'./'`src/tests/statemachine_test.c
mv -f .deps/statemachine_test.Tpo .deps/statemachine_test.Po
/bin/sh ./libtool --tag=CXX   --mode=link g++ -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -ggdb -Wall -D_FORTIFY_SOURCE=1 -pipe 
-O2   -o
statemachine_test statemachine_test.o statemachine.o  
libtool: link: g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare 
-ggdb
-Wall -D_FORTIFY_SOURCE=1 -pipe -O2 -o statemachine_test statemachine_test.o
statemachine.o 
statemachine_test.o(.text+0x51): In function `test_encode_char':
src/tests/statemachine_test.c:342: undefined reference to 
`statemachine_encode_char'
statemachine_test.o(.text+0xdc):src/tests/statemachine_test.c:347: undefined
reference to `statemachine_encode_char'
statemachine_test.o(.text+0x1ac):src/tests/statemachine_test.c:350: undefined
reference to `statemachine_encode_char'
statemachine_test.o(.text+0x1e3):src/tests/statemachine_test.c:353: undefined
reference to `statemachine_encode_char'
statemachine_test.o(.text+0x22c):src/tests/statemachine_test.c:356: undefined
reference to `statemachine_encode_char'
statemachine_test.o(.text+0x288):src/tests/statemachine_test.c:359: more 
undefined
references to `statemachine_encode_char' follow
statemachine_test.o(.text+0x437): In function `test_copy':
src/tests/statemachine_test.c:281: undefined reference to 
`statemachine_definition_new'
statemachine_test.o(.text+0x449):src/tests/statemachine_test.c:282: undefined
reference to `statemachine_new'
statemachine_test.o(.text+0x463):src/tests/statemachine_test.c:284: undefined
reference to `statemachine_definition_populate'
statemachine_test.o(.text+0x4d0):src/tests/statemachine_test.c:289: undefined
reference to `statemachine_duplicate'
statemachine_test.o(.text+0x544):src/tests/statemachine_test.c:292: undefined
reference to `statemachine_parse'

... continues for a page

Original comment by [email protected] on 2 Oct 2009 at 1:15

[GoogleCodeExporter]

Ah, that seems likely.  The test is working already!  I wonder why we don't get 
any
bug reports like this with automake 1.10 though.  In any case, I'll look into 
this
and see if I can fix it for the next release.  Probably because automake 1.10
compiles it as a c++ file.

Original comment by [email protected] on 2 Oct 2009 at 8:16

[GoogleCodeExporter]

I looked into this a big more, and the problem isn't the lack of extern "C", the
problem is that statemachine.cc needs to be compiled as a C file, despite its
extension.  gcc is auto-detecting it as a c++ file (it's written to compile both
ways), and hence you're seeing these errors.

The right fix is to use -xc at compile time but not at link time.  Or maybe it 
would
work just to copy statemachine.cc to statemachine.c and to change the 
Makefile.am to
change:
---
statemachine_test_SOURCES = src/tests/statemachine_test.c \
                            src/htmlparser/statemachine.cc
---
to
---
statemachine_test_SOURCES = src/tests/statemachine_test.c \
                            src/htmlparser/statemachine.c
---

(And also take out the -xc.)  Do you want to try that and see if it fixes 
things for you?

Original comment by [email protected] on 2 Oct 2009 at 8:32

[GoogleCodeExporter]

I looked into it, and there's no way (that I see) to use the -xc for compiling 
but
not for linking.  So I went with my other solution, which is to copy 
statemachine.cc
to statemachine.c.  That seems to work -- it invokes gcc now, not g++, so I can 
get
rid of -xc -- so I'll put it in the next release of ctemplate.

Original comment by [email protected] on 13 Oct 2009 at 10:20

• Changed state: Started

[GoogleCodeExporter]

This should be fixed in ctemplate 0.97, just released.

Original comment by [email protected] on 20 Apr 2010 at 5:53

• Changed state: Fixed