Licensing for Qt Embedded - Static build
-
Hi and welcome to devnet,
WARNING I AM NOT A LAWYER
Under LGPL, no you don't have to share your source code, you have to share the modifications you make to Qt if any and you have to provide the build objects of your application so people wanting to can re-build your application using their own version of Qt.
If you want a definite answer, ask a lawyer.
On a side note, the latest of the Qt 4 series is Qt 4.8.7.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Hi and welcome to devnet,
WARNING I AM NOT A LAWYER
Under LGPL, no you don't have to share your source code, you have to share the modifications you make to Qt if any and you have to provide the build objects of your application so people wanting to can re-build your application using their own version of Qt.
If you want a definite answer, ask a lawyer.
On a side note, the latest of the Qt 4 series is Qt 4.8.7.
-
LPGL doesn't dictate that you can't have static build. What you have to provide is the means to re-build your application with a different version of the library, therefore you have to provide the build objects.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
@Hariprasasth said in Licensing for Qt Embedded - Static build:
Developing software for lower end embedded hardware (64 MB RAM, Arm PXA270 hardware which runs on 620 MHz processor speed) so I cannot go for latest version of Qt
That assumption is utterly wrong. See this blog post https://blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu/
I would use Qt as a 'Static' build not 'Shared'. This is mainly for performance enhancement.
Better measure the impact first. And analyse your software for bottlenecks - you are far more likely to write suboptimal code than shared vs. static difference would buy you. And that's not me being judgemental in any way about your expertise - I don't question that. I just know that when it comes to performance, the problems are usually not where one would suspect. I've been bitten by this many times :-)
-
LPGL doesn't dictate that you can't have static build. What you have to provide is the means to re-build your application with a different version of the library, therefore you have to provide the build objects.
@SGaist
That is interesting. I was under the distinct impression that when I first read up on this the Qt company's terms specifically said something about static linking of Qt libraries not being allowed if using LGPL license. But I admit I am unable to find the reference. -
@SGaist
That is interesting. I was under the distinct impression that when I first read up on this the Qt company's terms specifically said something about static linking of Qt libraries not being allowed if using LGPL license. But I admit I am unable to find the reference.@JonB said in Licensing for Qt Embedded - Static build:
@SGaist
That is interesting. I was under the distinct impression that when I first read up on this the Qt company's terms specifically said something about static linking of Qt libraries not being allowed if using LGPL license. But I admit I am unable to find the reference.QtC has vested interest in making people believe that static linking is a no go. The LGPL license does not prohibit it, though (it does, however, make it very hard to satisfy the license when using static linking. On some platforms, like iOS in the past, it was indeed impossible to use LGPL. It is also at least highly questionable on embedded devices, where users have no means of tweaking the software).
So, in very general terms it is OK to say that static linking is not allowed under LGPL, but such sentence should be followed with some star * and explanation in small print at the bottom of a page ;-)
(Z(:^
-
@JonB said in Licensing for Qt Embedded - Static build:
@SGaist
That is interesting. I was under the distinct impression that when I first read up on this the Qt company's terms specifically said something about static linking of Qt libraries not being allowed if using LGPL license. But I admit I am unable to find the reference.QtC has vested interest in making people believe that static linking is a no go. The LGPL license does not prohibit it, though (it does, however, make it very hard to satisfy the license when using static linking. On some platforms, like iOS in the past, it was indeed impossible to use LGPL. It is also at least highly questionable on embedded devices, where users have no means of tweaking the software).
So, in very general terms it is OK to say that static linking is not allowed under LGPL, but such sentence should be followed with some star * and explanation in small print at the bottom of a page ;-)
@sierdzio said in Licensing for Qt Embedded - Static build:
So, in very general terms it is OK to say that static linking is not allowed under LGPL, but such sentence should be followed with some star * and explanation in small print at the bottom of a page ;-)
It is allowed. See the GNU GPL faq about static linking and LGPL.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
@sierdzio said in Licensing for Qt Embedded - Static build:
So, in very general terms it is OK to say that static linking is not allowed under LGPL, but such sentence should be followed with some star * and explanation in small print at the bottom of a page ;-)
It is allowed. See the GNU GPL faq about static linking and LGPL.
@SGaist said in Licensing for Qt Embedded - Static build:
@sierdzio said in Licensing for Qt Embedded - Static build:
So, in very general terms it is OK to say that static linking is not allowed under LGPL, but such sentence should be followed with some star * and explanation in small print at the bottom of a page ;-)
It is allowed. See the GNU GPL faq about static linking and LGPL.
Yes, I know and I hope I explained it ;-) I just meant that a TL;DR summary could state that it is not allowed, simply because it requires big effort to pull it off. Anyway, that's just my opinion. I'm pretty sure the reference OP is mentioning came from Qt Company back when iOS really was not compatible with LGPL at all.
-
@Hariprasasth said in Licensing for Qt Embedded - Static build:
Developing software for lower end embedded hardware (64 MB RAM, Arm PXA270 hardware which runs on 620 MHz processor speed) so I cannot go for latest version of Qt
That assumption is utterly wrong. See this blog post https://blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu/
I would use Qt as a 'Static' build not 'Shared'. This is mainly for performance enhancement.
Better measure the impact first. And analyse your software for bottlenecks - you are far more likely to write suboptimal code than shared vs. static difference would buy you. And that's not me being judgemental in any way about your expertise - I don't question that. I just know that when it comes to performance, the problems are usually not where one would suspect. I've been bitten by this many times :-)
@sierdzio I just created simple application to verify performance between static vs shared build:
Test application creates screen which contains 60 controls (30 - QPushbutton Icon+Text, 30 - QLabel).
Timing:
Static build - 1.1 seconds
Shared build - 1.5 secondshttps://doc.qt.io/archives/qtextended4.4/qt-embedded-performance.html#static-vs-dynamic-linking
Thanks,
Hari -
OK, so here the results (both) are pretty decent. I mean 60 controls in less than 2s - that seems good to me. And you have not enabled Link Time Optimizations (right?) which might change the results considerably. It's still just a test app. Results for the final app may vary.
Anyway, I'm not saying this to discourage static builds, they are a fine solution, sure.
-
@sierdzio I just created simple application to verify performance between static vs shared build:
Test application creates screen which contains 60 controls (30 - QPushbutton Icon+Text, 30 - QLabel).
Timing:
Static build - 1.1 seconds
Shared build - 1.5 secondshttps://doc.qt.io/archives/qtextended4.4/qt-embedded-performance.html#static-vs-dynamic-linking
Thanks,
Hari@Hariprasasth
I don't get this. I have read the link you included.So far as I understood it, the time difference in application execution between a dynamically linked vs statically linked would just be a (modest) difference in start-up time. You have one application. Once it's taken 0.4 seconds longer to start-up initially, it shouldn't make any difference whether you create 3 controls, 30 or 300, the code being executed will run at the same speed between the two. Unless there is something special about embedded which I understand nothing about.
Am I wrong, or is this a one-time half a second improvement you're talking about?
-
@Hariprasasth
I don't get this. I have read the link you included.So far as I understood it, the time difference in application execution between a dynamically linked vs statically linked would just be a (modest) difference in start-up time. You have one application. Once it's taken 0.4 seconds longer to start-up initially, it shouldn't make any difference whether you create 3 controls, 30 or 300, the code being executed will run at the same speed between the two. Unless there is something special about embedded which I understand nothing about.
Am I wrong, or is this a one-time half a second improvement you're talking about?
-
@JonB
Its not only about start-up. After starting-up, I tried to redraw all the controls on clicking one button. And, still I see the timing difference between static and shared (0.4 sec).Thanks,
Hari@Hariprasasth
And how would that come about? Would a Qt expert care to comment on how a statically vs dynamically linked set of Qt libraries can perform at different runtime speeds, after start-up? -
@sierdzio I just created simple application to verify performance between static vs shared build:
Test application creates screen which contains 60 controls (30 - QPushbutton Icon+Text, 30 - QLabel).
Timing:
Static build - 1.1 seconds
Shared build - 1.5 secondshttps://doc.qt.io/archives/qtextended4.4/qt-embedded-performance.html#static-vs-dynamic-linking
Thanks,
Hari@Hariprasasth said in Licensing for Qt Embedded - Static build:
Timing:
Static build - 1.1 seconds
Shared build - 1.5 secondsUnless you care to provide actual statistics this has no meaning. The uncertainty of one sample is just the square root of the value of said sample, meaning for all intents of purposes those two numbers are equal.
@JonB said in Licensing for Qt Embedded - Static build:
And how would that come about?
It shouldn't.
Would a Qt expert care to comment on how a statically vs dynamically linked set of Qt libraries can perform at different runtime speeds, after start-up?
I'm no expert, but I wouldn't even hazard a guess.
@sierdzio said in Licensing for Qt Embedded - Static build:
Anyway, I'm not saying this to discourage static builds, they are a fine solution, sure.
Maybe in some specific situations, which doesn't seem to be the case here. I'd rather all the KDE apps of the Plasma desktop I'm running link dynamically (and to the same library), instead of each bundling a copy of the same thing. Also the OS's loader can optimize loading dynamic libraries (i.e. they may already be in memory), which it can never do when you link statically.
So a "fine solution" is already pushing it a bit.Read and abide by the Qt Code of Conduct
-
@Hariprasasth said in Licensing for Qt Embedded - Static build:
Timing:
Static build - 1.1 seconds
Shared build - 1.5 secondsUnless you care to provide actual statistics this has no meaning. The uncertainty of one sample is just the square root of the value of said sample, meaning for all intents of purposes those two numbers are equal.
@JonB said in Licensing for Qt Embedded - Static build:
And how would that come about?
It shouldn't.
Would a Qt expert care to comment on how a statically vs dynamically linked set of Qt libraries can perform at different runtime speeds, after start-up?
I'm no expert, but I wouldn't even hazard a guess.
@sierdzio said in Licensing for Qt Embedded - Static build:
Anyway, I'm not saying this to discourage static builds, they are a fine solution, sure.
Maybe in some specific situations, which doesn't seem to be the case here. I'd rather all the KDE apps of the Plasma desktop I'm running link dynamically (and to the same library), instead of each bundling a copy of the same thing. Also the OS's loader can optimize loading dynamic libraries (i.e. they may already be in memory), which it can never do when you link statically.
So a "fine solution" is already pushing it a bit.@kshegunov said in Licensing for Qt Embedded - Static build:
@JonB said in Licensing for Qt Embedded - Static build:
And how would that come about?
It shouldn't.
Thank you! My point being, from my understanding and usage of static vs dynamic, there should only be a difference at start-up time, once it's in memory there should not be any difference at runtime. And if the OP's statistics of 50%-odd difference is true/replicated, I would expect everyone to have abandoned/complained about dynamic a long time ago!
-
@kshegunov said in Licensing for Qt Embedded - Static build:
@JonB said in Licensing for Qt Embedded - Static build:
And how would that come about?
It shouldn't.
Thank you! My point being, from my understanding and usage of static vs dynamic, there should only be a difference at start-up time, once it's in memory there should not be any difference at runtime. And if the OP's statistics of 50%-odd difference is true/replicated, I would expect everyone to have abandoned/complained about dynamic a long time ago!
@JonB said in Licensing for Qt Embedded - Static build:
My point being, from my understanding and usage of static vs dynamic, there should only be a difference at start-up time, once it's in memory there should not be any difference at runtime.
No not only, but the difference should be negligible to non-existent. Probably the "major" hit comes from generating cache misses (due to indirect references) when the CPU is executing the code. I'm going to say it again, though, this should be so insignificant in this kind of code that I wouldn't even venture into considering it.
PS.
Some related resources if you're feeling curious.Read and abide by the Qt Code of Conduct
-
@JonB said in Licensing for Qt Embedded - Static build:
My point being, from my understanding and usage of static vs dynamic, there should only be a difference at start-up time, once it's in memory there should not be any difference at runtime.
No not only, but the difference should be negligible to non-existent. Probably the "major" hit comes from generating cache misses (due to indirect references) when the CPU is executing the code. I'm going to say it again, though, this should be so insignificant in this kind of code that I wouldn't even venture into considering it.
PS.
Some related resources if you're feeling curious.@kshegunov said in Licensing for Qt Embedded - Static build:
@JonB said in Licensing for Qt Embedded - Static build:
PS.
Some related resources if you're feeling curious.Quoting from there:
Instructions that refer directly to specific memory addresses sometimes
execute faster, and replacing them with equivalent relative-addressing
instructions may result in slightly slower execution, although modern
processors make the difference practically negligible.Here we are talking about a very weak CPU with very slow memory (104 MHz RAM according to the specification). It may well prefer static builds.
I'd still throw in LTO is the compiler for that CPU supports it (see link).
You are, of course, absolutely right that a statistical analysis of the results is necessary for proper judgement, though.
