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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to