Opened 6 years ago

Closed 6 years ago

Last modified 20 months ago

#6697 closed defect

BUILD: make test doesn't work OOTB

Reported by: SF/ownerless Owned by: lordhoto
Priority: normal Component: Port: Linux
Keywords: Cc:


On Debian "testing" ScummVM-1.7.0 FTBFS in "make test":

~~~~ ./test/cxxtest/ --runner=StdioPrinter --no-std --no-eh --include=./test/cxxtest_mingw.h -o test/runner.cpp test/common/hashmap.h test/common/fixedstack.h test/common/stream.h test/common/memoryreadstream.h test/common/seekablesubreadstream.h test/common/str.h test/common/memorywritestream.h test/common/array.h test/common/list.h test/common/subreadstream.h test/common/rational.h test/common/math.h test/common/pack.h test/common/queue.h test/common/memoryreadstreamendian.h test/common/util.h test/common/algorithm.h test/common/huffman.h test/common/hash-str.h test/common/bitstream.h test/common/bufferedreadstream.h test/common/ptr.h test/common/bufferedseekablereadstream.h test/common/tokenizer.h test/common/endian.h test/common/func.h test/common/rendermode.h test/common/stack.h test/common/md5.h test/common/serializer.h test/common/rect.h test/audio/helper.h test/audio/audiostream.h test/audio/raw.h test/audio/timestamp.h
common/libcommon.a(system.o): In function instance': /tmp/buildd/scummvm-1.7.0+dfsg/./common/singleton.h:70: undefined reference toCommon::Singleton::_singleton' common/libcommon.a(system.o): In function makeInstance': /tmp/buildd/scummvm-1.7.0+dfsg/./common/singleton.h:52: undefined reference toGUI::EventRecorder::EventRecorder()' common/libcommon.a(system.o): In function instance': /tmp/buildd/scummvm-1.7.0+dfsg/./common/singleton.h:71: undefined reference toCommon::Singleton::_singleton' common/libcommon.a(system.o): In function getSavefileManager': /tmp/buildd/scummvm-1.7.0+dfsg/common/system.cpp:165: undefined reference toGUI::EventRecorder::getSaveManager(Common::SaveFileManager)' /tmp/buildd/scummvm-1.7.0+dfsg/common/system.cpp:165: undefined reference to `GUI::EventRecorder::getSaveManager(Common::SaveFileManager)' collect2: error: ld returned 1 exit status test/ recipe for target 'test/runner' failed make[2] *** [test/runner] Error 1 ~~~~

This appears to be a regression from 1.6.0.

Ticket imported from: bugs/6697.

Change History (6)

comment:1 by lordhoto, 6 years ago

Owner: set to lordhoto
Status: newclosed
Summary: FTBFS in `"make test`"BUILD: make test doesn't work OOTB

comment:2 by lordhoto, 6 years ago

Yes, "make test" doesn't work when you don't pass "--disable-eventrecorder" to configure. It's known and you should really just not use "make test" when building right now. You can also pass "--disable-eventrecorder" to configure since that one is still WIP anyway. Your choice really. Closing as later.

comment:3 by SF/ownerless, 6 years ago

Thanks for your comments. But perhaps "--disable-eventrecorder" should be default if it is work-in-progress? Besides "it's known" (to whom?) also doesn't feel right as there is no README note about it etc.

With "--disable-eventrecorder" there is a following test failure:

~~~~ In RenderModeTestSuite::test_get_render_mode_code_back_and_forth: ./test/common/rendermode.h:52: Error: Expected (Common::getRenderModeCode(Common::parseRenderMode("FMTOWNS")) != "fmtowns"), found (fmtowns) ....................................................... Failed 1 of 213 tests Success rate: 99% test/ recipe for target 'test' failed ~~~~

comment:4 by lordhoto, 6 years ago

We only really consider "make test" for developers, we don't expect anyone else to really use it. Thus, we didn't write about this issue anywhere. But, if I can find a nice spot where to put it, I'll add it (probably somewhere on our wiki, but it seems it completely misses out on the unit tests right now...).

Disabling the WIP event recorder would probably cause too much internal discussion, thus I would really like to avoid that.

That's an interesting failure case. It seems it's related to the fact that gcc always uses string pooling with -O2 (maybe others too) but doesn't do it without that. It seems the unit test is simply crazy and wants to make sure it's not the same pointer.... I will look into fixing that. It should however be no issue in reality. Thanks for reporting.

comment:5 by SF/ownerless, 6 years ago

"make test" is useful not only to developers but also to package maintainers (like myself) who run tests automatically in the end of the build process in order to check generated binaries. In Debian it is especially important because we build for many architectures of which only few may be available to maintainer to actually run application.

Thanks again for your quick response and for taking out problematic test.

comment:6 by digitall, 20 months ago

Component: Port: Linux
Note: See TracTickets for help on using tickets.