Re: 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