Menu
▾
▴
1 Attachments
#26 Yoshimi 1.3.9 lv2 misplaced files
Building yoshimi for Rosa Linux Fresh R7 (2014.1) on x86_64.
The install phase of the build process misplaces the "/lv2/yoshimi.lv2" dir (and consequently the files in it): it ends up in "/usr/usr/lib64/", while it should go in "/usr/lib[64]".
The workaround is very simple: manually move the affected dir in the right place, but it would be better to fix the build...
See attached log file.
I thought we'd solved this multi-arch issue :(
What is strange is that fedora and magia both seem to build OK, and we made an exception for debian based ones.
Rosa is another Mandriva-derivative, so it is similar to both Fedora (old ancestor, as RedHat, of the whole Mandrake-Mandriva line) and Mageia (a sort of cousin, since as Rosa originated from the Mandriva disbanding, gathering a goodbunch of the older developers).
They have diverged a bit in the past times... but re: multi-arch they should be in the same basket (Mageia for sure...). ie 32bit -> /usr/lib or /lib, 64bit -> /usr/lib64 or /lib64.
The problem I see is that the build process seems to add a straigh $prefix in front of an otherwise correct library path... I did not look to find where this could be happening, though...
My understanding is that most LV2 hosts only check /usr/lib and /usr/local/lib for plugins so that could still be a problem. Certainly the last time I checked that was the case for Ardour4 and Muse3.
No, it is not so (at least for Ardour, for Muse I don't know).
See: http://www.manual.ardour.org/working-with-plugins/getting-plugins/ , under the header "How do I install plugins".
LV2 plugins are folders/directories. They need to installed in either /usr/lib/lv2, /usr/local/lib/lv2 or a directory mentioned in your LV2_PATH environment variable.
On my system the above env variable points to "/usr/lib64", among other things:
giovanni@Rivendell ~ $ env |grep LV2
LV2_PATH=~/.lv2:/usr/lib64/lv2:/usr/lib/lv2
so a placement in /usr/lib64 should not be a problem at all; and indeed I never found a lv2 plugin not working with this setup (and I have 135 of them in my lv2 dirs).
So the issue boils down to the "/usr/usr" wrong prefix one...
Of course that wrong directory is the problem but you've just given me a clue as to what may underlie the difficulties we've had. On my system there is no LV2_PATH environment variable! We have called for just lv2-dev to be installed expecting it to pull in anything else that was needed. Do you know if there other packages we should specifically demand? I'm working on debian testing.
Since a couple of years we have a little script for profile.d, as part of the main lv2 package (attached): it simply set the LV2_PATH variable to the desired values...
To be honest, I found a little weird that the script seems to happily set the variable to "/usr/lib64/lv2" even on i586...
Perhaps no-one is using (or testing) this arch...
Ok, I think I may have got somewhere with this. Would you be so kind as to try using the attached CMakeLists.txt files, renamed and appropriately placed. I don't want to risk breaking otherwise working systems until that has been tested on various distros.
Nope.
Build fails at configure time:
CMake Error at LV2_Plugin/CMakeLists.txt:136 (install):
install TARGETS given target "lib/lv2/yoshimi.lv2" which does not exist in
this directory.
(attached build log and CMakeOutput.log)
See the wrong path (lib/lv2/...)?
Supposing the above means really "/usr/lib/lv2/...",
I guess it should be "/usr/lib64/lv2...", since I'm on x86_64.
But the path above, as is, it would at least work on x86...
Log of failed build.
Hmmm. Looking at that, and at your lv2 attached file it seems that the main CMakeLists.txt file didn't pick up the LV2_PATH variable (line 551). I tested that here by creating it and actually just sending to /tmp
Another attempt! I don't know why it failed to pick up the LV2_PATH, but this is slightly different, and might still put it in the right place as I've altered the way the lib path is built
Yes, this one works as a charm and no workaround is needed on my Rosa system.
Thanks.
Glad that's sorted.
The folks at Exherbo are offering a patch to improve multi-arch recognition. After I've checked it out myself on debian systems I might ask you to take a look - if you don't mind.
Sure.
In the next few days I will be mostly away from PC, though:
so if you can wait, I will manage to look at it...
Fine. Whenever yuo have the time, here is a patch for the main CMakeLists.txt file that you are currently using.
Last edit: Will Godfrey 2016-03-11
Tried it... and basically works: ie the library files correctly go in /usr/lib64.
Only a couple of minor things:
1) the patch above alone re-introduces the /usr/usr/... thing for lv2 files: I guess you need also the modified CMakeLists.txt file in src/LV2_PLUGIN to have them in the right place.
2) It changes (without cause IMO) the destination dir for docs from "/usr/share/doc/yoshimi" to "/usr/share/doc/yoshimi-1.3.9": not a big deal, really (I needed to change only a couple of lines in the packaging config file to fix the packaging issue), but I cannot see how this change relates to the multi-arch handling and anyway a such change need to be more prominently advertised to packagers, to aid them to avoid to vaste time and fix their packaging files in advance...
I'm hoping this helps...
Sorry, yes it does need the patched version of the LV2 CMakeLists.txt file. I'll have a look at that issue with doc. It's wrong of course and I hadn't noticed it before.
Thanks for staying with this :)
The culprit is this one:
there is a rogue ${YOSHIMI_VERSION} at the end, here...
Good catch. That was snuck in by the exherbo guys. If they do it again I'll send them to bed without any supper :)
I've asked people on the yoshimi users list to try this whole change on different distros - it may take a while for them to get back to me. Hopefully there will be no further problems.
The latest master (with these patches) has now been tested on debian and fedora, so unless you still have a problem I'll close this soon.