Re: New acinclude.m4 - Mailing list pgadmin-hackers

From Florian G. Pflug
Subject Re: New acinclude.m4
Date
Msg-id 428CF6CB.7040608@phlo.org
Whole thread Raw
In response to Re: New acinclude.m4  ("Adam H. Pendleton" <fmonkey@fmonkey.net>)
List pgadmin-hackers
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

Attachment

pgadmin-hackers by date:

Previous
From: "Adam H. Pendleton"
Date:
Subject: Re: New acinclude.m4
Next
From: Raphaël Enrici
Date:
Subject: Re: New acinclude.m4