Skip site navigation (1) Skip section navigation (2)

Re: New acinclude.m4

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Raphaël Enrici <blacknoz(at)club-internet(dot)fr>
Cc: "Adam H(dot) Pendleton" <fmonkey(at)fmonkey(dot)net>,Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: New acinclude.m4
Date: 2005-05-19 21:20:49
Message-ID: 428D0331.3050407@phlo.org (view raw or flat)
Thread:
Lists: 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

In response to

Responses

pgadmin-hackers by date

Next:From: Raphaël EnriciDate: 2005-05-19 21:27:41
Subject: [SUMMARY] Re: New acinclude.m4
Previous:From: Adam H. PendletonDate: 2005-05-19 21:12:25
Subject: Re: New acinclude.m4

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group