Topic: Pianoteq 6.4 not starting in Linux.

Hi,

I'm a new and happy user of Pianoteq on Linux (standalone version, for piano practice).
The problem is, while version 6.3 runs perfectly fine, 6.4 doesn't start at all.


Here's what's returned in the terminal when launching the "Pianoteq 6 STAGE" file from the "amd64" folder of the 7zip file :

[user1@localhost amd64]$ ./"Pianoteq 6 STAGE"
*** Error in `./Pianoteq 6 STAGE': free(): invalid pointer: 0x00007f4be3301f00 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7238e)[0x7f4be427d38e]
/lib64/libc.so.6(+0x7a0c8)[0x7f4be42850c8]
/lib64/libc.so.6(cfree+0x48)[0x7f4be4288798]
/lib64/libstdc++.so.6(_ZNSt6locale5_Impl16_M_install_facetEPKNS_2idEPKNS_5facetE+0x142)[0x7f4be3067722]
/lib64/libstdc++.so.6(_ZNSt6locale5_ImplC1Em+0x1e3)[0x7f4be3067b83]
/lib64/libstdc++.so.6(+0x71af5)[0x7f4be3068af5]
/lib64/libpthread.so.0(pthread_once+0x50)[0x7f4be45ccae0]
/lib64/libstdc++.so.6(+0x71b41)[0x7f4be3068b41]
/lib64/libstdc++.so.6(_ZNSt6localeC2Ev+0x13)[0x7f4be3068b83]
/lib64/libstdc++.so.6(_ZNSt8ios_base4InitC2Ev+0xb4)[0x7f4be3065a24]
/lib64/libjack.so.0(+0x10ee2)[0x7f4be3313ee2]
/lib64/libjack.so.0(+0x10f14)[0x7f4be3313f14]
/lib64/ld-linux-x86-64.so.2(+0xf5fa)[0x7f4be5bf55fa]
/lib64/ld-linux-x86-64.so.2(+0xf70b)[0x7f4be5bf570b]
/lib64/ld-linux-x86-64.so.2(+0x13761)[0x7f4be5bf9761]
/lib64/ld-linux-x86-64.so.2(+0xf4a4)[0x7f4be5bf54a4]
/lib64/ld-linux-x86-64.so.2(+0x12ef3)[0x7f4be5bf8ef3]
/lib64/libdl.so.2(+0x1039)[0x7f4be57db039]
/lib64/ld-linux-x86-64.so.2(+0xf4a4)[0x7f4be5bf54a4]
/lib64/libdl.so.2(+0x169d)[0x7f4be57db69d]
/lib64/libdl.so.2(dlopen+0x31)[0x7f4be57db0d1]
./Pianoteq 6 STAGE(+0xcb6f2)[0x55876b4f06f2]
./Pianoteq 6 STAGE(+0x73b7ad)[0x55876bb607ad]
/lib64/libc.so.6(__libc_start_main+0x7f)[0x7f4be422afdf]
./Pianoteq 6 STAGE(+0xd1239)[0x55876b4f6239]
======= Memory map: ========
55876b425000-55876e152000 r-xp 00000000 08:02 3597                       /media/win_d/pianoteq/Pianoteq 6 STAGE/amd64/Pianoteq 6 STAGE
55876e351000-55876e3aa000 r--p 02d2c000 08:02 3597                       /media/win_d/pianoteq/Pianoteq 6 STAGE/amd64/Pianoteq 6 STAGE
55876e3aa000-55876e3c8000 rw-p 02d85000 08:02 3597                       /media/win_d/pianoteq/Pianoteq 6 STAGE/amd64/Pianoteq 6 STAGE
55876e3c8000-55876e3de000 rw-p 00000000 00:00 0 
55876e923000-55876e944000 rw-p 00000000 00:00 0                          [heap]
7f4be2ff7000-7f4be30e4000 r-xp 00000000 08:08 142474                     /usr/lib64/libstdc++.so.6.0.20
7f4be30e4000-7f4be32e4000 ---p 000ed000 08:08 142474                     /usr/lib64/libstdc++.so.6.0.20
7f4be32e4000-7f4be32ec000 r--p 000ed000 08:08 142474                     /usr/lib64/libstdc++.so.6.0.20
7f4be32ec000-7f4be32ee000 rw-p 000f5000 08:08 142474                     /usr/lib64/libstdc++.so.6.0.20
7f4be32ee000-7f4be3303000 rw-p 00000000 00:00 0 
7f4be3303000-7f4be3358000 r-xp 00000000 08:08 141135                     /usr/lib64/libjack.so.0.1.0
7f4be3358000-7f4be3557000 ---p 00055000 08:08 141135                     /usr/lib64/libjack.so.0.1.0
7f4be3557000-7f4be355a000 r--p 00054000 08:08 141135                     /usr/lib64/libjack.so.0.1.0
7f4be355a000-7f4be355b000 rw-p 00057000 08:08 141135                     /usr/lib64/libjack.so.0.1.0
7f4be355b000-7f4be355c000 rw-p 00000000 00:00 0 
7f4be355c000-7f4be3561000 r-xp 00000000 08:08 140279                     /usr/lib64/libXdmcp.so.6.0.0
7f4be3561000-7f4be3760000 ---p 00005000 08:08 140279                     /usr/lib64/libXdmcp.so.6.0.0
7f4be3760000-7f4be3761000 r--p 00004000 08:08 140279                     /usr/lib64/libXdmcp.so.6.0.0
7f4be3761000-7f4be3762000 rw-p 00005000 08:08 140279                     /usr/lib64/libXdmcp.so.6.0.0
7f4be3762000-7f4be3764000 r-xp 00000000 08:08 140269                     /usr/lib64/libXau.so.6.0.0
7f4be3764000-7f4be3964000 ---p 00002000 08:08 140269                     /usr/lib64/libXau.so.6.0.0
7f4be3964000-7f4be3965000 r--p 00002000 08:08 140269                     /usr/lib64/libXau.so.6.0.0
7f4be3965000-7f4be3966000 rw-p 00003000 08:08 140269                     /usr/lib64/libXau.so.6.0.0
7f4be3966000-7f4be39bf000 r-xp 00000000 08:08 135631                     /usr/lib64/libpng16.so.16.27.0
7f4be39bf000-7f4be3bbe000 ---p 00059000 08:08 135631                     /usr/lib64/libpng16.so.16.27.0
7f4be3bbe000-7f4be3bbf000 r--p 00058000 08:08 135631                     /usr/lib64/libpng16.so.16.27.0
7f4be3bbf000-7f4be3bc0000 rw-p 00059000 08:08 135631                     /usr/lib64/libpng16.so.16.27.0
7f4be3bc0000-7f4be3bcf000 r-xp 00000000 08:08 140476                     /usr/lib64/libbz2.so.1.0.6
7f4be3bcf000-7f4be3dce000 ---p 0000f000 08:08 140476                     /usr/lib64/libbz2.so.1.0.6
7f4be3dce000-7f4be3dcf000 r--p 0000e000 08:08 140476                     /usr/lib64/libbz2.so.1.0.6
7f4be3dcf000-7f4be3dd0000 rw-p 0000f000 08:08 140476                     /usr/lib64/libbz2.so.1.0.6
7f4be3dd0000-7f4be3de9000 r-xp 00000000 08:08 134419                     /usr/lib64/libz.so.1.2.8
7f4be3de9000-7f4be3fe9000 ---p 00019000 08:08 134419                     /usr/lib64/libz.so.1.2.8
7f4be3fe9000-7f4be3fea000 r--p 00019000 08:08 134419                     /usr/lib64/libz.so.1.2.8
7f4be3fea000-7f4be3feb000 rw-p 0001a000 08:08 134419                     /usr/lib64/libz.so.1.2.8
7f4be3feb000-7f4be400a000 r-xp 00000000 08:08 141706                     /usr/lib64/libxcb.so.1.1.0
7f4be400a000-7f4be4209000 ---p 0001f000 08:08 141706                     /usr/lib64/libxcb.so.1.1.0
7f4be4209000-7f4be420a000 r--p 0001e000 08:08 141706                     /usr/lib64/libxcb.so.1.1.0
7f4be420a000-7f4be420b000 rw-p 0001f000 08:08 141706                     /usr/lib64/libxcb.so.1.1.0
7f4be420b000-7f4be43b5000 r-xp 00000000 08:08 137036                     /usr/lib64/libc-2.20.so
7f4be43b5000-7f4be45b5000 ---p 001aa000 08:08 137036                     /usr/lib64/libc-2.20.so
7f4be45b5000-7f4be45b9000 r--p 001aa000 08:08 137036                     /usr/lib64/libc-2.20.so
7f4be45b9000-7f4be45bb000 rw-p 001ae000 08:08 137036                     /usr/lib64/libc-2.20.so
7f4be45bb000-7f4be45bf000 rw-p 00000000 00:00 0 
7f4be45bf000-7f4be45d6000 r-xp 00000000 08:08 148466                     /usr/lib64/libpthread-2.20.so
7f4be45d6000-7f4be47d5000 ---p 00017000 08:08 148466                     /usr/lib64/libpthread-2.20.so
7f4be47d5000-7f4be47d6000 r--p 00016000 08:08 148466                     /usr/lib64/libpthread-2.20.so
7f4be47d6000-7f4be47d7000 rw-p 00017000 08:08 148466                     /usr/lib64/libpthread-2.20.so
7f4be47d7000-7f4be47db000 rw-p 00000000 00:00 0 
7f4be47db000-7f4be47f1000 r-xp 00000000 08:08 135646                     /usr/lib64/libgcc_s-4.9.2.so.1
7f4be47f1000-7f4be49f0000 ---p 00016000 08:08 135646                     /usr/lib64/libgcc_s-4.9.2.so.1
7f4be49f0000-7f4be49f1000 r--p 00015000 08:08 135646                     /usr/lib64/libgcc_s-4.9.2.so.1
7f4be49f1000-7f4be49f2000 rw-p 00016000 08:08 135646                     /usr/lib64/libgcc_s-4.9.2.so.1
7f4be49f2000-7f4be4af7000 r-xp 00000000 08:08 155552                     /usr/lib64/libm-2.20.so
7f4be4af7000-7f4be4cf6000 ---p 00105000 08:08 155552                     /usr/lib64/libm-2.20.so
7f4be4cf6000-7f4be4cf7000 r--p 00104000 08:08 155552                     /usr/lib64/libm-2.20.so
7f4be4cf7000-7f4be4cf8000 rw-p 00105000 08:08 155552                     /usr/lib64/libm-2.20.so
7f4be4cf8000-7f4be4d09000 r-xp 00000000 08:08 140284                     /usr/lib64/libXext.so.6.4.0
7f4be4d09000-7f4be4f08000 ---p 00011000 08:08 140284                     /usr/lib64/libXext.so.6.4.0
7f4be4f08000-7f4be4f09000 r--p 00010000 08:08 140284                     /usr/lib64/libXext.so.6.4.0
7f4be4f09000-7f4be4f0a000 rw-p 00011000 08:08 140284                     /usr/lib64/libXext.so.6.4.0
7f4be4f0a000-7f4be4f9c000 r-xp 00000000 08:08 130996                     /usr/lib64/libfreetype.so.6.11.3
7f4be4f9c000-7f4be519b000 ---p 00092000 08:08 130996                     /usr/lib64/libfreetype.so.6.11.3
7f4be519b000-7f4be51a1000 r--p 00091000 08:08 130996                     /usr/lib64/libfreetype.so.6.11.3
7f4be51a1000-7f4be51a2000 rw-p 00097000 08:08 130996                     /usr/lib64/libfreetype.so.6.11.3
7f4be51a2000-7f4be5292000 r-xp 00000000 08:08 140392                     /usr/lib64/libasound.so.2.0.0
7f4be5292000-7f4be5491000 ---p 000f0000 08:08 140392                     /usr/lib64/libasound.so.2.0.0
7f4be5491000-7f4be5498000 r--p 000ef000 08:08 140392                     /usr/lib64/libasound.so.2.0.0
7f4be5498000-7f4be549a000 rw-p 000f6000 08:08 140392                     /usr/lib64/libasound.so.2.0.0
7f4be549a000-7f4be55d3000 r-xp 00000000 08:08 163372                     /usr/lib64/libX11.so.6.3.0
7f4be55d3000-7f4be57d2000 ---p 00139000 08:08 163372                     /usr/lib64/libX11.so.6.3.0
7f4be57d2000-7f4be57d4000 r--p 00138000 08:08 163372                     /usr/lib64/libX11.so.6.3.0
7f4be57d4000-7f4be57d9000 rw-p 0013a000 08:08 163372                     /usr/lib64/libX11.so.6.3.0
7f4be57d9000-7f4be57da000 rw-p 00000000 00:00 0 
7f4be57da000-7f4be57dd000 r-xp 00000000 08:08 155550                     /usr/lib64/libdl-2.20.so
7f4be57dd000-7f4be59dc000 ---p 00003000 08:08 155550                     /usr/lib64/libdl-2.20.so
7f4be59dc000-7f4be59dd000 r--p 00002000 08:08 155550                     /usr/lib64/libdl-2.20.so
7f4be59dd000-7f4be59de000 rw-p 00003000 08:08 155550                     /usr/lib64/libdl-2.20.so
7f4be59de000-7f4be59e5000 r-xp 00000000 08:08 155716                     /usr/lib64/librt-2.20.so
7f4be59e5000-7f4be5be4000 ---p 00007000 08:08 155716                     /usr/lib64/librt-2.20.so
7f4be5be4000-7f4be5be5000 r--p 00006000 08:08 155716                     /usr/lib64/librt-2.20.so
7f4be5be5000-7f4be5be6000 rw-p 00007000 08:08 155716                     /usr/lib64/librt-2.20.so
7f4be5be6000-7f4be5c06000 r-xp 00000000 08:08 135674                     /usr/lib64/ld-2.20.so
7f4be5ddb000-7f4be5de5000 rw-p 00000000 00:00 0 
7f4be5e04000-7f4be5e05000 rw-p 00000000 00:00 0 
7f4be5e05000-7f4be5e06000 r--p 0001f000 08:08 135674                     /usr/lib64/ld-2.20.so
7f4be5e06000-7f4be5e08000 rw-p 00020000 08:08 135674                     /usr/lib64/ld-2.20.so
7ffffe824000-7ffffe845000 rw-p 00000000 00:00 0                          [stack]
7ffffe9ef000-7ffffe9f1000 r--p 00000000 00:00 0                          [vvar]
7ffffe9f1000-7ffffe9f3000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Abandon

I'm not too computer-savvy so I have no idea what it signifies.

I use Mageia 5 and the output is jack (real time mode), 64 samples at 48000Hz, with the onboard sound card of a Gigabyte GA-P35-DS3R motherboard (cpu is Intel Core2Duo E8600). This is an old computer, but Pianoteq gives me around 90 notes of polyphony and no noticeable latency, so I'm really happy.


I'd be grateful if anyone could help.

Re: Pianoteq 6.4 not starting in Linux.

Hi Soel,

I'm not so english-savvy, sorry, but I guess "Mageia 5" is too old. From distrowatch.com:

• 2018-12-08: Development Release: Mageia 7 Beta 1
• 2018-10-06: Distribution Release: Mageia 6.1
• 2017-07-16: Distribution Release: Mageia 6
• 2017-05-25: Development Release: Mageia 6 RC
• 2017-03-07: Development Release: Mageia 6 Sta 2
• 2016-12-03: Distribution Release: Mageia 5.1
• 2016-07-01: Development Release: Mageia 6 Sta 1
• 2016-03-31: Development Release: Mageia 6 Dev 1
• 2015-06-20: Distribution Release: Mageia 5        <------

I'm running Pianoteq v6.4 on Debian 9 Linux, not a bleeding-edge distro, but stable and works well for me with JACK low-latency sound server on Intel (amd64) arch:

• 2017-06-18: Distribution Release: Debian 9  <------

Re: Pianoteq 6.4 not starting in Linux.

I have the same problem with Pianoteq STAGE 6.4.0, bought version for i386. There seems to be a problem with the executable file. It doesn't run on Linux Mint 19 Xfce, which is a quite recent version.

All previous Linux versions of Pianoteq are running fine, including 6.3.0. Just not this latest version.

Re: Pianoteq 6.4 not starting in Linux.

I'm having the same problem, under Ubuntu Studio 18.04 LTS.

I had a desktop shortcut to PTQ 6.2 (hadn't got around to updating to 6.3). I deleted the PTQ folder and replaced it with the one I extracted from the archive and the shortcut launched 6.4 first time around. I went off to eat and when I came back more than 20 minutes had elapsed so I had to restart PTQ if I was going to try the Bechstein demo. And that's when I found that neither the shortcut, nor double-clicking on the "Pianoteq 6" file itself, worked. The file manager keeps asking me what software it should use to open a shared library file.

With previous versions the file manager identifies the "Pianoteq 6" file as an executable, but in the 6.4 archive it's showing as a shared library.

PTQ Std: Blüthner, K2, YC5, Steinway D, Kremsegg 2, Celeste, Hohner, Electric pianos
UbuntuStudio, SL88 Grand, Keystation 88es

1903 Bechstein Model 8, Yamaha CP-30

Re: Pianoteq 6.4 not starting in Linux.

Same issue here...
Odroid xu4, Ubuntu.
Only message I get is a segmentation fault.

Real pitty, can't wait to try the new piano.

Re: Pianoteq 6.4 not starting in Linux.

I've fired up Carla and am playing with the LV2 version, just about to try the Bechstein :-)

PTQ Std: Blüthner, K2, YC5, Steinway D, Kremsegg 2, Celeste, Hohner, Electric pianos
UbuntuStudio, SL88 Grand, Keystation 88es

1903 Bechstein Model 8, Yamaha CP-30

Re: Pianoteq 6.4 not starting in Linux.

Sounds like a good idea. I'll try if I can get Carla working on arm linux.

Jorvik wrote:

I've fired up Carla and am playing with the LV2 version, just about to try the Bechstein :-)

Re: Pianoteq 6.4 not starting in Linux.

groovy wrote:

Hi Soel,
I'm not so english-savvy, sorry, but I guess "Mageia 5" is too old.

Hi, thank you for your answer and your research (being french myself, we are fellow non native english speakers).
I'm well aware of the fact that my system is not up to date and I'd rather not upgrade it for the moment (I can't easily test other linux distributions either).
But since previous versions were working fine my guess would be that it's not the problem here.

Of course I don't really know what i'm talking about but the error reported seems to indicate that the "free()" function (supposed to free memory - says google) is used with an "invalid pointer", probably meaning a wrong memory address ?

Error in `./Pianoteq 6 STAGE': free(): invalid pointer: 0x00007f4be3301f00

At least it would seem that I'm not the only one having the problem, so that's good to know !

Re: Pianoteq 6.4 not starting in Linux.

Hello Soel,

hard to say, if the Error is cause or effect. Would be interesting, if other users see the same error starting Pianoteq Stage from commandline.

Maybe I'm just not affected because of using Pianoteq v6.4.0 Standard and not Stage.

Re: Pianoteq 6.4 not starting in Linux.

Just tried both 32bit and 64bit versions -- 6.4 Pro -- on my Mint 18/Ubuntu 16.04 system.

32bit version launches without error but fails to connect to JACK.

64bit version works perfectly.

Last edited by Mossy (18-01-2019 09:51)

Re: Pianoteq 6.4 not starting in Linux.

I'm using standard too.
Version 6.3 runs without errors, version 6.4 won't even start.

groovy wrote:

Hello Soel,

hard to say, if the Error is cause or effect. Would be interesting, if other users see the same error starting Pianoteq Stage from commandline.

Maybe I'm just not affected because of using Pianoteq v6.4.0 Standard and not Stage.

Re: Pianoteq 6.4 not starting in Linux.

I'm also using Standard. I'd no problems using the LV2 plugin, but as previously mentioned, the standalone version isn't recognised as an executable on my UbuntuStudio 18.04.

How exactly does one start the standalone version from the commandline? I think I successfully tried that last night – successful only in the sense that I used the right command, but it gave the same error as double-clicking in the file manager.

PTQ Std: Blüthner, K2, YC5, Steinway D, Kremsegg 2, Celeste, Hohner, Electric pianos
UbuntuStudio, SL88 Grand, Keystation 88es

1903 Bechstein Model 8, Yamaha CP-30

Re: Pianoteq 6.4 not starting in Linux.

System Tools -> Terminal

## 64-bit version
cd /where your pianoteq is/amd64
./Pianoteq \6

## 32-bit version
cd /where your pianoteq is/i386
./Pianoteq \6

Re: Pianoteq 6.4 not starting in Linux.

Hi All,

We have just updated the version 6.4.0 for linux ( it will display 6.4.0/20190118 in options/about ). This time it should work on many distributions, as long as the glibc is not too old. The problem was that we have switched to statically linking libstdc++ (in order to improve compatibility with older distributions), but it is not trivial and requires a linker script to take care of a few weak symbols.

Re: Pianoteq 6.4 not starting in Linux.

Not quite. I just downloaded 6.4.0 again (18. Jan 14:14h version). In the file manager it still is displayed as a shared library, not as executable and just clicking on it won't start Pianoteq. From the command line it runs ok on 32 and 64 bit linux if the execute bit is set.

Last edited by goahead (18-01-2019 16:26)

Re: Pianoteq 6.4 not starting in Linux.

Oh, this is a different issue. The linux standalone is now a PIE (position independant executable), so technically it IS a shared library , but a shared library that can run. I guess it is related to this issue:

https://bugzilla.redhat.com/show_bug.cgi?id=1296858

So I guess we just have to disable PIE.. I'm still surprised that no linux distro can handle them, they are not new and they are supposed to be the future.

Re: Pianoteq 6.4 not starting in Linux.

julien wrote:

We have just updated the version 6.4.0 for linux ( it will display 6.4.0/20190118 in options/about ). This time it should work on many distributions, as long as the glibc is not too old.

Hi, and thank you very much, the new version runs perfectly !
I will test it further but the problem seems solved for me.

By the way I have glibc 2.20. I know it's old and I will upgrade my Linux distribution and my computer at some point in the future, but for now I have to keep it as is, so I'm really grateful that you were willing to fix this issue.

Re: Pianoteq 6.4 not starting in Linux.

Thank you!

I can confirm that this version runs on my odroid xu4.
You guys deliver great support.

Best regards,
Jonathan

julien wrote:

Hi All,

We have just updated the version 6.4.0 for linux ( it will display 6.4.0/20190118 in options/about ). This time it should work on many distributions, as long as the glibc is not too old. The problem was that we have switched to statically linking libstdc++ (in order to improve compatibility with older distributions), but it is not trivial and requires a linker script to take care of a few weak symbols.

Re: Pianoteq 6.4 not starting in Linux.

This comment from Chris Billington about PIE executables and some Linux file managers (in this case, the Gnome desktop environment’s Nautilus file manager) might be interesting:

https://gitlab.gnome.org/GNOME/nautilus/issues/437

There are at least several simple work-arounds in Linux which bypass or compensate for the file-browser/file-manager applications (of which there exist many to choose from in Linux) that have not yet been updated to have a sensible approach to PIE executables.

+1 for removing the ability to launch .desktop files but retaining ability to launch binaries and scripts.

It even looks like in version 5.33 of the file utility PIE executables are now identified as such, resolving
one of the original issues that prompted reconsideration of supporting binary launching from nautilus.
This means there will no longer be an impetus for FireFox to distribute non-PIE executables, so they
can be more secure in their binary distribution for linux (the inability to launch PIE executables from
linux file managers has been a problem for them).

Removing the ability to launch .desktop files resolves the CVE fairly definitively, and people seem to be
much less concerned about their removal. Not many people are actually launching apps from the desktop
it seems, they're using the DE launchers as intended, but many people seem to not necessarily want their
random dev scripts, some isolated/portable apps and meticulously sorted folders full of games integrated
with the system.

Nautilus doesn't need to change to support the PIE executables (other than rolling back this recent change)
as far as I can tell. It looks like 'file' has changed to report both shared objects and executables as executables
if they are PIE. While Nautilus may wish to inspect the 'interpreter' flag (once libmagic adds support for
exposing this, not clear if they have yet but as indicated here they will in due course) to decide whether an
ELF is intended to be executed or linked, I don't really see a problem if it doesn't and if it just executes them
all if they have the execute bit set (and the user confirms they want to execute). They're valid executables
that can be executed from the command line with ./libfoo.so, they just usually segfault is all (but some don't
and print things to stdout - not super useful without a terminal, but also harmless). Nonetheless if Nautilus
thinks shared objects are executables until libmagic exposes the relevant flags for it to check, that's
not so bad in the interim.

If the ability to launch executables remains removed entirely, distros and some savvy users will create a
launcher program and associate executable formats with it. But this may not be ideal for scripts, since
each type will need to be associated separately - the non-executable ones with your text editor and the
executable ones with both the text editor and some 'run' or 'run in terminal' launcher programs. It's also
not clear to me whether the presence of the executable bit counts as a different file format for the purpose
of setting file associations via nautilus. If it doesn't, then one would have the 'run' option with such a
custom launcher even if the executable bit is not set. The launcher program, if well designed, would give a
GUI error about the execute bit not being set. This situation is actually not so bad, though it a) defeats
the purpose of removing executable launching support if distros will just work around it in this way and
b) does not allow the current situation where you get a popup asking "open, or run?", which is something
I quite like - since you often switch between both with executables and it is easy to forget to right click
and select 'open with'. A confirmation generally is good for preventing accidentally running potentially
malicious executables too.

One final possibility might be if Nautilus allowed associating multiple programs with a mime type,
without a default, such that it asks every time which program to use. That way distros could have a
'run' and 'run in terminal' launcher program associated with executable file types as well as the
usual program. This is not ideal however, because if it's part of the user-exposed file associations,
the user could change it accidentally (setting their game to always open with 'run program' and
inadvertently making this the setting for all executables), opening themselves up to accidentally
executing things. Probably better that Nautilus continue to treat executables as special.

All things considered, given that the feature (except for .desktop files) is popular enough to be
worked around, and given that the workarounds are more likely to result in accidental execution
than if Nautilus treats executables as special, it seems like the feature to run executables from a
file browser, if it exists at all (which it is too popular not to IMHO), belongs in Nautilus. The
PIE problem is mostly resolved and will likely become fully resolved in time (distinguishing
between shared objects and PIE executables with the 'interpreter' flag), and the CVE with .desktop
files gone.

Last edited by Stephen_Doonan (19-01-2019 17:33)
--
Linux, Pianoteq Pro, Organteq

Re: Pianoteq 6.4 not starting in Linux.

It seems my issue was this one about not being able to launch by double-clicking on the file and when trying to launch from the commandline I was doing so incorrectly (thanks Mossy for putting me straight, I always forget about the ./ part). I've double-checked and the previous version worked when started correctly from the commandline, as does the latest one.

As the proud owner of a 1903 Bechstein Model 8, thank you to the Pianoteq team for doing a Bechstein grand.

And as always, many, many thanks to Modartt, not just for a truly superb instrument in Pianoteq, but for supporting Linux, it is very much appreciated.

PTQ Std: Blüthner, K2, YC5, Steinway D, Kremsegg 2, Celeste, Hohner, Electric pianos
UbuntuStudio, SL88 Grand, Keystation 88es

1903 Bechstein Model 8, Yamaha CP-30

Re: Pianoteq 6.4 not starting in Linux.

I just noticed, that v6.4.1 (2019/01/30) is out and has a fix for the linux executable. Great support, thanks!

I can confirm, that another quirk has vanished too with this version. With the former release (v6.4.0) quitting Pianoteq Standard -- after using it without problems from commandline -- reports a Segmentation Fault. Now it quits cleanly.

Hopefully I can test the new Bechstein this weekend more thoroughly. First impression: Beautiful strong sound. Maybe a bit percussive, but probably that is a signature of a Bechstein and I just tried the preset Bechstein Player so far ...

Thank you for making PTQ better again!
Cheers

Re: Pianoteq 6.4 not starting in Linux.

@julien

Is it possible for your to create a debian repo hosted by PianoTeq for the package installs instead of having to download from the website, then unzip then copy, etc?

BTW, what do i do with the .so file that's in AMD64 directory?

What is the lv2 directory for?

Thanks!

Last edited by Mk4UmHa (06-02-2019 17:08)

Re: Pianoteq 6.4 not starting in Linux.

I am trying to run Pianoteq 6.6.0 on a 64 bit Linux distro (Dietp version of ARMbian) on a Rock Pi 4 board.  The Pianoteq executable file cannot be recognized by BASH and it returns "Not found" error whenever I try to execute ./"Pianoteq 6' in the arm directory.  I put a copy of ping into this directory and ./ping runs with no problem.  Anyone have an idea of what is going on?

Re: Pianoteq 6.4 not starting in Linux.

fewarren wrote:

I am trying to run Pianoteq 6.6.0 on a 64 bit Linux distro (Dietp version of ARMbian) on a Rock Pi 4 board.  The Pianoteq executable file cannot be recognized by BASH and it returns "Not found" error whenever I try to execute ./"Pianoteq 6' in the arm directory.  I put a copy of ping into this directory and ./ping runs with no problem.  Anyone have an idea of what is going on?

It is off-topic. Anyway, just an idea:

Instead of ./"Pianoteq 6' try ./Pianoteq\ 6 in the your arm directory.

Is "Not found" the correct error message? For example under amd64 a non existing file on my Linux throws another error message "bash: ./Pianoteq 123: No such file or directory".