Re: static or dynamic libpgport

On 12/12/2011 02:59 PM, Tom Lane wrote:
> Peter Eisentraut<peter_e(at)gmx(dot)net> writes:
>> On lör, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
>>> Right now, libpq laboriously rebuilds all the .o files it needs from
>>> src/port/ so as to get them with -fpic. It would be nice if we could
>>> clean that up while we're doing this. It might be all right to always
>>> build the client-side version of libpgport with -fpic, though I'd be sad
>>> if that leaked into the server-side build.
>> So would we continue to build the client binaries (psql, pg_dump, etc.)
>> against the static libpgport.a, thus keeping it "invisible" there, or
>> would we dynamically link them, thus creating a new dependency.
> I think that if possible we should avoid creating a new dependency for
> either the client binaries or libpq.so itself; what I suggest above
> is only a simplification of the build process for libpq. If we create
> a new dependency we risk packagers breaking things by forgetting to
> include it.
>
> The Fedora/RHEL rule against static libraries is meant to prevent
> situations where changes in a library would require rebuilding other
> packages to get the fixes in place. If we had to make a quick security
> fix in libpq, for example, it would suck if dozens of other packages had
> to be rebuilt to propagate the change everywhere. However, I don't think
> that concern applies to programs that are in the same source package as
> the library --- they'd get rebuilt anyway. So I see nothing wrong with
> continuing to statically link these .o files into files belonging to the
> postgresql package. It's just that I can't export them in a .a file for
> *other* source packages to use.
>
> (Whether a security issue in libpgport is really likely to happen is not
> a question that this policy concerns itself with ...)
>
>

OK, my possibly naïve approach is shown in the attached. Essentially it
builds libpgport-shared.so and then installs it as libpgport.so. That
ensures that the library is not used in building any postgres binaries
or libraries. Places such as libpq that formerly symlinked and
recompiled the sources in a way that is suitable for a shared library
now just link in the already built object files.

Is there a better way to do this?

cheers

andrew