Re: [pgadmin-hackers] New acinclude.m4

[Florian G. Pflug]

Raphaėl Enrici wrote:

Adam H. Pendleton wrote:

On May 19, 2005, at 4:30 PM, Raphaėl Enrici wrote:

Adam H. Pendleton wrote:

I'm glad to be so "rare"... It seems I belong to the 1%: I have a
dynamic build. ;)
Please also note that the patch attached reintroduce your code
concerning the static link of the rest of the libs (libpq and sons).

However, you are the ac guru and I'm fully satisfied by a dynamic
linking with the new acinclude.m4 (+ the configure.ac patch).
The real question is:
- do we still need "full" static linking (at least libpq, ssl,..?).

If yes, then the new acinclude.m4 does not provide it anymore and we
need to rework on it.

Are you saying that `wx-config --libs` and `wx-config --libs -- static` produce two different outputs on your system? If you built wx dynamically then either a) the output from --libs --static is nonsense, or b) it's the same as --libs. Either way, the current acinclude will link the same way you linked wx.

What I'm trying to say is this:
I've a dynamic only build. So, wx-config --libs is ok. wx-config
--static --libs gives an error.
According to what I understand from the wx-config --help output is:
if I had both built and would like to get informations concerning the
static wxWid libs, then I'd need to pass --static to wx-config. Right?

As for the full static linking, --enable-static never performed a full static link, it only statically linked against wxWindows. Personally, I don't like static linking. It creates huge executables, eats up memory, and slows down performance. We should link dynamically wherever possible.

Actually, it linked wx _and_ libpq statically - this is what acinclude.m4 says:

    if test "$pg_static_build" = "yes"
    then
        if test "$build_cpu-$build_vendor" = "powerpc-apple"
        then
            CRYPT_LIB=""
        else
            CRYPT_LIB="-lcrypt"
        fi

if test "$pgsql_ssl_libpq" = "yes"
then
LIBS="${LIBPQ_HOME}/lib/libpq.a $CRYPT_LIB $LIBS -lssl -lcrypto"
else
LIBS="${LIBPQ_HOME}/lib/libpq.a $CRYPT_LIB $LIBS -lcrypto"
fi
else
if test "$pgsql_ssl_libpq" = "yes"
then
LIBS="$LIBS -lssl -lcrypto -lpq"
else
LIBS="$LIBS -lcrypto -lpq"
fi
fi

So, it linkes libpq statically, and the rest dynamically - which
I believe is correct, since libssl is pretty much a standard
library, which you can expect to find on most systems - libpq
OTOH is not "that-much-standard" ;-)

yup, _I HATE STATIC BUILDS TOO_ :)) But, it seems that at least for
Florian this is important. The latest patch I sent just does two things:
a) force static parameters of wxWid, just in case the wx-config --libs
would not give the _static_ lib informations when both shared and static
are installed on the system.
b) re-introduce the pg_static_build=yes variable which is later
interpreted just as in previous versions because the old code is still
there.

Sounce good to me - but if there is no interest in supporting
static builds on all plattforms, I could also special-case
OSX, and turn static linking of libpq on when building a .app-bundle.

greetings, Florian Pflug

smime.p7s
Description: S/MIME Cryptographic Signature