Re: New acinclude.m4 - Mailing list pgadmin-hackers

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