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