12 Dec
2017
12 Dec
'17
5:09 p.m.
On Tue, Dec 12, 2017 at 10:02 AM, Gordonjcp <gordonjcp(a)gjcp.net> wrote:
On Sun, Dec 10, 2017 at 09:26:55PM +0100, Markus
Seeber wrote:
You can still statically link for example with FLTK and derivatives or roll
your
That doesn't answer the question, really. For one thing, statically
linking *anything* is utterly ridiculous and anyone doing that now or
indeed at any point in the past 30 years of Unix development should have
their hands cut off.
I am not caught up on the entire conversation, but static linking is great.
Dynamic linking prevents optimizations across library boundaries, and does
work at runtime that could have been done at compile-time. Dynamic linking
makes distribution of binaries more cumbersome and error-prone. There's a
whole product / open source community around this containers concept which
is basically a way to turn a bunch of messy dynamically linked components
into a single static component.
Perhaps you are using hyperbole, but generalization of "statically linking
*anything*" belies a lack of understanding. Should every function of every
object file be dynamically linked? Should we never have an inline function?
There's a time and a place for dynamic linking, and it's plugins. But even
so, you want each plugin to be statically linked, and the only thing
dynamic is that you can load the plugin code from the host application at
runtime.
Regards,
Andrew Kelley
http://ziglang.org/
>> and be done with it, let offensive
software die. In my eyes writing a
plugin GUI
in GTK/Qt is very bad practice for exactly these
reasons.
So what would you write it in instead?
Why would FLTK be any better than Gtk or Qt? It's slow, bloated and
fairly ugly, and is yet another set of deps to pull in.
--
Gordonjcp
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev