Compile Compatibility Mode

• Oct 13, 2013 - 21:32

I find it a disturbing trend that the Open Source community is abandoning older hardware so quickly. I understand that you cannot support everything, but abandoning OSX 10.6? Really?

I cannot tell you the trouble I've gone through to try to get a nightly build to run. I run ubuntu in virtualbox to contain all my downloaded software.

Here's an example of what I've gone through to try out the upcoming guitar tab support
- Downloaded nightly mscore build for linux, which silently crashed when double clicking
- Ran the unix "files" command on the mscore executable, and found it was a 64-bit binary.
- Downloaded UbuntuStudio 64bit and installed in virtualbox
- mscore nightly still crashes under ubuntustudio 64bit
- From the command line, it reports "error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory"
- Not finding adequate information on getting the appropriate library installed, I've started following the instructions for building my own copy.

Hours and hours later, I'm still no where close to getting the nightly to run as I wait for the qt-project download...

A lot of people have been waiting on version 2.0 for guitar tab and other features for a very long time, and all these hurdles certainly won't help attract people to help test the latest version.

Please:
- compile the nightly against static libraries,
- include 32bit support binaries.

Although I'm most interested in the Linux version so I can run it contained under virtual box, please
- consider compiling for Win XP, all Ubuntu LTS versions still active, and OSX 10.4 (Intel at least)

If you want to get more people involved, the nightly build should be as easy to download and run as the production release. No installer needed, but should double click run after extracting.


Comments

Thank you for your feedback.

As you may know we are a very little team... and Apple is making it very hard for us to compile for older mac versions... I guess it's the same for other free software project. Projects need the hardware, they might need to provide several binaries depending on the OS version which is inconvenient for users. And they also need the right skills (for example the DMG format changed between 10.4 and 10.8...) Regarding MuseScore, we are standing on the shoulders of bigger projects like Qt, and Qt doesn't provide support for old version of Mac OSX.

The nighly are currently supporting Windows XP and up, Mac OS X 10.7+ Intel 64bit. The Linux status is close to a mystery to me, I never understood why there is just a binary but there are discussion to put the nightlies in a PPA (help welcome!) Advanced Linux users can build by themself easily though. Here are instructions that I try to keep up to date.

With the current setting, we are covering at least 96% of the operating system market share with very limited resources in term of hardware and people (mainly myself for both mac, windows and compilation documentation and Robert Leleu for Linux 64bit). We do welcome any further help to increase this figure!

In reply to by [DELETED] 5

I can appreciate all you have said. I guess my perspective is, with every line of code, you have a choice to adopt a new library that is supported only on new machines, or to make your project as backward compatible as possible. I never embraced the idea of using the absolute newest compilers and libraries for code development for this very reason. It limits the market to only those with the newest environments.
.
Perhaps there's too much code dependent on the new version of QT or the new Mac libraries at this point to roll back. But, going forward, I would caution any open source project from adopting new libraries when those new libraries are not as widely supported as you would like your project to be.
.
I'm thinking, why someone uses Open Source MuseScore instead of a commercial product.
1. They are in a country where new computer hardware is scarce.
2. They are a struggling student where finances are tight
3. They don't like their data tied up in closed source projects (often goes back to costs)
4. They are a dabbler or part time musician whose music does not yet support luxury tools.
5. They have or have cobbled together an older audio system because they cannot afford new.
.
All of these would seem to influence decisions to keep it working on older hardware as long as is practical.
.
Yes, Apple is a special case. Arguably your computer is only as good and safe as your web browser, and since Apple doesn't update the web browser on OSX 10.4 anymore, most people have made the jump to something newer. Still, a few people have, let's say disconnected, older Macs running the heart of their DAW perfectly well, while they use something newer for web browsing. e.g. The VirtualBox / Ubuntu solution mentioned earlier. I guess to compile on 10.4 or 10.6, you might also have to keep one of those machines around taking up space and electricity. I'd think an old 10.4 or 10.6 MacMini with VNC could do the nightly build for that platform.
.
The point was, there are ways around it if you are conscious and committed to supporting those less fortunate struggling with some older environments.
.
I hope this isn't falling on deaf ears, but rather is providing a perspective that perhaps has not been given the same consideration before.
.
I do not want to belabor the point, but

"Advanced Linux users can build by themselves easily though."

I thought I read another post that agreed that forcing users to build themselves might not be the best approach. And, yes, running "make" is easy enough, it's the getting the environment set up that's the pickle. Particularly when it depends upon compilers and libraries that are not in distribution with LTS versions of Ubuntu. I'm still trying to get QT downloaded, which is proving difficult for some reason. It all just further limits your market / user base / distribution potential.
.
One more observation. I know everyone wants their new feature, but version 1.3 has been out for a very long time. Perhaps closing releases more often would help push the features out faster, which will help increase adoption, and increasing adoption increases the volunteer base, which increases momentum.

In reply to by dougl

The way I see it is, you always have a choice between backwards compatibility and new features. If you want backwards compatibility, you can always keep using older versions of programs. However, if you want the latest and greatest new features, sometimes those features come at the price of a little backwards compatibility. It's just a question of finding the right tradeoff.

Implementing new features (or fixing existing bugs) without relying on new libraries is often more difficult than if one has the latest versions of the libraries available. There are thus a number of improvements made possible only by using recent versions of Qt. Should all MuseScore users everywhere have to give up those potential improvements for the sake of making sure the next version will work on older machines? Plus the older versions of the libraries may cease to be supported at some point, making it dangerous to rely on them into the future.

There are tough choices to be made here, but I think as long as older versions of MuseScore continue to be available - which of course they will in one form or another - then development has to look more forward than backwards. Making intelligent choices, of course - you can't break things lots of people depend on, of course - but I do think that compromising the future of MuseScore for the sake of the 4% (?) of users running machines that don't support Qt 5 would be short-sighted.

Oh, and yes, I'm sure everyone would like releases to come out quicker. 2.0 really is a special case, hopefully. Not sure how long you've been following the project, but my understanding is that ended up being a major rewrite / refactoring of a lot of code for a lot of reasons. The development actually branched before the 1.0 release several years ago, with most new development focusing on the "trunk". This work seems to have turned out to be a bigger project than originally anticipated, but once they started going down that road, I don't think there has been any way to corral the 2.0 code into a releasable product. And all work done on the "branch" - new releases in the 1.X family - is work that basically has to be duplicated for 2.0, and the duplication of effort (as well as the overhead of having those minor point releases) just pushes 2.0 out that much further. Which is to say, 2.0 *might* be out right now had there not been a 1.1, 1.2, and 1.3. Having a 1.4 - for what reason? - would surely delay 2.0 more.

In reply to by dougl

Part of your problem may be documented in this thread which tells the story of me getting a 32 bit MuseScore 2 unstable build working in Ubuntu Studio 12.04

http://musescore.org/en/node/23173

I have also overcome the final problem of the MuseScore 2 Unstable build nerfing the existing 1.3 installation which I will be posting there shortly.

HTH
Michael

PS I used the Qt online installer for Linux - you don't say whether you're trying to download the whole package. But that could be a way forward for you if not?

In reply to by ChurchOrganist

Thank you. For some reason the server at qt-project.org was busy or something. I tried both the Qt online installer and the direct download and they were both stalling at around 51MB. I finally got it downloaded through the Qt online installer.

Then came the fun of compiling. Thanks to the Compile instructions (Ubuntu 12.04) - Git and your posts at Building a 32 bit version of 2.0 on Ubuntu Studio 12.04 I was able to get it to build and run.

Note add crashed when built from command line until I checked ALSA in the MuseScore > Edit > Preferences > IO. Reported at Crash of build on New UbuntuStudio 12.04 64bit install.

Yes, I know UbuntuStudio is perhaps a little heavy for a build environment, but that's where I want to use it.

Thanks again for getting me started.

Do you still have an unanswered question? Please log in first to post your question.