Re: [HACKERS] building libpq.a static library
| От | Craig Ringer |
|---|---|
| Тема | Re: [HACKERS] building libpq.a static library |
| Дата | |
| Msg-id | CAMsr+YF5TLP=g483wku4Z--9TvwMdGXkVbUVA-8hiXgRxELQqw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] building libpq.a static library (Jeroen Ooms <jeroen@berkeley.edu>) |
| Ответы |
Re: [HACKERS] building libpq.a static library
Re: [HACKERS] building libpq.a static library |
| Список | pgsql-hackers |
On 12 July 2017 at 23:46, Jeroen Ooms <jeroen@berkeley.edu> wrote:
On Wed, Jul 12, 2017 at 5:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeroen Ooms <jeroen@berkeley.edu> writes:
>> I maintain static libraries for libpq for the R programming language
>> (we need static linking to ship with the binary packages).
>
> How do you get that past vendor packaging policies? When I worked at
> Red Hat, there was a very strong policy against allowing any package
> to statically embed parts of another one, because it creates serious
> management problems if e.g. the other one needs a security update.
> I'm sure Red Hat isn't the only distro that feels that way.
We only use this on Windows. On platforms with a decent package
manager we indeed link to a shared library.
You shouldn't ever need static libraries on Windows, though. Because it searches the CWD first on its linker search path, you can just drop libpq.dll in the same directory as your binary/library and link to the stub libpq.lib .
On Mac OS X and Linux, you can use relative rpath linking. On OS X use @executable_path either at link-time or later via install_name_tool . On Linux, use $ORIGIN in your rpath. Beware of quoting issues with $ORIGIN though.
I'm not trying to block support for a static libpq, I just don't see the point.
В списке pgsql-hackers по дате отправления: