wxWidgets and codelite build problem

Do you have a question about makefiles, a compiler or IDE you are using and need to know how to set it up for wxWidgets or why it doesn't compile but other IDE's do ? Post your questions here.
PB
Part Of The Furniture
Part Of The Furniture
Posts: 2859
Joined: Sun Jan 03, 2010 5:45 pm

Re: wxWidgets and codelite build problem

Post by PB » Mon Feb 08, 2021 7:50 pm

The static build has one advantage: You do not need to ship any DLLs with your executable at all. Actually, it has two advantages: As only the used library code is linked in, the resulting size of your application installation is usually smaller then when shipping executable + DLLs.

To have a true static build, one has to build wxWidgets statically (SHARED=0) but also link compiler libraries statically, e.g., when building wxWidgets using LDFLAGS="-static" parameter for make and also using this parameter when building your application.

eranif
Moderator
Moderator
Posts: 610
Joined: Tue Nov 29, 2005 7:10 pm
Location: Israel

Re: wxWidgets and codelite build problem

Post by eranif » Mon Feb 08, 2021 7:51 pm

No, always append $(PATH) (or prepend it).
Just do it on the workspace or project level rather than on the global IDE level
IDE: CodeLite + wxCrafter
OS: All
https://wxcrafter.codelite.org
https://codelite.org

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 4873
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: wxWidgets and codelite build problem

Post by ONEEYEMAN » Mon Feb 08, 2021 7:58 pm

Hi,
Eman wrote:
Mon Feb 08, 2021 7:40 pm
ONEEYEMAN wrote:
Mon Feb 08, 2021 7:33 pm
Hi,
Yes, that is exactly what PB meant.
However, the DLL build of wxWidgets means that you will be developing DLL yourself on top of the main application. Is that so?

Otherwise using dynamic build of wxWidgets have no sense.

Thank you.
Many thanks for you all.
I am developing c++ project (simple robotic simulator) using GUI (wxWidgets). I am not sure which was better for me dynamic or static build?
If you intend to have only one executable - it is better to have a static build.
Dynamic build make sense in case you will produce the DLL/so/dylib as part of your software.

Thank you.

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 4873
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: wxWidgets and codelite build problem

Post by ONEEYEMAN » Mon Feb 08, 2021 8:02 pm

Hi, PB,
PB wrote:
Mon Feb 08, 2021 7:50 pm
The static build has one advantage: You do not need to ship any DLLs with your executable at all. Actually, it has two advantages: As only the used library code is linked in, the resulting size of your application installation is usually smaller then when shipping executable + DLLs.

To have a true static build, one has to build wxWidgets statically (SHARED=0) but also link compiler libraries statically, e.g., when building wxWidgets using LDFLAGS="-static" parameter for make and also using this parameter when building your application.
You can't always have a fully static build, as Windows CRT can't always be legally linked statically.

In fact it is better not to do it and keep the Windows libraries dynamic.

Thank you.

PB
Part Of The Furniture
Part Of The Furniture
Posts: 2859
Joined: Sun Jan 03, 2010 5:45 pm

Re: wxWidgets and codelite build problem

Post by PB » Mon Feb 08, 2021 8:08 pm

ONEEYEMAN wrote:
Mon Feb 08, 2021 8:02 pm
You can't always have a fully static build, as Windows CRT can't always be legally linked statically.
I was not talking about Windows libraries, those are always available on a Windows computer. I meant not requiring any wxWidgets (e.g., wxbase314u_gcc_custom.dll and wxmsw314u_core_gcc_custom.dll) nor GCC (e.g., libgcc_s_dw2-1.dll, libstdc++-6.dll, or libwinpthread-1.dll) runtime linked libraries.

ONEEYEMAN
Part Of The Furniture
Part Of The Furniture
Posts: 4873
Joined: Sat Apr 16, 2005 7:22 am
Location: USA, Ukraine

Re: wxWidgets and codelite build problem

Post by ONEEYEMAN » Mon Feb 08, 2021 8:09 pm

PB,
OK, I will shut up now, as I'm not familiar with MinGW, and therefore have no idea about compiler specific libraries. ;-)

Thank you.

stahta01
Super wx Problem Solver
Super wx Problem Solver
Posts: 418
Joined: Fri Nov 03, 2006 2:00 pm

Re: wxWidgets and codelite build problem

Post by stahta01 » Thu Feb 11, 2021 2:51 am

Static link of GCC runtime library normally requires the product if released to the public to be open source and LGPL or GPL licensed.

Tim S.

PB
Part Of The Furniture
Part Of The Furniture
Posts: 2859
Joined: Sun Jan 03, 2010 5:45 pm

Re: wxWidgets and codelite build problem

Post by PB » Tue Feb 23, 2021 9:35 pm

stahta01 wrote:
Thu Feb 11, 2021 2:51 am
Static link of GCC runtime library normally requires the product if released to the public to be open source and LGPL or GPL licensed.
Could you please tell me what source is this information based on? I am certainly no expert but based on http://www.gnu.org/licenses/gcc-exception-3.1.html and the below from http://www.gnu.org/licenses/gcc-exception-3.1-faq.html
... neither the GPL nor the GCC Runtime Library Exception distinguish between static linking, dynamic linking, and other methods for combining code in their conditions. The same permissions are available to you, under the same terms, no matter which method you use.
....
The GCC Runtime Library Exception covers any file that has a notice in its license headers stating that the exception applies. This includes libgcc, libstdc++, libfortran, libgomp, libdecnumber, libgcov, and other libraries distributed with GCC.
it may appear that the way the GCC runtime libraries are linked has no effect on license which the application can use? Am I wrong?

stahta01
Super wx Problem Solver
Super wx Problem Solver
Posts: 418
Joined: Fri Nov 03, 2006 2:00 pm

Re: wxWidgets and codelite build problem

Post by stahta01 » Tue Feb 23, 2021 11:32 pm

PB: You appear to be right; but, I remember being told otherwise in the past.
All that I have found is parts require the copyright notice (like most BSD lic. code) does to be included.

Tim S.

Post Reply