> -----Original Message-----
> From: pgadmin-hackers-owner@postgresql.org
> [mailtogadmin-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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

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
>>[mailtogadmin-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


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

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
>>> [mailtogadmin-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


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 majordomo@postgresql.org)

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)
>


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

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 majordomo@postgresql.org so that your
message can get through to the mailing list cleanly