[SUMMARY] Re: New acinclude.m4 - Mailing list pgadmin-hackers

To summarize :
- we reject the configure.ac.patch which removed ENABLE_STATIC and
should not have been included in trunk yet
- we keep the latest "acinclude_static.patch" which re-add support for
pg_static_build=yes + takes care of systems where wxWid installations
are both static & dynamic.

Everybody is ok with this?

Raphaël

Florian G. Pflug wrote:
> 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