Re: [HACKERS] Shared library conflicts
That's good news. Any chance of getting this fix backported to 8.1? Or at least, the libz part of it? Regards, Thomas Hallgren Martijn van Oosterhout wrote: On Fri, Jun 23, 2006 at 10:45:29AM +0200, Thomas Hallgren wrote: There was a discussion some time back concerning the linking of the postgres backend. Some libraries where linked although they where not needed, mainly because it was convenient. AIUI, this was fixed in -HEAD. In the Makefile there's a filter command to strip libraries not needed. One of them is libz. From src/backend/Makefile: # The backend doesn't need everything that's in LIBS, however LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses -lcurses, $(LIBS)) Have a nice day, ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Shared library conflicts
On Fri, Jun 23, 2006 at 10:45:29AM +0200, Thomas Hallgren wrote: > There was a discussion some time back concerning the linking of the > postgres backend. Some libraries where linked although they where not > needed, mainly because it was convenient. AIUI, this was fixed in -HEAD. In the Makefile there's a filter command to strip libraries not needed. One of them is libz. From src/backend/Makefile: # The backend doesn't need everything that's in LIBS, however LIBS := $(filter-out -lz -lreadline -ledit -ltermcap -lncurses -lcurses, $(LIBS)) Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] Shared library conflicts
"Thomas Hallgren" <[EMAIL PROTECTED]> > > Another related question. What happens when I use --without-zlib? Does it > have any effect on besides disabling compression for the dump/restore > utilities? Is there anyway to make it affect the backend only? --without-zlib will affected LIBS and HAVE_LIBZ defined in configure. I searched HAVE_LIBZ in the source code, and find only pg_dump use it. I think we can change LIBS to not include "-lz" in configure, and add "-lz" for pg_dump in its Makefile. With regards, William ZHANG > > Kind Regards, > Thomas Hallgren > > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Shared library conflicts
There was a discussion some time back concerning the linking of the postgres backend. Some libraries where linked although they where not needed, mainly because it was convenient. I had a problem with PL/Java since a Sun JVM ships with their own version of libz.so (they call it libzip.so). Sun fixed the problem, simply by adding a namespace to all functions in their own library so I didn't stress the issue any further. Now this bites me again. Sun forgot to remove the old functions in their libzip.so on the amd64 platform. I have of course reported this to Sun and I expect it to be fixed in future releases of Java but shouldn't this be fixed for PostgreSQL too? Perhaps we should consider this a more generic problem. The more libraries that are linked with the backend, the greater the risk that add-on modules will run into conflicts. What effort would be involved to fix this once and for all? Another related question. What happens when I use --without-zlib? Does it have any effect on besides disabling compression for the dump/restore utilities? Is there anyway to make it affect the backend only? Kind Regards, Thomas Hallgren ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
