#281 closed defect (fixed)
Build error in AtlasUI
Reported by: | bugmenot | Owned by: | Philip Taylor |
---|---|---|---|
Priority: | Should Have | Milestone: | |
Component: | Core engine | Keywords: | |
Cc: | Patch: |
Description (last modified by )
Hello, I try to compile wildfire on ubuntu jaunty following your build instructions.
Now there is an error while compiling the AtlasUI. The output is:
==== Building AtlasUI ==== precompiled.cpp ActorEditor.cpp AnimListEditor.cpp ActorEditorListCtrl.cpp PropListEditor.cpp ActorViewer.cpp ColourTesterFileCtrl.cpp ColourTester.cpp ColourTesterColourCtrl.cpp ColourTesterImageCtrl.cpp ActionButton.cpp ToolButton.cpp Canvas.cpp ColourDialog.cpp DraggableListCtrl.cpp DraggableListCtrlCommands.cpp ListCtrlValidator.cpp QuickComboBox.cpp QuickTextCtrl.cpp EditableListCtrl.cpp FieldEditCtrl.cpp QuickFileCtrl.cpp EditableListCtrlCommands.cpp FileHistory.cpp HighResTimer.cpp SnapSplitterWindow.cpp virtualdirtreectrl.cpp AtlasWindow.cpp AtlasDialog.cpp ErrorReporter.cpp Observable.cpp AtlasClipboard.cpp AtlasEventLoop.cpp Datafile.cpp AtlasWindowCommand.cpp AtlasWindowCommandProc.cpp FFmpeg.cpp VideoRecorder.cpp DLLInterface.cpp SectionLayout.cpp ScenarioEditor.cpp Sidebar.cpp Cinematic.cpp LightControl.cpp Environment.cpp Terrain.cpp Trigger.cpp ../../../source/tools/atlas/AtlasUI/ScenarioEditor/Sections/Trigger/Trigger.cpp:1050: warning: unused parameter 'label' ScriptedTool.cpp AlterElevation.cpp PlaceObject.cpp FlattenElevation.cpp PaintTerrain.cpp TransformObject.cpp ObjectSettings.cpp MiscState.cpp Brushes.cpp Tools.cpp Linking AtlasUI obj/AtlasUI_Debug/ColourTesterColourCtrl.o: In function `CustomColourButton::OnButton(wxCommandEvent&)': ColourTesterColourCtrl.cpp:(.text._ZN18CustomColourButton8OnButtonER14wxCommandEvent[CustomColourButton::OnButton(wxCommandEvent&)]+0x92): undefined reference to `wxColour::IsOk() const' obj/AtlasUI_Debug/FieldEditCtrl.o: In function `wxColour::Ok() const': /usr/include/wx-2.8/wx/gtk/colour.h:30: undefined reference to `wxColour::IsOk() const' /usr/bin/ld: ../../../binaries/system/libAtlasUI_dbg.so: hidden symbol `wxColour::IsOk() const' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[2]: *** [../../../binaries/system/libAtlasUI_dbg.so] Error 1 make[1]: *** [AtlasUI] Error 2 make[1]: Leaving directory `/build/korn-wildfire_0svn7029-1~getdeb1-amd64-L8XWbo/wildfire-0svn7029-1~getdeb1/build/workspaces/gcc' make: *** [build-stamp] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2
Attachments (1)
Change History (10)
by , 15 years ago
comment:1 by , 15 years ago
comment:3 by , 15 years ago
Description: | modified (diff) |
---|---|
Owner: | set to |
Status: | new → assigned |
(Edited the description to use {{{ ... }}}
for the output.)
Looks like a bad interaction with the -fvisibility=hidden
option, but I'm not sure why nobody else has reported that problem...
Could you try changing source/tools/atlas/AtlasUI/ColourTester/ColourTesterColourCtrl.cpp
line 69 from
if (c.Ok())
to
if (c.IsOk())
and see if that results in different output?
comment:4 by , 15 years ago
Linking AtlasUI obj/AtlasUI_Debug/FieldEditCtrl.o: In function `wxColour::Ok() const': /usr/include/wx-2.8/wx/gtk/colour.h:30: undefined reference to `wxColour::IsOk() const' /usr/bin/ld: ../../../binaries/system/libAtlasUI_dbg.so: hidden symbol `wxColour::IsOk() const' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[2]: *** [../../../binaries/system/libAtlasUI_dbg.so] Error 1 make[1]: *** [AtlasUI] Error 2 make[1]: Leaving directory `/build/korn-wildfire_0svn7029-1~getdeb1-amd64-kYFSqH/wildfire-0svn7029-1~getdeb1/build/workspaces/gcc' make: *** [build-stamp] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 ****************************************************************************** Build finished at 20090722-1651 FAILED [dpkg-buildpackage died] ------------------------------------------------------------------------------ Not removing build depends: cloned chroot in use ****************************************************************************** Finished at 20090722-1651 Build needed 00:15:59, 1079500k disk space
It still fails. Maybe it is because of the wx version I use? (I do not use the libraries that are in the repository but the ones that come with ubuntu jaunty) http://packages.ubuntu.com/jaunty/libwxgtk2.8-dev
comment:5 by , 15 years ago
Hmm, that looks like it has one less error message than before, so maybe it's the right thing to do (or maybe it's just hiding the error deeper)... Could you also try editing source/tools/atlas/AtlasUI/CustomControls/EditableListCtrl/FieldEditCtrl.cpp
line 73 from newColour.Ok()
to newColour.IsOk()
? (Sorry, missed that one in my earlier comment.)
(I'm using the same version of wxGTK (2.8.9.1), but on Gentoo rather than Ubuntu, and I think Ubuntu has some GCC patches that may trigger visibility issues.)
comment:6 by , 15 years ago
Great. Now the AtlasUI compiles successfully.
The build fails on another point but this is my fault I think.
comment:7 by , 15 years ago
Another question not related to the bug.
Now the compilation succeeds.
But where are all the binaries and how can I install the game?
Is there support for "make DESTDIR=debian/tmp install" ?
I want to make a debian package out of the game. Can I install the data files into /usr/share/wildfire ?
I would appreciate a short installation instruction.
comment:8 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Thanks for testing this! Added those IsOk changes in r7030. Marking this as fixed (feel free to file more bugs if other stuff is broken).
Executables get put into binaries/system/
(primarily pyrogenesis_dbg
). There isn't any proper support yet for installing into system-wide locations - we assume a user just runs the build output directly from binaries/system/
, and we require write permission in various parts of the directory tree (which makes it impossible to do a secure system-wide installation). That definitely needs to be fixed, and shouldn't be too hard to implement (the code was written with this problem in mind), but we still need to work out exactly where writable files should get put, and it'd be great if someone could help with working out the best way to do this. (I've started a forum thread, which should be better than Trac for discussions.)
Oh, the newlines have been ignored.
I attach the log.