Camoto compilation errors

[Malvineous]

Interesting. I hadn't noticed that until I tried to compile the Windows version on the weekend. I do have a fix for it, I just haven't pushed it to the GitHub repo yet as there are some other things I want to include first.

But thanks for testing, good to know the win32 changes didn't break the Linux build

EDIT: Ok just pushed the changes, the OpenGL stuff can wait, it's going to take a while to fix (for Windows.) Let me know if this installs correctly now.

[yellowantphil]

That final install command for camoto-studio has been giving me errors for a while... I thought I had mentioned it earlier but maybe not. Anyway, it’s working now.

I'm pretty sure I’ve mentioned this before, but configure.ac in camoto-studio says it requires libXML 2.7.8, but I’ve been compiling with libXML 2.7.6 with no problems. The only changes I have to make anymore are for boost, since my version isn’t quite compatible with yours.

[Malvineous]

Surely a more up to date version of Boost is available in your distro's repos by now? I think I've upgraded four or five times since you first mentioned the issues! Luckily all those versions have been backwards compatible.

Thanks for the tip about the libxml version, I've updated configure.ac. Feel free to fork the repository on GitHub and commit your changes there, I'm happy to pull things like that back into my copy. Likewise for any .xml file updates you might make.

Just FYI I'm getting ready to push a pretty large change to libgamemusic (bordering on a rewrite), but you might want to hold off on downloading it until I've updated camoto-studio as well, otherwise camoto-studio won't compile or run.

[yellowantphil]

Well, Slackware 13.37 has been out for almost a year, but I somehow fell behind on upgrading and I'm still using Slackware 13.1. Upgrading my operating system is on my to do list, but I don't know when I'm going to get to it. I wouldn't be surprised if I'm forced to upgrade my OS just to compile Camoto at some point.

[Malvineous]

Haha quite possibly. Despite starting with Slackware I'm an Arch Linux convert, and they have a rolling release so you never have to reinstall. Although the way Linux works, all you need to do to reinstall or switch distros is back up your home directory and restore it afterwards. I've switched distros twice using that method, and it's great not having to reconfigure any software after a reinstall! All your programs just keep working as before.

FWIW Arch was particularly easy to switch to, because I could install it to a separate hard drive from within my previous distro, inside a 'chroot jail'. Then I could download programs and configure things in the new install while I was still doing work in the old install, and when I was happy with it I could just reboot from the new disk and the new install was running live, already configured and ready to go. It made it very easy to switch because there was no pressure or downtime, and if it didn't work I could easily reboot into my old distro until I fixed it.

[yellowantphil]

Just compiled the lastest version of camoto, for the first time in a couple months. Everything compiled this time, except that libgamegraphics kept complaining that I didn't have png++, although I had it in libgamegraphics/examples/png++/. Eventually, I gave up and made a link to my download of png++ in /usr/include/. I deleted and redownloaded camoto today, so maybe I had png++ in some other location earlier... I don't know.

Yesterday, I switched to Arch Linux on one of my computers. Presumably, we're running the same library versions now, so I won't be complaining about you using a newer version of boost anymore.

Arch seems pretty nice so far—didn't have any particular trouble installing. And the wiki documentation is amazing. The core and extra repositories have had all the software I've looked for so far, except for camoto and png++. I saw that you put those on AUR, but I haven't tried to do anything with AUR yet. Other than that, I was running at least a couple of my own modified versions of software, and I don't know yet the Arch way of dealing with that. I guess I need to make my own package. Also, I want to run Arch on my other computer, but I don't want to download every package update twice. Don't know what to do about that yet.

[Malvineous]

I changed libgamegraphics and camoto-studio a little while back to use the system-wide version of png++ instead of the local version, to avoid needing two copies of it when compiling. If you install png++ just like any other program, then rerun ./autogen.sh and ./configure for libgamegraphics then it should work fine (note that you need to install the SVN version of png++, which is why I have it in the AUR.)

Glad to hear you've made the switch to Arch, and that it's working out well! The AUR is pretty good, I use the "aurget" program to download and compile programs from it as the command line syntax is identical to pacman. For your own modified software it's probably easiest to make your own package, replacing the Arch-supplied one, as the other alternatives (installing into /usr/local) require a bit of search-path tweaking to get working properly. Making packages under Arch is extremely simple - it's how software is installed from the AUR. So you can just download someone's PKGBUILD file off AUR, modify it for your app, then run "makepkg -i" in that folder to get your Arch package compiled, created and installed. You can also download the original PKGBUILD file from the main Arch repository if you're happy with the official package's compile flags, and just edit that to apply your patch first.

To avoid downloading packages multiple times, just share the download folder between PCs.

[yellowantphil]

I downloaded the latest version of Camoto studio and......

My version of boost is broken. I have the latest boost you can get from pacman (1.49-02), which is known to have problems. I see 1.50 in the changelog from five days ago, but I don’t know why it isn’t listed in the package database, even under testing. And I don’t have any older versions of boost in my pacman cache. Maybe if I hadn’t cleaned my pacman cache recently, I wouldn’t have this problem. (I did set up a network shared pacman cache though. )

Such are the perils of a rolling release schedule, I suppose.

[Malvineous]

Yes I ran into the same problem. It's not actually a Boost upgrade that broke, it's a GCC upgrade. The new version of GCC is starting to enable C++11 features, which conflict with a variable name that Boost is using. I think Boost 1.50 isn't available yet as there are some packages that depend on Boost but won't work with 1.50. Once they're updated Boost will be too.

In the mean time, the fix is very simple and involves a couple of small changes to one file. See post #5 from 6xx. As a bonus this change doesn't break anything that pacman does, so it will be upgraded by pacman normally when the time comes.

Even with a rolling release, this stuff is supposed to be tested but I guess they don't recompile everything with each new GCC upgrade. Either that or there's nothing in the core repository that uses Boost Thread.

FYI I'm starting to release version 1.0 of the various Camoto libraries, followed by an alpha release of the Studio, hopefully with a Windows version too.

[yellowantphil]

I downloaded the latest Camoto Studio and libgame* from git today, and... never mind my previous errors.

[Malvineous]

patch-midi.cpp line 33 is different to what your error messages are complaining about, so it looks like somehow you don't have the latest version of the code.

Can you confirm you are actually compiling with the latest source? When you run "git pull" you shouldn't get any errors, and as of the moment I post this message, "git log" should display this as the latest commit:

Code: Select all

commit bc14106a8d765d1b4154ffb45128f66309e4ae80
Author: Adam Nielsen <malvineous@shikadi.net>
Date:   Sun Nov 16 11:42:26 2014 +1000

    cmf-creativelabs: Add more tests to confirm correct rhythm operator settings

If the commit shown has an older date than this, then you are definitely not working off the latest code.

[yellowantphil]

Hmm, yes, I really ought to be better at using git than I am. I ran "git remote update" but never "git pull." Then a couple makefiles weren't working, but "git clean -xf" followed by autogen.sh fixed it.

Now, being at least 95% sure that my code is up to date... everything compiles, but I am still getting the failed assert that I emailed you about back when I had forgotten about this forum.

Code: Select all

./src/unix/glx11.cpp(86): assert "xid" failed in SetCurrent(): window must be shown

I had hoped that some random software update of my system would have fixed it by now. I would look into what’s causing it, but I am not familiar with OpenGL, or Boost, or anything else you’re writing in, except C++.

[Malvineous]

Glad you got that fixed but unfortunately I'm still stumped about the other one. I haven't been able to reproduce the problem at my end and I haven't found any hints about what caused the problem for anyone else (as a few people have gotten the same error with other programs.)

Basically when you issue OpenGL commands you have to tell them which window they should be drawn into, and that's what SetCurrent() does. Just looking at it now, it's only used to create the shared context at the start of the code, and I'm not sure that it's even necessary to make it current as the temporary canvas is destroyed almost immediately, so it's not "current" for very long anyway.

What happens if you comment out the SetCurrent() call (studio.cpp line 193)? When I do that there is no change, the OpenGL stuff still works fine.

[yellowantphil]

What happens if you comment out the SetCurrent() call (studio.cpp line 193)?

Hmm... After commenting out that line:

Code: Select all

Unable to load OpenGL.  Make sure you have OpenGL drivers available for your video card.

[glewInit() failed: Missing GL version]

It looks like my video driver is i915 (for Intel), if that makes any difference. I have been meaning to get a video card, so I guess I could buy one and then see if Camoto runs with the new card...

[Malvineous]

Ok my mistake, upon further inspection you apparently need a (working) call to SetCurrent() before glewInit() will return success.

A different video card shouldn't make a difference, as everything is supposed to fall back to software rendering if hardware support isn't available. I'm using the Mesa drivers with Intel HD graphics, so I think we are both running the same driver.

I still have no idea why it's not working! What happens if you modify glAttribList in studio.cpp:53? WX_GL_DEPTH_SIZE is the only one I have added (the others are defaults) but perhaps removing one of these flags will work, if there's some reason why they can't be used.

I've just made another commit which removes all the errors about deprecated functions - I don't suppose this makes any difference either?