Re: postgres.h

From: Frank Seesink <frank(at)mail(dot)wvnet(dot)edu>
To: pgsql-cygwin(at)postgresql(dot)org
Subject: Re: postgres.h
Date: 2003-11-05 00:12:52
Message-ID: bo9fa5$12c$1@sea.gmane.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-cygwin

Nupur,

No, you didn't do anything wrong. The problem is that you have stumbled
into one of the areas where compiling/developing under Cygwin is
different than most forms of *nix. You may find the following
information helpful in general (taken from a README I wrote up for the
Cygwin version of Jabberd v1.4.3 recently; apologies for being lazy):

______________________________________________________________________
COMMENTS ABOUT BUILDING *NIX APPS UNDER CYGWIN

With the modifications made since Jabberd v1.4.2, you should now be able
to build Jabberd under Cygwin just as you would under *nix, with a few
exceptions. For those interested, note that building *nix applications
under Cygwin tends to run into problems in the following areas:

* dynamic libraries
* DNS (Domain Name System) resolution/functionality
* the use of fork()

Unfortunately, Jabberd touches on ALL of these capabilities to some
extent.

Dynamic libraries are an OS-specific feature, requiring the OS to play
its role in loading/unloading libraries. In *nix, dynamic libraries
have filenames ending in .so, whereas in Windows they end in .dll. This
is more cosmetic in nature, but it requires changing all modules such as
JUD or MU-Conference so that their filenames end in .dll (see setup.sh).

More importantly, however, is the fact that *nix and Windows compile
their libraries differently, and in order to make a *nix library
build/work under Cygwin, it requires using certain Cygwin tools to build
a list of EXPORTed functions/variables and then building the libraries
as Windows would expect. See the various Makefiles for details on the
commands used under Cygwin vs. typical *nix builds. Basically it
involves building an EXPORT list via 'nm' and then building the libary
using 'dllwrap'.

DNS is another area where compiling *nix apps under Cygwin falls down
hard. In *nix, you can expect to find BIND (Berkeley Internet Name
Domain) or something like it. This provides you not only with a DNS
server, but also as a programmer with all the functions you might
need for DNS resolution, via libraries like libresolv
(/usr/lib/libresolv.a) and their matching header files like
/usr/include/resolv.h, /usr/include/arpa/nameser.h, etc.

Unfortunately, BIND does not build cleanly under Cygwin (so far one can
only Google for hacks), and there is no BIND package available via
Cygwin's setup.exe. This means that as a programmer, you do not get the
header files or necessary libraries for doing DNS functions. Since
Jabberd does DNS resolution for its 'dialback' feature, this required a
rewrite of that portion of Jabberd for Cygwin. This is the ugliest part
of the Cygwin build, as you will find setup.sh simply overwrites the
standard ./dnsrv subdirectory with the Cygwin-specific version. Thanks
go to whoever did this rewrite, however, as it does work.

Recently I found a handy utility called 'minires' (v0.9.7 as I write
this) which implements the more common BIND libresolv functions,
allowing you to build against it as if you had libresolv.
Unfortunately, in my tests, compilation and linking against minires went
fine, but attempts to run the DNSRV portion (dnsrv.dll) of Jabberd blew
up, kicking up rather nasty errors. Though it did not die, it did not
do DNS resolution either. So for now, we'll stick to the rewrite from
Jabberd v1.4.2.

Finally, fork(). Cygwin is fork()ing hell (pun intended) compared to a
proper *nix environment. Applications which use fork() either directly
or indirectly--as Jabberd does since it uses GNU Pth, which in turn uses
fork()--often have difficulty under Cygwin. As mentioned above, when
attempting to run a version of Jabberd compiled against minires
(basically attempting to build Jabberd under Cygwin as you would do
under *nix), I ran into trouble. The trouble involved fork(). I do not
have a resolution at this time.
______________________________________________________________________

Basically, you cannot use .so files under Cygwin. Dynamic Link
Libraries, or DLLs, in Windows end with .DLL, and the way in which they
are built is different than under *nix.

In most cases you CAN take *nix type source code and, by modifying the
Makefile, compile yourself a .DLL file that will work under Windows. I
would suggest doing a

$ man nm
$ dllwrap --help
$ man dlltool

to learn more. Yes it's a pain, but it can be done. I would give you a
modified version of your Makefile here if it were that simple, but there
are too many assumptions I would have to make, and compiling a .so file
as a .dll requires both a modified Makefile and a wrapper/stub file, an
example of which can be had here (taken from Jabberd project):

http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/*checkout*/jabberd14/cygwin/dllinit.c?rev=1.1&content-type=text/plain

To give you at least some direction in this, look at the following
Makefile (again taken from Jabberd project) for a basic idea of what's
involved:

http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/jabberd14/dialback/Makefile?rev=1.5&content-type=text/vnd.viewcvs-markup

Ignore the actual filenames and just note the general structure. Note
the line at the top "include ../platform-settings" refers to including a
simple shell script file containing compiler flags and such, including
one line that reads "__CYGWIN__=1", which is what the conditionals in
the above Makefile look for to see if you're running under Cygwin. This
platform-settings file was generated by a ./configure script provided
with Jabberd, available here:

http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/jabberd14/configure?rev=1.43&content-type=text/vnd.viewcvs-markup

I realize that saying "Go look at this other code" isn't the prettiest
way to learn, but hopefully it will be of use to you. Best of luck to you.

______________________________________________________________________
DISCLAIMER: I am not a professional coder (i.e., "sitting at desk,
coding for my paycheck"), nor do I play one on TV. So if any of the
above is a little off, an apology is the best I can offer.

Nupur Pande wrote:

> Thanks a lot.. that did work.
> One last question (hopefully)
> I'm trying to create a .so file. My makefile looks like this:
>
> all: RuleFinder.so
>
> RuleFinder.so: RuleFinder.o
> gcc -shared -o RuleFinder.so RuleFinder.o
>
> RuleFinder.o: <files>
> gcc -I /usr/include/postgresql/server -fpic -c RuleFinder.c
>
> When I run make, the .o file gets created but not the .so. I get the
> following errors:
>
> gcc -I /usr/include/postgresql/server -fpic -c RuleFinder.c
> cc1: warning: -fpic ignored for target (all code is position independent)
> gcc -shared -o RuleFinder.so RuleFinder.o
> RuleFinder.o(.text+0x16c1):RuleFinder.c: undefined reference to `_SPI_exec'
> RuleFinder.o(.text+0x1cf2):RuleFinder.c: undefined reference to
> `_pg_detoast_datum'
> RuleFinder.o(.text+0x1d06):RuleFinder.c: undefined reference to
> `_pg_detoast_datum'
> RuleFinder.o(.text+0x2152):RuleFinder.c: undefined reference to
> `_GetAttributeByName'
> RuleFinder.o(.text+0x2438):RuleFinder.c: undefined reference to
> `_GetAttributeByName'
>
> Did I do something wrong?
>
> Thanks,
> Nupur
*snip*

In response to

Responses

Browse pgsql-cygwin by date

  From Date Subject
Next Message Emanuele 2003-11-05 08:39:29 Re: Problems with InitDB
Previous Message Nupur Pande 2003-11-04 18:28:06 Re: postgres.h