Re: [HACKERS] building libpq.a static library
On Thu, Jul 13, 2017 at 4:58 AM, Craig Ringer wrote: > 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 . This is not possible in our case. The R programming language binaries are installed in the "program files" directory which is only writable by the sys admin. There are over 10.000 contributed packages (including one with postgres drivers) which are installed by the user in the home dir and the package DLL's need to get dynamically loaded at runtime. We have been working with this system for a very long time and static linking external libs to the package DLL is really the only reliable way to prevent DLL problems across Windows versions/configurations > I'm not trying to block support for a static libpq, I just don't see the > point. This is a bit overgeneralized, there are many use cases where static linking is the only feasible way. Most libs support --enable static and many distros ship both static and shared libs and leave it up to user or developer author how to configure their application. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] building libpq.a static library
On Wed, Jul 12, 2017 at 5:11 PM, Tom Lane wrote: > Jeroen Ooms 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. > FWIW, we used to have support for building static libpq, but > we got rid of it a long time ago. OK that's too bad. I agree that shared libs are often preferable but in some environments dynamic linking is simply not possible and you need to static link the library into the application. Most C/C++ libraries do support --enable-static and even for most linux distros the static libs are included with the lib-dev / lib-devel package. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] building libpq.a static library
I maintain static libraries for libpq for the R programming language (we need static linking to ship with the binary packages). Unfortunately currently the standard postgres makefile only generates a shared library for libpq, not a static one. In order to make a static library I always manually edit ./src/interfaces/libpq/Makefile and add a target: libpq.a: $(OBJS) ar rcs $@ $^ And then run 'make libpq.a' in the libpq directory. This works but it's a bit of a pain to maintain. I was wondering if this hack could be merged so that the standard 'configure --enable-static' script would install a static library for libpq alongside the shared one. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
