Thread: Static Build

I keep hearing that a static version of pgAdmin3 is desired, so I
thought that I would just squash the thought before it gets to far.  It
would be next to impossible to release a static version of pgAdmin3
because of the large number of dependencies of the program.  Keep in
mind, that just because we link against a static version of the
wxWindows library, doesn't mean that we aren't using shared symbols.  We
would also need static versions of glibc, PostgreSQL, and any libraries
against which any of those programs link.  We  would need to be able to
pull in static code for *every* library that our program touches, or any
library that a library our program touches touches.  I think statically
linking against wxWindows is a good idea, since it is not likely to be
available on client machines, but to statically link against something
like the GNU C Library is just an unnecessary headache, since it's not
unreasonable to require a client to have that library installed (every
other program on the machine requires it too!).  Just my 2 cents.

ahp

It's rumoured that Adam Pendleton once said:
> I keep hearing that a static version of pgAdmin3 is desired, so I
> thought that I would just squash the thought before it gets to far.  It
>  would be next to impossible to release a static version of pgAdmin3
> because of the large number of dependencies of the program.  Keep in
> mind, that just because we link against a static version of the
> wxWindows library, doesn't mean that we aren't using shared symbols.
> We  would also need static versions of glibc, PostgreSQL, and any
> libraries  against which any of those programs link.  We  would need to
> be able to  pull in static code for *every* library that our program
> touches, or any  library that a library our program touches touches.  I
> think statically  linking against wxWindows is a good idea, since it is
> not likely to be  available on client machines, but to statically link
> against something  like the GNU C Library is just an unnecessary
> headache, since it's not  unreasonable to require a client to have that
> library installed (every  other program on the machine requires it
> too!).  Just my 2 cents.

Hi Adam,

That sounds sensible. I think we're all pretty much settled on wx2.5 now
as well, so how about the following (for the Unix build - Win32 is a whole
other matter):
1) We make GTK2/wx25/Unicode requirements, and thus get rid of the
associated configure options. If we're producing mainly binary releases
anyway, this should only be a problem for those who want to compile on
older systems, from source.
Q. Is the GTK2 stuff can either be statically linked into wx or is it
common enough these days that we needn't worry about it?
2) We statically link wx and libpq. Currently libpq is dynamically linked.
This of course removes the requirement for PostgreSQL to be installed on
the target machine.
Q. To get SSL support we need to compile PostgreSQL with OpenSSL. Are
there any legal ramifications for this?
If we can do this, I think all we need is a --enable-debug option in
addition to --with-wx & --with-pgsql.
Thoughts, comments? Am I insane?

Regards, Dave

On Wednesday 11 June 2003 19:00, Adam Pendleton wrote:
> I keep hearing that a static version of pgAdmin3 is desired, so I
> thought that I would just squash the thought before it gets to far.  It
> would be next to impossible to release a static version of pgAdmin3
> because of the large number of dependencies of the program.  Keep in
> mind, that just because we link against a static version of the
> wxWindows library, doesn't mean that we aren't using shared symbols.  We
> would also need static versions of glibc, PostgreSQL, and any libraries
> against which any of those programs link.  We  would need to be able to
> pull in static code for *every* library that our program touches, or any
> library that a library our program touches touches.  I think statically
> linking against wxWindows is a good idea, since it is not likely to be
> available on client machines, but to statically link against something
> like the GNU C Library is just an unnecessary headache, since it's not
> unreasonable to require a client to have that library installed (every
> other program on the machine requires it too!).  Just my 2 cents.

Hi everyone,

This is why we need strong dependency checking during RPM install or whatever
other packaging system used.

By the way, the Suse 82 problem certainly relies to a dependency question.
Here is an extract of the spec file. Could you "tell" what package is missing
in order to build wxWindows 2.5 cvs? 0.01 cent question.

Requires: gtk2 >= 2.2, glibc >= 2.3.2, libjpeg >= 6, libpng >= 1.2.2, pango >=
1.2.1, libstdc++ >= 3.2.2, openssl >= 0.9.6, libtiff >= 3.5.7, zlib >= 1.1.4

BuildRequires: autoconf >= 2.57, automake >= 1.7.2, gtk2-devel >= 2.2,
postgresql >= 7.3.2, openssl-devel >= 0.9.6, pkgconfig >= 0.14, libpng-devel
>= 1.2.2, gtk2-engines >= 2.2, gcc-c++ >= 7.3

Cheers, Jean-Michel