Re: building and linking C user defined functions

[Jean-Marc EBER <jeanmarc(dot)eber(at)lexifi(dot)com>]

Bruce,

Thanks for this quick answer.
I will have to look more precisely at the minGW build env/stuff.

jm


Bruce Momjian wrote:
> I think I can answer this.  The symbols it is complaining about are
> backend symbols.  They would never be in libpq.
>
> As far as backend functions, because Visual C doesn't compile the
> backend code, I don't think it can be used for backend functions.  My
> guess is that you are going to have to use the MinGW build environment
> for such cases.
>
> Now, on your specific case below, I _think_ the problem is that a DLL
> requires some resolution of symbols that would normally appear in the
> backend, while a Unix shared library can have those symbols totally
> unresolved until dynamic link time.  Again, that is just a guess. 
> Perhaps there is some link switch which will give you that behavior on
> Visual C.
>
> On your last point, when creating a shared library on Unix, you don't
> normally use any of the backend object files.  What happens is that the
> backend dynamically links in the object file and resolves all symbols at
> runtime.  Since you have done this on Unix already you should already
> know that though.
>
> One trick would be to look at the shared objects created by MinGW like
> libplpgsql.so and see how those are created and try to duplicate the
> process in Visual C.  MinGW uses gcc and I wonder if it is creating some
> special file format that it can dynamically link but Visual C can't.
>
> The short answer is that I think you are going to need to use MinGW to
> do what you want at this point.  You will find MinGW much closer to
> Win32 native that Cygwin because it doesn't have any compatibility layer
> in the runtime files.
>
> ---------------------------------------------------------------------------
>
> Jean-Marc EBER wrote:
>
> > Hi all,
> >
> > As I learned that a native win32 version of PG would be available soon, I began 
> > to look seriously at it (win32 support is necessary in our business). We began 
> > with a 7.xx standard version under Linux. After a few days of learing and 
> > documenting, we were able to create our own types, add user defined functions 
> > written in C and returning sets etc. Worked very well and nicely. Fine (and 
> > thanks to the Postgresql team!).
> >
> > Now I tried to port this stuff to the win32 native version, building a dll that 
> > can be dynamically loaded by PG at run-time.
> >
> > Our steps:
> >
> > 1.	Download the self extracting binaries and install them. No major problems 
> > encountered.
> > 2.	Download the cvs 8.0beta3 snapshoot and build the native libpq.lib, libpq.dll 
> > with nmake etc. Seemed to work well.
> > 3.	Try to link our code for building a dll. Here the problem begins:
> >
> > -----------------------------------------------------------
> > link /nologo /dll /libpath:"c:\Program Files\mlfi\lib" \
> >           /libpath:"C:\postgresql\postgresql-snapshot\src\interfaces\libpq\Relea
> > se" \
> >           /libpath:"c:\program files\Microsoft Visual Studio\VC98\Lib" \
> >           /out:libudfs_wrapper.dll \
> >   libpq.lib udfs.obj udfs_wrapper.obj postgresql/pg_wrapper.obj \
> >   libcamlrun.lib
> > pg_wrapper.obj : error LNK2001: unresolved external symbol _MemoryContextAlloc
> > pg_wrapper.obj : error LNK2001: unresolved external symbol __imp__CurrentMemoryC
> > ontext
> > pg_wrapper.obj : error LNK2001: unresolved external symbol _Float8GetDatum
> > pg_wrapper.obj : error LNK2001: unresolved external symbol _pg_detoast_datum
> > pg_wrapper.obj : error LNK2001: unresolved external symbol _end_MultiFuncCall
> > pg_wrapper.obj : error LNK2001: unresolved external symbol _per_MultiFuncCall
> > pg_wrapper.obj : error LNK2001: unresolved external symbol _MemoryContextSwitchT
> > o
> > pg_wrapper.obj : error LNK2001: unresolved external symbol _init_MultiFuncCall
> > libudfs_wrapper.dll : fatal error LNK1120: 8 unresolved externals
> > make: *** [libudfs_wrapper.dll] Error 96
> >
> > -----------------------------------------------------------
> >
> > If I understand well, libpq is a library for building PG clients, but doesn?t 
> > contain "enough" functions to build "udf dlls".
> >
> > So my question:
> >
> > What is (or will be) the "official" way to achieve this goal for the win32 version ?
> >
> > Did anybody achieve to build such a dll with native VC++ only (probably by 
> > achieving to compile the transitive closure of what is needed in backend/utils) ?
> >
> > Or is one supposed to build such a dll through the "cygwin way" ? This would 
> > mean that one is taking a mingw or cygwin compiled PG (that should contain all 
> > needed object files and library files as .a and .o files), compile and link the 
> > own C udfs against these files for producing a dll ? Would such a dll be 
> > compatible with the native win32 binary version ?
> >
> > Jean-Marc Eber
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster