2010/3/10 Dag-Erling Smørgrav <des@des.no>:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> "Dag-Erling Smørgrav" <des@des.no> writes:
>> > 1. PostgreSQL's private versions of inet_aton etc. can conflict with
>> > similar functions in other libraries (in my case, PostgreSQL's
>> > inet_aton conflicts with libavformat's).
>> So what? We don't link with those libraries.
>
> Your users might need to link with both. I'm working on an application
> that generates animations (specifically, animated weather forecasts)
> based on data retrieved from a PostgreSQL database.
This shows up only with static links of libpq, correct? Or are you
building a backend function?
>> The proposed #defines seem like a completely bad idea, especially
>> since as-presented they would affect every platform not only yours.
>
> Yes. That's the idea. This is a common idiom - the canonical way, if
> you will, of solving this problem, which is not exclusive to PostgreSQL.
> There are even cases in which you have no other choice, e.g. when the
> function you want to use is available but does not work properly or does
> not implement a particular feature that you need.
>
>> We don't need the maintenance/debugging headaches of routines that
>> don't have the names they appear to have.
>
> Honestly, I don't see the problem.
>
>> > ifeq ($(PORTNAME),win32)
>> > -LIBS += -lws2_32 -lshfolder
>> > +LIBS += -lws2_32 -lshfolder -lsecur32
>> > endif
>> Surely this bit would need to be conditional on whether libsecur32
>> is available?
>
> It's just as much part of Win32 as ws2_32 (winsock).
Yeah, it's a standard win32 library so that's not a problem.
But the fix seems wrong. If you are using a static libpq, the library
should be added whenever you link that library into your client
application. Not for every single EXE and DLL that postgres produces.
The makefiles already add it to the places in PostgreSQL where it's
needed - namely postgres.exe and libpq.dll.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/