Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues

[andioak]

I got an issue that seems to persist since a few years ago. This is not the compiling process of HISE itself, but the end result of a project, the standalone application on Linux and the export & build process of the instrument.

First off, here´s my setup:

• Linux Mint 17.3, including all installs of all dependencies from @d-healey very nice and detailed video, Building HISE on GNU Linux 2019
• HISE 2.1, downloaded the zip form github.

The issue consists of 2 things it seems.

---

1. When exporting from HISE the .jucer project “AutogeneratedProject.jucer”, that is exported along with the shell-script file “batchCompileLinux.sh”, does not contain the same IPP flags and paths from the original build of hise, which I thought for sure it must, since you cannot use the export without it. If your HISE standalone app uses IPP the end result will not compile without IPP. So why is that .jucer file not fitted with the same settings? It doesn't make sense to me. (perhaps not possible? )

2. Since the .jucer file in the export does not include the IPP flags I had to open the .jucer file in JUCE and modify it, adding the correct flags for IPP on my system. So far so good.

• 2.1 I delete the previous export by clicking on “Clean build directory” and then clicking on “Export as Standalone Application” regenerating all files.
• 2.2 I open the .jucer file and modify the flags, saving the .jucer file again.
• • upon saving the .jucer file it generates the same files later generated by the shell script “batchCompileLinux.sh”. Having had issues with the build during the execution of the .sh batch file I therefore delete the folders “Builds” and “JuceLibraryCode” (folders created upon saving .jucer file) while leaving the folders “Source” and “temp” untouched, since they were exported by HISE export procedure.

So the .sh batch script (“batchCompileLinux.sh”) runs through everything fine until this occurs:

I seem to have 2 errors:

1: ‘XShmGetEventBase’

/usr/bin/ld: build/intermediate/Release/include_juce_gui_basics_e3f79785.o: undefined reference to symbol ‘XShmGetEventBase’

This has been seen before and I just thought it was fixed since then, but the issue persists.

I have made the changes suggested by @d-healey in this post, I added -no-pie to the “Extra linker flags” section on the “Linux Makefile” page (as seen in the pic below). It still runs into this issue. What’s the fix here?

2: "DSO missing from command line"

//usr/lib/x86_64-linux-gnu/libXext.so.6: error adding symbols: DSO missing from command line

• a bit worried about this. It seems like //usr/lib/x86_64-linux-gnu/libXext.so.6 does not have the same path as the other line, the /usr/bin/ld (which is the only file-path I´ve seen in any of the other issues with builds for linux-stuff here on HISE forums)...
  Anyone got an idéa about this?

---

Here is the flags I entered into the .jucer project exported by HISE, before running the .sh file:

Linux Makefile settings in the exported .jucer project.

---

Release page of the Linux Makefile settings.

If you see any errors here, please comment.

(I´m a newbie to Linux and to HISE)

[d.healey]

Try using a newer version of HISE.

[andioak]

@d-healey What am I looking at?? /tree/scriptnode/ ?? You´ll have to excuse my ignorance, I´m new to github.

[d.healey]

This is the scriptnode branch. Click code >> download as zip.

You might also find this video helpful
https://youtu.be/Bs3zI5Dtvn0

[andioak]

@d-healey The git video is very informative, will watch that in full detail asap, but regarding your other video, the Building HISE on GNU Linux 2019, it does not go into branches at all, just the bleeding edge or stable releases. That might be a good add-on video for that, as most things discussed here are going to be on a certain branch, right?

I´d love to see a link to a video about that at the correct second (link in description and as a hover link at around minute/sec 1:25 where you discuss downloading the Hise files)

It really is too bad Youtube does not allow splicing in a few seconds of new video content after the publishing of a video. :) Or video revisions. Imagine "Building hise... v1.01". Then Youtube comments [comment made to video revision 1.00]. Useful.

[d.healey]

@andioak Yeah I'll probably do an update video at some point. HISE development moves so fast it's hard to keep up with the most up to date (working) branch unless you're following the forums daily, so my video was intended as a sure fire way to get up and running with a working version of HISE.

[andioak]

@d-healey said in Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues:

@andioak ...my video was intended as a sure fire way to get up and running with a working version of HISE.

I would have to agree with it moving fast. I would though strongly disagree that I might want to or should move to a newer version of hise, since unless I change branch would not be possible, which was not stated in the video or anywhere on the download page or any documentation.

The master branch does not work to export one´s own projects from, if there is no solution to this without moving to another branch, right? That´s a problem. Unless the "scriptnode" branch or any of the others is the only one people are using, which is not at all apparent from just getting into this project, unless you are a well versed githubber.

And moreover it´s irrelevant. If the master branch is not working, where is the disclaimer?

As of 10 minutes ago I knew nothing about branches and thus had no way (for all I know) of getting this project to work at all. Anyone just getting into this project from a KSP environment or other lighter dev stuff will also be surprised, as I am.

[d.healey]

@andioak Yep there's a big learning curve when moving from KSP to compiling full programs, and both git and github have learning curves of their own. Always assume that any code on github is unstable and may possibly not work, unless it is tagged as a release (or some other tag to indicate it is stable).

[andioak]

@d-healey said in Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues:

@andioak Yep there's a big learning curve when moving from KSP to compiling full programs, and both git and github have learning curves of their own. Always assume that any code on github is unstable and may possibly not work, unless it is tagged as a release (or some other tag to indicate it is stable).

I understand that it´s complicated. But I only used the master branch and files you yourself use in your videos where it supposedly can be used to produce a project, any project.

In the video you state that you "I´ll prefer to just work on the master branch on small projects", but this would not be possible here. If there´s no fix for this while using the master branch.

The master branch was updated lastly 15 months ago, according to https://github.com/christophhart/HISE/branches page. Then the "Active Branches" are "scriptnode", "full_exp" and "scriptnode_codegen_rewrite".

Is the master branch not active? Can I not use it as a current version that is functioning? Or are we waiting for a master branch merge with some of the chances made in the other branches? (where some of these types of issues have been fixed)

*I know how fresh-of-the-boat I am, but this surely has a fix that will work using the master branch.

[d.healey]

I don't know if the master branch will build but even if it does it's very out of date. Most of us are using the scriptnode branch.

[andioak]

@d-healey said in Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues:

I don't know if the master branch will build but even if it does it's very out of date. Most of us are using the scriptnode branch.

You don´t know if it will build? You used it in the video. Or you don´t know if it will build with a newer version of Linux? Anyway, for me it built fine with the stuff shown in that video. But the video is about a dev situation for backwards compatibility, my favorite perspective by the way And as I state above that is what I used to create my Linux OS.

I guess compared to the other branches the master could be less up-to-date on matters pertaining to the features made in those new branches, but I would never figure that it is out of function, cause it functioned at the time of the last commit. Also it is still waiting to be merged with the issue-fixes that could be merged with it, right? Isn´t that the point of branches? To be used as dev points and later integrated/merged into the master?

But how did you manage to use this? You used the identical OS with the identical libs and dependencies, did you never use this? Surely there is a simple fix for my issues above using only the master branch.

[d.healey]

@andioak

You don´t know if it will build?

I think I said in the video that if you want stable code to go to the releases.

Anyway, for me it built fine with the stuff shown in that video.

In the video I use the release version, not the master branch. But they are pretty close in date so probably not much difference between them.

but I would never figure that it is out of function, cause it functioned at the time of the last commit.

It should function just fine, but usually I can offer better advice to help you solve problems if you are using the same version as me (and probably anyone else who responds to this thread). However I think the solution to your problem might be as simple as going into the directory containing the makefile and running make clean and then trying to compile again.

Isn´t that the point of branches? To be used as dev points and later integrated/merged into the master?

Yes, when the next stable version of HISE is ready all necessary dev branches will be merged into the master branch.

More recent version of HISE in the scriptnode branch should contain various changes I've made to make it simpler to compile on GNU/Linux and this may also be a solution to your issue.

[andioak]

@d-healey

I think I said in the video that if you want stable code to go to the releases.

I downloaded the zip from your video, so that is the release, then. I knew nothing about the "master" branch or any other at the time. So my version is the release 2.1.

... I think the solution to your problem might be as simple as going into the directory containing the makefile and running make clean and then trying to compile again.

As I state in my explanation I "delete the previous export by clicking on “Clean build directory” and then clicking on “Export as Standalone Application” regenerating all files". That deletes and clean the entire "Binaries" directory. No need for make clean after that. Also in my initial message I say:

@andioak:

upon saving the .jucer file it generates the same files later generated by the shell script “batchCompileLinux.sh”. Having had issues with the build during the execution of the .sh batch file I therefore delete the folders “Builds” and “JuceLibraryCode” (folders created upon saving .jucer file) while leaving the folders “Source” and “temp” untouched, since they were exported by HISE export procedure.

Meaning I completely delete the two folders that are generated when saving the .jucer file after adding IPP flags and the -no-pie, as you mention in your earlier posts when you dealt with this issue specifically. So they are not present in the "Binaries" folder when running the sh batchCompileLinux.sh again.

More recent version of HISE in the scriptnode branch should contain various changes I've made to make it simpler to compile on GNU/Linux and this may also be a solution to your issue.

So are you using Linux Mint 17.3 still or did you give up and upgrade to a newer system? Or does your updates to the scriptnode branch have fixes for building and exporting on Linux Mint 17 or Ubuntu 14? (or older Linux´s)

I ask because I want to keep it as old as possible, to not have to ask future customers to upgrade their OS:es. Feels unprofessional. Also additionally, linux distros are not like macOS where an OS upgrade is super easy, seems more like the opposite.

[d.healey]

@andioak I'm on 19.3 for my main system but I build on 17.3 for the same reasons you do. Upgrading Linux Mint is pretty straightforward if you use the upgrade manager (I'm not sure what version of Mint that was introduced in though). Try the scriptnode branch, I'm doubtful also whether it will solve the problem, but at least we'll both be using the same version so it will rule out that possibility.

[andioak]

@d-healey

Try the scriptnode branch

I have downloaded the latest zip from /tree/scriptnode/ as you suggested, but I have errors with compiling on mac. Errors that seem to change using different settings in the .jucer file, as seen here:

Building HISE on macOS (10.13) errors and questions about using /auto_build/ files in hise source folder

I just tried to compile the latest commit of the branch "scriptnode" (2020-08-20) on my macOS system. 21 errors and about 59 warnings. The errors stop the bu...

Forum (forum.hise.audio)

My question here is if there are any requirements for changing the settings in the "HISE standalone.jucer" project included in the /Projects/ folder? Is there a magic formula one needs to choose for that to work from the Projucer?

I ask because the settings on some things in that .jucer file have changed since the video, based off the Release 2.1.

[d.healey]

I haven't built on Mac for a few months so I'm not sure if anything has changed with regards to building on that platform, hopefully some of the Mac users around here can chip in and answer those questions.

[andioak]

@d-healey said in Linux exporting instruments errors - .jucer file not containing IPP + re-saved jucer build issues:

... hopefully some of the Mac users around here can chip in and answer those questions.

Indeed, hopefully. But on the other forum post.