Project

General

Profile

Actions

Emulator Issues #4535

closed

wxWidgets 2.9 from Externals does not build on Linux x86_32

Added by MofoMan2000 over 13 years ago.

Status:
Fixed
Priority:
High
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

What's the problem?
The dolphin-emu externals has two different versions of WXWidgets. Together these take up about 75MB of space. What's the deal with this? Even on a fast connection it takes forever to do a fresh checkout because of this. One of these needs to be deprecated.

Dolphin version with the problem (as it appears in the title bar, Ex.: "R
4779" or "R 6403M"):
Was added in r7380.


Related issues 1 (0 open1 closed)

Has duplicate Emulator - Emulator Issues #3529: Connot link with wxGTK 2.9.1 - undefined referencesDuplicatenakeee

Actions
Actions #1

Updated by Billiard26 over 13 years ago

  • Status changed from New to Accepted
  • Priority set to Low

Ya, someone should switch the windows build to the newer wxw within externals.

Actions #2

Updated by glennricster over 13 years ago

The newer wxWidgets that is in the externals is not an actual release of wxWidgets. It is the development release. wxWidgets 2.8.11 is the latest stable release. It would probably better to wait until the next stable release. Although if you want to do this on windows and eliminate the 2.8.11 version from the externals that is fine. Linux users shouldn't be using either of those in any case.

Actions #3

Updated by dtittle over 12 years ago

Resurrecting an old issue, because its priority should be moved to high. I cannot do a fresh build of dolphin-emu in Linux, due to what some call an "upstream issue." I don't know if a patch was sent upstream or not, but I know this issue has been resolved in newer versions: http://trac.wxwidgets.org/ticket/10935

The problem:

[ 5%] Building CXX object Externals/wxWidgets3/CMakeFiles/wx.dir/src/aui/auibar.cpp.o
In file included from /home/david/Desktop/dolphin-emu/Externals/wxWidgets3/include/wx/utils.h:21:0,
from /home/david/Desktop/dolphin-emu/Externals/wxWidgets3/include/wx/cursor.h:66,
from /home/david/Desktop/dolphin-emu/Externals/wxWidgets3/include/wx/event.h:22,
from /home/david/Desktop/dolphin-emu/Externals/wxWidgets3/include/wx/window.h:19,
from /home/david/Desktop/dolphin-emu/Externals/wxWidgets3/include/wx/control.h:23,
from /home/david/Desktop/dolphin-emu/Externals/wxWidgets3/include/wx/statline.h:24,
from /home/david/Desktop/dolphin-emu/Externals/wxWidgets3/src/aui/auibar.cpp:29:
/home/david/Desktop/dolphin-emu/Externals/wxWidgets3/include/wx/filefn.h:476:9: error: zero width for bit-field ‘wxAssert_477::BadFileSizeType’
make[2]: *** [Externals/wxWidgets3/CMakeFiles/wx.dir/src/aui/auibar.cpp.o] Error 1
make[1]: *** [Externals/wxWidgets3/CMakeFiles/wx.dir/all] Error 2
make: *** [all] Error 2

Another problem: I'm not sure why it's named wxWidgets3, when they are still on version two. On top of that, when I run cmake, it says:

Found wxWidgets version 2.8.11
At least 2.9.4 is required; ignoring found version
Using static wxWidgets from Externals

The latest stable release is actually 2.9.3. Why does it look for 2.9.4???

There are lots of sub-issues here, but the biggest is that we can't do a clean build with libraries provided. I'll submit my solution if I can solve this problem...

Actions #4

Updated by skidau over 12 years ago

Issue 3529 has been merged into this issue.

Actions #5

Updated by dtittle over 12 years ago

I've made changes to the master CMakeLists.txt file. This will check for wxWidgets on the system, and if it doesn't meet the requirements download the most current version of wxWidgets (as of now, 2.9.4) from github, configure and build it automatically: http://code.google.com/r/dtittle-dolphin-emu/source/list?name=updated-wxWidgets

I've tested in Linux, and have a successful build of dolphin-emu. Windows visual studio version is unaffected. Haven't been able to get wxWidgets to correctly build on mac. That will be the next objective.

This was my first contribution to the project. Feedback would be welcome. :)

Actions #6

Updated by delroth over 12 years ago

  • Priority changed from Low to High
  • Operating system N/A added

One of the goals of the externals directory is to freeze the external libraries version. Cloning the git at compilation time kind of destroys that advantage. Cloning then checkouting to a specific tag would solve that, but then I don't see why the code shouldn't be included in the Dolphin repository.

The compilation problem with wx in the current master is that we're missing some compilation flags to force 64 bits file offsets and wx does not seem to like that. I'm using an x86_64 Linux system so I can't test that - if someone has a working patch for this specific issue I would gladly apply it.

Actions #7

Updated by dtittle over 12 years ago

Yes, checking out the tag/commit for that specific version would be the ideal solution. I was just shooting for, "will it make?" I can include that in my patch.

I'll grab a VM of Ubuntu 11 x86 and see if this builds. It seems like it should, because it uses wxWidgets' own configure file to generate a unique build depending on the system. More to follow...

Actions #8

Updated by dtittle over 12 years ago

I wasn't very clear in my previous post.

The wxWidgets/Externals situation has three main issues:

  • The version of wxWidgets (2.8, 2.9, etc) might be out of date and need patches (like the problem above)
  • wxWidgets has a fairly large footprint. It would be best not to include its source in the Dolphin repository.
  • For people without wxWidgets, they will need binaries for their specific system.

If the builder has the up-to-date wxWidgets libraries installed, then there are no problems. However, if they don't, they will have to have a build specific for their system. We could include binaries for every possible build of wxWidgets, but that would make Dolphin even more bloated. We might also include the source code itself, but this leads us toward more problems like this very issue.

The best solution is to configure and build wxWidgets at Dolphin's build-time, thus reducing the size of the Dolphin repository, and successfully adding patches as they are released (upstream).

I think this would be a good approach to all external libraries, and other Dolphin dependencies.

Actions #9

Updated by dtittle over 12 years ago

I was able to get a 32bit Linux build, but it's not "out of the box" ready yet. Unfortunately, it won't be as straightforward as having cmake use git to download, configure, make and install... I'll post more when I have (what should be) a better Linux build solution.

Actions #10

Updated by dtittle over 12 years ago

I've tested fresh builds on both Ubuntu 32 and 64 bit, and it works: http://code.google.com/r/dtittle-dolphin-emu/source/browse?name=updated-wxWidgets

All I did was make some changes to the CMakeLists.txt file. The old wxWidgets3 directory is still there, for Windows builds. At least it builds on Linux and Windows now.

Can someone check a build using my commits, before we call this resolved?

Actions #11

Updated by themaskedman over 12 years ago

I pulled a fresh copy of your repo and attempted to compile under Ubuntu 11.10 and still can't compile.

src/dolphin/dtittle-dolphin-emu/Externals/wxWidgets3/include/wx/filefn.h:476:9: error: zero width for bit-field ‘wxAssert_477::BadFileSizeType’

Full configure/build log: http://pastebin.com/ATM7Lnan

Actions #12

Updated by dtittle over 12 years ago

Are you using the branch "updated-wxWidgets"?

Actions #13

Updated by themaskedman over 12 years ago

Oops. I can confirm your branch compiles under Ubuntu 11.10 amd64.
Thanks

Actions #14

Updated by delroth over 12 years ago

  • Status changed from Accepted to Fixed

Fixed a long time ago by rc83f87dfc4dc.

Actions

Also available in: Atom PDF