Обсуждение: New acinclude.m4
Attached is a new acinclude.m4, and a patch to our current acinclude, that relies on wx-config for all the flags. Gone is all the complicated stuff. The only thing this new acinclude doesn't do is warn about a missing stc or ogl. It will link against them, but if a user doesn't have them, their compile will fail. I'll be adding in stub programs to test for this in my next version. In the meantime, test and enjoy. On another note, could someone please check out ./pkg/mac/complete- bundle.sh and chmod +x it? The compile on mac fails with an error because the execute bit is not set. ahp
Вложения
> -----Original Message----- > From: pgadmin-hackers-owner@postgresql.org > [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of > Adam H. Pendleton > Sent: 18 May 2005 22:26 > To: pgadmin-hackers@postgresql.org > Subject: [pgadmin-hackers] New acinclude.m4 > > Attached is a new acinclude.m4, and a patch to our current > acinclude, > that relies on wx-config for all the flags. Gone is all the > complicated stuff. The only thing this new acinclude doesn't do is > warn about a missing stc or ogl. It will link against them, > but if a > user doesn't have them, their compile will fail. I'll be adding in > stub programs to test for this in my next version. In the meantime, > test and enjoy. Great, thanks Adam - committed. > On another note, could someone please check out ./pkg/mac/complete- > bundle.sh and chmod +x it? The compile on mac fails with an error > because the execute bit is not set. It's already mode 755 on a fresh checkout here. Regards, Dave
On May 19, 2005, at 4:34 AM, Dave Page wrote:
It's already mode 755 on a fresh checkout here.
Hmmm, it seems that everything gets a mode of 644 when I use the "download tarball" option from the cvsweb interface (still waiting for a Fink binary for Tiger!).
ahp
Dave Page wrote: > > > >>-----Original Message----- >>From: pgadmin-hackers-owner@postgresql.org >>[mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of >>Adam H. Pendleton >>Sent: 18 May 2005 22:26 >>To: pgadmin-hackers@postgresql.org >>Subject: [pgadmin-hackers] New acinclude.m4 >> >>Attached is a new acinclude.m4, and a patch to our current >>acinclude, >>that relies on wx-config for all the flags. Gone is all the >>complicated stuff. The only thing this new acinclude doesn't do is >>warn about a missing stc or ogl. It will link against them, >>but if a >>user doesn't have them, their compile will fail. I'll be adding in >>stub programs to test for this in my next version. In the meantime, >>test and enjoy. > > > Great, thanks Adam - committed. I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Regards, Raphaël Index: configure.ac =================================================================== --- configure.ac (revision 4219) +++ configure.ac (working copy) @@ -35,7 +35,6 @@ CHECK_WX_CONFIG_BINARY CHECK_PGSQL_INCLUDE ENABLE_DEBUG -ENABLE_STATIC CHECK_PGSQL CHECK_WXWINDOWS
Yes. Nice catch. On May 19, 2005, at 1:07 PM, Raphaël Enrici wrote: > Dave Page wrote: > > >> >> >> >> >> >>> -----Original Message----- >>> From: pgadmin-hackers-owner@postgresql.org >>> [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of >>> Adam H. Pendleton >>> Sent: 18 May 2005 22:26 >>> To: pgadmin-hackers@postgresql.org >>> Subject: [pgadmin-hackers] New acinclude.m4 >>> >>> Attached is a new acinclude.m4, and a patch to our current >>> acinclude, >>> that relies on wx-config for all the flags. Gone is all the >>> complicated stuff. The only thing this new acinclude doesn't do is >>> warn about a missing stc or ogl. It will link against them, >>> but if a >>> user doesn't have them, their compile will fail. I'll be adding in >>> stub programs to test for this in my next version. In the meantime, >>> test and enjoy. >>> >>> >> >> >> Great, thanks Adam - committed. >> >> > > > I have warning concerning ENABLE_STATIC in configure script. Shouldn't > we also remove it crom configure.ac ? (patch attached). > > Regards, > Raphaël > Index: configure.ac > =================================================================== > --- configure.ac (revision 4219) > +++ configure.ac (working copy) > @@ -35,7 +35,6 @@ > CHECK_WX_CONFIG_BINARY > CHECK_PGSQL_INCLUDE > ENABLE_DEBUG > -ENABLE_STATIC > CHECK_PGSQL > CHECK_WXWINDOWS > > >
----Message d'origine---- >Copie à: Dave Page <dpage@vale-housing.co.uk>, >De: Adam H.Pendleton <fmonkey@fmonkey.net> >Sujet: Re: [pgadmin-hackers] New acinclude.m4 >Date: Thu, 19 May 2005 13:14:47 -0400 >A: Raphaël Enrici <blacknoz@club-internet.fr> > >Yes. Nice catch. A small one compared to the work you did! The new acinclude.m4 works like a charm even with wxWid --flavour and even on pgAdmin REL-1_2_0_PATCHES branch. Do you think to any problem including it in 1.2.x branch apart from the fact that you invoke 'ogl' which is not requiredfor 1.2.2 but does not harm the 1.2.x build ? Regards, Raphaël > >On May 19, 2005, at 1:07 PM, Raphaël Enrici wrote: > > >> Dave Page wrote: >> >> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: pgadmin-hackers-owner@postgresql.org >>>> [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of >>>> Adam H. Pendleton >>>> Sent: 18 May 2005 22:26 >>>> To: pgadmin-hackers@postgresql.org >>>> Subject: [pgadmin-hackers] New acinclude.m4 >>>> >>>> Attached is a new acinclude.m4, and a patch to our current >>>> acinclude, >>>> that relies on wx-config for all the flags. Gone is all the >>>> complicated stuff. The only thing this new acinclude doesn't do is >>>> warn about a missing stc or ogl. It will link against them, >>>> but if a >>>> user doesn't have them, their compile will fail. I'll be adding in >>>> stub programs to test for this in my next version. In the meantime, >>>> test and enjoy. >>>> >>>> >>> >>> >>> Great, thanks Adam - committed. >>> >>> >> >> >> I have warning concerning ENABLE_STATIC in configure script. Shouldn't >> we also remove it crom configure.ac ? (patch attached). >> >> Regards, >> Raphaël >> Index: configure.ac >> =================================================================== >> --- configure.ac (revision 4219) >> +++ configure.ac (working copy) >> @@ -35,7 +35,6 @@ >> CHECK_WX_CONFIG_BINARY >> CHECK_PGSQL_INCLUDE >> ENABLE_DEBUG >> -ENABLE_STATIC >> CHECK_PGSQL >> CHECK_WXWINDOWS >> >> >> > > > >---------------------------(end of broadcast)--------------------------- >TIP 7: don't forget to increase your free space map settings >
Raphaël Enrici wrote: > I have warning concerning ENABLE_STATIC in configure script. Shouldn't > we also remove it crom configure.ac ? (patch attached). Does this mean the linking statically is not possible anymore? Or has the check just moved to another place? greetings, Florian Pflug
Florian G. Pflug wrote: > Raphaël Enrici wrote: > >>I have warning concerning ENABLE_STATIC in configure script. Shouldn't >>we also remove it crom configure.ac ? (patch attached). > > > Does this mean the linking statically is not possible anymore? > Or has the check just moved to another place? To me, as Adam is making the build relying on wx-config flags, the build is considered static if wxWid was built with --disabled-shared passed to its configure. In the case where wxWidgets has been built with --enable-shared, pgadmin will inherit this default and build dynamically (same thing if both shared and static wxWid libs were built, the shared build will become the default...). Maybe it would be worth to still being able to force a static build by passing "--static" to wx-config in our acinclude.m4. Something like : if we pas --enable-static to our configure, then pass --static to wx-config so that we build statically, if not then don't pass anything in particular. Adam ? Regards, Raphaël
Raphaël Enrici wrote: > Florian G. Pflug wrote: >>Raphaël Enrici wrote: >>>I have warning concerning ENABLE_STATIC in configure script. Shouldn't >>>we also remove it crom configure.ac ? (patch attached). >> >> >>Does this mean the linking statically is not possible anymore? >>Or has the check just moved to another place? > > To me, as Adam is making the build relying on wx-config flags, the build > is considered static if wxWid was built with --disabled-shared passed > to its configure. In the case where wxWidgets has been built with > --enable-shared, pgadmin will inherit this default and build dynamically > (same thing if both shared and static wxWid libs were built, the shared > build will become the default...). Will a statically-built wx make the _whole_ pgadmin link statically too, or will only the wx-libraries be linkes statically and e.g. libpq dynamically. It would be the right thing to do, I guess - but then there would be need for a global "--enable-static" flag, that defined the linking-type for all other libs beside wx. At least for OSX, linking the release-versions statically it the most reliable method, while keeping the resulting app small. > Maybe it would be worth to still being able to force a static build by > passing "--static" to wx-config in our acinclude.m4. Something like : > if we pas --enable-static to our configure, then pass --static to > wx-config so that we build statically, if not then don't pass anything > in particular. Sounds reasonable - additionally --enable-static should link e.g. libpq statically too. greetings, Florian Pflug
Florian G. Pflug wrote:
> Raphaël Enrici wrote:
>
>>Florian G. Pflug wrote:
>>
>>>Raphaël Enrici wrote:
>>>
>>>>I have warning concerning ENABLE_STATIC in configure script. Shouldn't
>>>>we also remove it crom configure.ac ? (patch attached).
>>>
>>>
>>>Does this mean the linking statically is not possible anymore?
>>>Or has the check just moved to another place?
>>
>>To me, as Adam is making the build relying on wx-config flags, the build
>> is considered static if wxWid was built with --disabled-shared passed
>>to its configure. In the case where wxWidgets has been built with
>>--enable-shared, pgadmin will inherit this default and build dynamically
>>(same thing if both shared and static wxWid libs were built, the shared
>>build will become the default...).
>
> Will a statically-built wx make the _whole_ pgadmin link statically too,
> or will only the wx-libraries be linkes statically and e.g. libpq
> dynamically.
To me, second case. wx static the rest of the world dynamic.
>It would be the right thing to do, I guess - but then there
> would be need for a global "--enable-static" flag, that defined
> the linking-type for all other libs beside wx. At least for OSX,
> linking the release-versions statically it the most reliable method,
> while keeping the resulting app small.
So, if I'm right we have lost this functionnality. But, again, I may be
wrong.
Can you try the patch attached on OSX with a fresh checkout (don't
apply the configure.ac I just sent) ? (I need to rebuild wxWid to
generate static libs... it may take a moment).
Cheers,
Raphaël
>>Maybe it would be worth to still being able to force a static build by
>>passing "--static" to wx-config in our acinclude.m4. Something like :
>>if we pas --enable-static to our configure, then pass --static to
>>wx-config so that we build statically, if not then don't pass anything
>>in particular.
>
> Sounds reasonable - additionally --enable-static should link e.g. libpq
> statically too.
>
> greetings, Florian Pflug
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
Index: acinclude.m4
===================================================================
--- acinclude.m4 (revision 4219)
+++ acinclude.m4 (working copy)
@@ -59,6 +59,18 @@
AC_SUBST(pg_debug_build)
############################
+# Static build of pgAdmin3 #
+############################
+AC_DEFUN([ENABLE_STATIC],
+[AC_ARG_ENABLE(static,
+[ --enable-static build a static version of pgAdmin3],
+[pg_static_build=yes
+WX_STATIC="--static"],
+[pg_static_build=no
+WX_STATIC=""])
+])
+
+############################
# Build an pgAdmin III.app #
############################
AC_DEFUN([ENABLE_APPBUNDLE],
@@ -255,8 +267,8 @@
LDFLAGS="$LDFLAGS -L${WX_HOME}/lib"
WX_OLD_LDFLAGS="$LDFLAGS"
WX_OLD_CPPFLAGS="$CPPFLAGS"
- WX_NEW_LIBS=`${WX_CONFIG} --libs`
- WX_NEW_CONTRIB_LIBS=`${WX_CONFIG} --libs stc,ogl`
+ WX_NEW_LIBS=`${WX_CONFIG} ${WX_STATIC} --libs`
+ WX_NEW_CONTRIB_LIBS=`${WX_CONFIG} ${WX_STATIC} --libs stc,ogl`
LIBS="$LIBS $WX_NEW_LIBS $WX_NEW_CONTRIB_LIBS"
WX_NEW_CPPFLAGS=`${WX_CONFIG} --cppflags`
CPPFLAGS="$CPPFLAGS $WX_NEW_CPPFLAGS"
On May 19, 2005, at 2:13 PM, Florian G. Pflug wrote: > Raphaël Enrici wrote: > >> I have warning concerning ENABLE_STATIC in configure script. >> Shouldn't >> we also remove it crom configure.ac ? (patch attached). >> > > Does this mean the linking statically is not possible anymore? > Or has the check just moved to another place? Static linking is totally dependent on how wx2 was built. If wx2 was built statically, we link statically. If it was not a static build we dynamically link. ahp
On May 19, 2005, at 3:24 PM, Florian G. Pflug wrote: > Raphaël Enrici wrote: > >> Florian G. Pflug wrote: >> >>> Raphaël Enrici wrote: >>> >>>> I have warning concerning ENABLE_STATIC in configure script. >>>> Shouldn't >>>> we also remove it crom configure.ac ? (patch attached). >>>> >>> >>> >>> Does this mean the linking statically is not possible anymore? >>> Or has the check just moved to another place? >>> >> To me, as Adam is making the build relying on wx-config flags, the >> build >> is considered static if wxWid was built with --disabled-shared >> passed >> to its configure. In the case where wxWidgets has been built with >> --enable-shared, pgadmin will inherit this default and build >> dynamically >> (same thing if both shared and static wxWid libs were built, the >> shared >> build will become the default...). >> > Will a statically-built wx make the _whole_ pgadmin link statically > too, > or will only the wx-libraries be linkes statically and e.g. libpq > dynamically. It would be the right thing to do, I guess - but then > there > would be need for a global "--enable-static" flag, that defined > the linking-type for all other libs beside wx. At least for OSX, > linking the release-versions statically it the most reliable method, > while keeping the resulting app small. I ran into some real problems trying to link the whole app statically, especially on Linux. There is a flag that can be passed (to ld I think) that makes all linking static, but IIRC I found that some linux libraries didn't like that much, and would require dynamic linking. Besides, in this day and age, there really isn't any reason to completely statically link, except for debugging purposes, and it's really only statically linking against wx that we care about in that case. ahp
On May 19, 2005, at 3:46 PM, Raphaël Enrici wrote: > > > Can you try the patch attached on OSX with a fresh checkout (don't > apply the configure.ac I just sent) ? (I need to rebuild wxWid to > generate static libs... it may take a moment). > Your attached patch isn't going to do anything. `wx-config --libs` and `wx-config --libs --static` both return the same thing, unless you have both a static and dynamic version of wx2 in the same tree. For 99% of us, adding the --static flag makes no difference. ahp
Adam H. Pendleton wrote: > On May 19, 2005, at 3:24 PM, Florian G. Pflug wrote: >> Raphaël Enrici wrote: >>> Florian G. Pflug wrote: >>>> Raphaël Enrici wrote: >>>>> I have warning concerning ENABLE_STATIC in configure script. >>>>> Shouldn't >>>>> we also remove it crom configure.ac ? (patch attached). >>>>> >>>> Does this mean the linking statically is not possible anymore? >>>> Or has the check just moved to another place? >>>> >>> To me, as Adam is making the build relying on wx-config flags, the >>> build >>> is considered static if wxWid was built with --disabled-shared passed >>> to its configure. In the case where wxWidgets has been built with >>> --enable-shared, pgadmin will inherit this default and build >>> dynamically >>> (same thing if both shared and static wxWid libs were built, the shared >>> build will become the default...). >>> >> Will a statically-built wx make the _whole_ pgadmin link statically too, >> or will only the wx-libraries be linkes statically and e.g. libpq >> dynamically. It would be the right thing to do, I guess - but then there >> would be need for a global "--enable-static" flag, that defined >> the linking-type for all other libs beside wx. At least for OSX, >> linking the release-versions statically it the most reliable method, >> while keeping the resulting app small. > > I ran into some real problems trying to link the whole app statically, > especially on Linux. There is a flag that can be passed (to ld I > think) that makes all linking static, but IIRC I found that some linux > libraries didn't like that much, and would require dynamic linking. > Besides, in this day and age, there really isn't any reason to > completely statically link, except for debugging purposes, and it's > really only statically linking against wx that we care about in that case. On OSX, you have to include any non-standard (not included in OSX) lib into your application bundle - at least, if you want people to be able to take the ".app", drag it into their applications folder, and run it - which people on OSX expect, since it works that way for 90% of the software (Even for MS-Office ;-) ). The complete-bundle.sh in the pgadmin sources takes care of this - it moves all shared-libs pgadmin3 depends on into the bundle, and patches pgadmin3 to search for them there. This, howevery, causes bloat, because you can't strip a shared library - it always contains all symbols, no matter if your app nees them or not. OTOH, if you link statically, you can strip the resulting binary, and only retain the symbols that you really need. As long as wx is linked statically, howevery, the difference will hopefully by small for pgadmin3 I guess, since libpq is quite slim. But things grow out of hand quickly, if you start linking dynamically against wx - because the libs are _hughe_. I'll now go and test a compile with the new acinclude.m4, and see what happens ;-) greetings, Florian Pflug
Вложения
Adam H. Pendleton wrote: > On May 19, 2005, at 3:46 PM, Raphaël Enrici wrote: > > >> >>Can you try the patch attached on OSX with a fresh checkout (don't >>apply the configure.ac I just sent) ? (I need to rebuild wxWid to >>generate static libs... it may take a moment). >> > > > Your attached patch isn't going to do anything. `wx-config --libs` > and `wx-config --libs --static` both return the same thing, unless > you have both a static and dynamic version of wx2 in the same tree. > For 99% of us, adding the --static flag makes no difference. 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. Regards, Raphaël
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. 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. ahp
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. 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. Does it makes sens? (in case someone for some bad or good reason need a 95% static build) Raphaël
On May 19, 2005, at 4:54 PM, Raphaël Enrici wrote: > 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? Yes. The --static flag is only useful in the case where a user has both a static and dynamic build of wxWidgets in the same tree. > > 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. Yes, your patch would add support for those people with both build types. > 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. There are no references to pg_static_build in acinclude any more. Well, okay there's one, but it doesn't do anything because pg_static_build isn't set anywhere (sans your patch, of course). Your patch is fine, just know that it terms of statically linking pgAdmin3 as a whole it does nothing. It only helps any user with both a dynamic and static wx select the one they want. ahp
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
Вложения
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
Raphaël Enrici wrote: > 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? +1 greetings, Florian Pflug
Вложения
On May 19, 2005, at 5:27 PM, Raphaël Enrici wrote:
To summarize :- we reject the configure.ac.patch which removed ENABLE_STATIC andshould not have been included in trunk yet
- we keep the latest "acinclude_static.patch" which re-add support forpg_static_build=yes + takes care of systems where wxWid installationsare both static & dynamic.
We should add your patch to what is already in the trunk.
ahp
Thanks, patch applied. > -----Original Message----- > From: Raphaël Enrici [mailto:blacknoz@club-internet.fr] > Sent: 19 May 2005 20:46 > To: Florian G. Pflug > Cc: Adam H. Pendleton; Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] New acinclude.m4 > > Florian G. Pflug wrote: > > Raphaël Enrici wrote: > > > >>Florian G. Pflug wrote: > >> > >>>Raphaël Enrici wrote: > >>> > >>>>I have warning concerning ENABLE_STATIC in configure > script. Shouldn't > >>>>we also remove it crom configure.ac ? (patch attached). > >>> > >>> > >>>Does this mean the linking statically is not possible anymore? > >>>Or has the check just moved to another place? > >> > >>To me, as Adam is making the build relying on wx-config > flags, the build > >> is considered static if wxWid was built with > --disabled-shared passed > >>to its configure. In the case where wxWidgets has been built with > >>--enable-shared, pgadmin will inherit this default and > build dynamically > >>(same thing if both shared and static wxWid libs were > built, the shared > >>build will become the default...). > > > > Will a statically-built wx make the _whole_ pgadmin link > statically too, > > or will only the wx-libraries be linkes statically and e.g. libpq > > dynamically. > > To me, second case. wx static the rest of the world dynamic. > > >It would be the right thing to do, I guess - but then there > > would be need for a global "--enable-static" flag, that defined > > the linking-type for all other libs beside wx. At least for OSX, > > linking the release-versions statically it the most reliable method, > > while keeping the resulting app small. > > So, if I'm right we have lost this functionnality. But, > again, I may be > wrong. > > Can you try the patch attached on OSX with a fresh checkout (don't > apply the configure.ac I just sent) ? (I need to rebuild wxWid to > generate static libs... it may take a moment). > > Cheers, > Raphaël > > >>Maybe it would be worth to still being able to force a > static build by > >>passing "--static" to wx-config in our acinclude.m4. > Something like : > >>if we pas --enable-static to our configure, then pass --static to > >>wx-config so that we build statically, if not then don't > pass anything > >>in particular. > > > > Sounds reasonable - additionally --enable-static should > link e.g. libpq > > statically too. > > > > greetings, Florian Pflug > > > > > > ---------------------------(end of > broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to > majordomo@postgresql.org) > > >