|
Home > Archive > Unix Programming > October 2006 > Statically compling GTK+ programs
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Statically compling GTK+ programs
|
|
|
|
Can I compile a GTK+ application (panels built with Glade2) into a single
statically linked binary which statically links everything to do with GTK+ ?
This app will be multi platform and I don't want to have to impose all of the
necessary GTK developer libraries and headers onto folks who want to run the
app on HP-UX, Solaris or AIX.
I can't see an option in the automake/configure generated from Glade2 which
will do this.
--
remove stars for email
g*a*r*y*c*o*w*e*l*l*a*t*m*a*c*d*o*t*c*o*
m
| |
| Michel Bardiaux 2006-10-19, 7:32 am |
| On Mon, 16 Oct 2006 19:04:03 +0100, Gary <postmaster@127.0.0.1> wrote:
>
>Can I compile a GTK+ application (panels built with Glade2) into a single
>statically linked binary which statically links everything to do with GTK+ ?
>
>This app will be multi platform and I don't want to have to impose all of the
>necessary GTK developer libraries and headers onto folks who want to run the
>app on HP-UX, Solaris or AIX.
If you link dynamically *then* the execution platform will not need
the development libraries, only the DSOs.
If you use static linking, then to comply with LGPL (since GTK+ is
LGPL) you would have to distribute at least the relocatable binaries
of your application, and the receiver would need the GTK+ dev
packages.
So, chosing static linking has exactly the opposite effect of what you
intend!
>
>I can't see an option in the automake/configure generated from Glade2 which
>will do this.
Ah, automake... That's even worse; if you distribute .am files then
the receiver will probably need to have exactly the same rev of the
autotools as you have.
Cheers,
| |
| James Antill 2006-10-20, 1:22 pm |
| On Thu, 19 Oct 2006 12:13:52 +0200, Michel Bardiaux wrote:
> On Mon, 16 Oct 2006 19:04:03 +0100, Gary <postmaster@127.0.0.1> wrote:
>
You are somewhat screwed, the glib/gtk+ developers basically don't
support static linking. It might be possible with special compile flags
for the libraries, but IIRC the default is to not even build .a
versions of the libraries.
Your best bet is to have a distribution which contains all of the
gtk+/etc. libraries and uses a LD_LIBRARY_PATH script ala. win32.
[vbcol=seagreen]
> If you link dynamically *then* the execution platform will not need
> the development libraries, only the DSOs.
>
> If you use static linking, then to comply with LGPL (since GTK+ is
> LGPL) you would have to distribute at least the relocatable binaries
> of your application, and the receiver would need the GTK+ dev
> packages.
If you distribute a dynamic and static version, the LGPL issue isn't.
Also if you distribute source, you are fine. This is basically a
non-problem.
--
James Antill -- james@and.org
http://www.and.org/and-httpd
| |
| Logan Shaw 2006-10-21, 1:27 am |
| James Antill wrote:
> On Thu, 19 Oct 2006 12:13:52 +0200, Michel Bardiaux wrote:
>
[vbcol=seagreen]
> You are somewhat screwed, the glib/gtk+ developers basically don't
> support static linking.
> Your best bet is to have a distribution which contains all of the
> gtk+/etc. libraries and uses a LD_LIBRARY_PATH script ala. win32.
Or use a run-time linker path relative to the location of the binary.
On Solaris, this can be accomplished by passing arguments like
-R'$ORIGIN/../lib'
to the linker. Then as long as you preserve the relative structure of
your installation, the binaries can find the libraries with zero
configuration at install time. And zero wrapper scripts.
- Logan
| |
| jmcgill 2006-10-22, 1:20 am |
| James Antill wrote:
> You are somewhat screwed, the glib/gtk+ developers basically don't
> support static linking.
I've seen Linux distributions that have packages for static GTK+.
|
|
|
|
|