On Sonntag, 2. Februar 2020 19:54:43 CET Frank Neumann wrote: > Hi all, Hi Frank,
> not sure if I overlooked some recent build requirement change, but with > Linux Mint 19.2 (gcc 7.4.0) I seem to be unable to build current > LinuxSampler (svn r3734) from source (but thie issue might been in for a > while already): The build requirement has in fact changed after last year's release: http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_1_1/ Like mentioned in those release notes, I've added a bunch of new features after that release, which would be hard to maintain without modern C++ standard support by the compiler. So current min. requirement is a compiler with at least C++14 support. Last year's release even compiled with pre-C++11 compilers. > parser.y: In function ‘int InstrScript_parse(LinuxSampler::ParserContext*)’: > parser.y:311:25: sorry, unimplemented: non-trivial designated initializers > not supported }); > ^ > parser.y:311:25: sorry, unimplemented: non-trivial designated initializers > not supported parser.y:311:25: sorry, unimplemented: non-trivial designated > initializers not supported parser.y:311:25: sorry, unimplemented: > non-trivial designated initializers not supported parser.y:318:26: sorry, > unimplemented: non-trivial designated initializers not supported }); > ^ > > There is a whole bunch more of these "sorry, unimplemented..." lines on the > same file. Bison version is 3.0.4. > > I rebuilt&installed current libgig/liblscp packages before building this > one, all fine so far. > > Do I have to run some manual "generate" step first? Short: either compile with clang (works also with quite old versions of clang) or update to GCC >= 8.x. You can install both clang and gcc without problems. If you have both installed, just force LS compilation with clang like this: CXX=clang++ CC=clang ./configure && make Background: The LS code base is now using a lot of so called "designated initializers", probably better described as C-style "named initializers" for semantic critical functions/methods. Instead of this: void foo(int a, float b, char c, bool d) { ... } ... foo(1, 2.9, 'a', true); // function call it's now (often) like this instead: struct FooOpt { int a; float b; char c; bool d; } void foo(FooOpt& opt) { ... } ... foo({ // function call .a = 1, .b = 2.9, .c = 'a', .d = true }); Reason: after a while (months, years, ...), arguments of functions/methods are typically changed, which can silently introduce bugs since the compiler only checks function calls for type correctness with the old function call style. By binding a function argument to a name, you are binding it to a specific semantic when calling the function, which the compiler would immediately recognize with an error if function's semantics were changed without updating all calls appropriately, and hence prevents such kind of bugs at compilation. It also makes the code more readable. I know C++>=14 requirement is quite a shift regarding backward compatibility of LS, but a bunch of new C++ language features reduce code complexity (and hence development time and bug affinity) significantly, and the LS code base is already quite large, so I decided to go for the "please use recent compilers" route after last year's release instead of investing a lot of time for supporting old compilers. CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
