[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. 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 acinclude.m4.patch Description: Binary data acinclude.m4 Description: Binary data ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] New acinclude.m4
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] New acinclude.m4
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
Re: [pgadmin-hackers] New acinclude.m4
Dave Page wrote: > > > >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] New acinclude.m4
Yes. Nice catch. On May 19, 2005, at 1:07 PM, Raphaël Enrici wrote: Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Re: [pgadmin-hackers] New acinclude.m4
Message d'origine >Copie à: Dave Page , >De: Adam H.Pendleton <[EMAIL PROTECTED]> >Sujet: Re: [pgadmin-hackers] New acinclude.m4 >Date: Thu, 19 May 2005 13:14:47 -0400 >A: Raphaël Enrici <[EMAIL PROTECTED]> > >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 required for 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: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] 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 > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
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 [EMAIL PROTECTED])
>
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"
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] New acinclude.m4
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] New acinclude.m4
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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] New acinclude.m4
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
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [pgadmin-hackers] New acinclude.m4
Thanks, patch applied. > -Original Message- > From: Raphaël Enrici [mailto:[EMAIL PROTECTED] > 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 > [EMAIL PROTECTED]) > > > ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[SUMMARY] Re: [pgadmin-hackers] New acinclude.m4
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
Re: [SUMMARY] Re: [pgadmin-hackers] New acinclude.m4
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: [SUMMARY] Re: [pgadmin-hackers] New acinclude.m4
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 yetYou mean reject my entire patch? It did much more than just remove ENABLE_STATIC, so it should not be rejected.- 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
Re: [SUMMARY] Re: [pgadmin-hackers] New acinclude.m4
Message d'origine >Copie à: "Florian G. Pflug" <[EMAIL PROTECTED]>, >De: "Adam H.Pendleton" <[EMAIL PROTECTED]> >Sujet: Re: [SUMMARY] Re: [pgadmin-hackers] New acinclude.m4 >Date: Thu, 19 May 2005 17:44:44 -0400 >A: Raphaël Enrici <[EMAIL PROTECTED]> > > >On May 19, 2005, at 5:27 PM, 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 > >You mean reject my entire patch? It did much more than just remove >ENABLE_STATIC, so it should not be rejected. Oh no! Your patch is _really_ fine and it does not remove ENABLE_STATIC from configure.ac! I meant to just reject the first one I sent yesterday evening concerning ENABLE_STATIC removal in configure.ac, not acinclude.m4. >> - 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. > >We should add your patch to what is already in the trunk. So we all agree. Thank you Adam and Florian for this thread, it just reminds me we are alive :-) @Dave, can you apply the last patch I sent named "acinclude_static.patch" concerning acinclude.m4 and ignore my first one concerning the configure.ac? Thanks. (note that if you don't find it, I can repost it). All of this should be done on current trunk keeping Adam's work. Regards, Raphaël ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [SUMMARY] Re: [pgadmin-hackers] New acinclude.m4
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 20 May 2005 08:00 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: Re: [SUMMARY] Re: [pgadmin-hackers] New acinclude.m4 > > > @Dave, can you apply the last patch I sent named > "acinclude_static.patch" concerning acinclude.m4 and ignore > my first one concerning the configure.ac? Thanks. (note that > if you don't find it, I can repost it). All of this should be > done on current trunk keeping Adam's work. Damn, I take one night off and the list goes insane! Yes, I'll apply it later today to trunk and 1_2_0_PATCHES. Following that, can everyone concerned test both versions please? As an aside, you may have noticed that I've been working on /xtra/pgagent/* recently - can you please take a look over the makefiles under there and make sure the look OK (Florian in particular, for obvious reasons)? Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
