Thread: Problem Building Cygwin PostgreSQL
I am attempting to build PostgreSQL 7.0.2 on a stock Cygwin 1.1.4
distribution. When building plpgsql.dll, I get the following error:
dllwrap -o plpgsql.dll --dllname plpgsql.dll --def plpgsql.def \
pl_parse.o pl_han dler.o pl_comp.o pl_exec.o pl_funcs.o \
../../../utils/dllinit.o -L/usr/local/lib -L/usr/local/lib \
-L../../../backend -lpostgres -lcygipc -lcygwin -lcrypt -lkernel32
pl_exec.o(.text+0x1e56):pl_exec.c: undefined reference to `fmgr_pl_finfo'
pl_exec.o(.text+0x32a1):pl_exec.c: undefined reference to `fmgr_pl_finfo'
pl_exec.o(.text+0x32bd):pl_exec.c: undefined reference to `fmgr_pl_finfo'
collect2: ld returned 1 exit status
Searching the Net, I found the following on the pgsql-ports list:
http://www.postgresql.org/mhonarc/pgsql-ports/2000-08/msg00045.html
which demonstrates that at least one other person had exactly the same
problem. Unfortunately, the solution given was not applicable.
Has anyone been successful building a Cygwin PostgreSQL 7.0.2? If so,
what is the solution to the above problem?
Thanks,
Jason
--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Volker, On Thu, Sep 21, 2000 at 06:49:22PM +0200, Dr. Volker Zell wrote: > I have the same problem. Anyway postmaster -i works perfect and the > database system starts up fine. Thanks for the heads up -- with my very limited testing my Cygwin PostgreSQL build seems to be working correctly. > But using psql always results in a > stacktrace. Can you check if you get the same behaviour. So far (meaning working through some of the tutorial) psql works without stackdumping. However, it does stackdump whenever I execute 'psql --help'. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Volker,
On Thu, Sep 21, 2000 at 05:02:11PM -0400, Jason Tishler wrote:
> However, it does stackdump whenever I execute 'psql --help'.
The above was caused by the following in src/bin/psql/help.c:
void
usage(void)
{
...
#ifndef WIN32
if (pw)
free(pw);
#endif
}
Changing the above #ifndef to:
#if !defined(WIN32) && !defined(__CYGWIN__)
fixed this niggling crash.
Jason
--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Earnie,
On Fri, Sep 22, 2000 at 11:01:25AM -0700, Earnie Boyd wrote:
> Hmm... This appears that it would potentially cause a memory leak. What
> happens if instead of this patch you initialize the pointer to NULL?
I guess that I should have giving more context:
void
usage(void)
{
...
user = getenv("USER");
if (!user)
{
#ifndef WIN32
pw = getpwuid(geteuid());
if (pw)
user = pw->pw_name;
...
#else
user = "?";
#endif
}
...
#if !defined(WIN32) && !defined(__CYGWIN__)
if (pw)
free(pw);
#endif
}
The relevant Cygwin source (i.e., src/winsup/cygwin/passwd.cc) and the
getpwuid() man page (from Solaris):
The functions getpwnam(), getpwuid(), getpwent(), and
fgetpwent() use *static* storage that is re-used in each call,
making these routines unsafe for use in multithreaded appli-
cations.
seemed to indicate that free-ing the return value from getpwuid() was a
bad idea. Can someone confirm or refute this supposition?
Thanks,
Jason
--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
On Thu, Sep 21, 2000 at 11:55:38AM -0400, Jason Tishler wrote:
> I am attempting to build PostgreSQL 7.0.2 on a stock Cygwin 1.1.4
> distribution. When building plpgsql.dll, I get the following error:
>
> dllwrap -o plpgsql.dll --dllname plpgsql.dll --def plpgsql.def \
> pl_parse.o pl_han dler.o pl_comp.o pl_exec.o pl_funcs.o \
> ../../../utils/dllinit.o -L/usr/local/lib -L/usr/local/lib \
> -L../../../backend -lpostgres -lcygipc -lcygwin -lcrypt -lkernel32
> pl_exec.o(.text+0x1e56):pl_exec.c: undefined reference to `fmgr_pl_finfo'
> pl_exec.o(.text+0x32a1):pl_exec.c: undefined reference to `fmgr_pl_finfo'
> pl_exec.o(.text+0x32bd):pl_exec.c: undefined reference to `fmgr_pl_finfo'
> collect2: ld returned 1 exit status
After much head banging and web surfing, I finally fixed the plpgsql.dll
build problem. I was pointed in the right direction by Joost Kraaijeveld.
The solution was to change Gen_fmgrtab.sh.in, which generates fmgr.h,
as follows:
diff Gen_fmgrtab.sh.in.orig Gen_fmgrtab.sh.in
139c139,144
< extern FmgrInfo *fmgr_pl_finfo;
---
> #ifdef BUILDING_DLL
> #define DLL_INTERFACE __declspec(dllexport)
> #else
> #define DLL_INTERFACE __declspec(dllimport)
> #endif
> extern DLL_INTERFACE FmgrInfo *fmgr_pl_finfo;
fmgr_pl_finfo is data and not a function, so I guess that it needs to be
explicitly imported/exported via __declspec(dllimport)/__declspec(dllexport),
respectively.
Does anyone know whether or not older Cygwin versions of binutils
automatically exported data items?
Thanks,
Jason
--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
On Thu, Sep 21, 2000 at 06:49:22PM +0200, Dr. Volker Zell wrote: > But using psql always results in a stacktrace. FYI, I have determined that Volker's psql crashes were due to the linking with multiple instances of libcygwin.a problem. It was libm.a in this case. Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Looks like this is fixed in current sources.
> Earnie,
>
> On Fri, Sep 22, 2000 at 11:01:25AM -0700, Earnie Boyd wrote:
> > Hmm... This appears that it would potentially cause a memory leak. What
> > happens if instead of this patch you initialize the pointer to NULL?
>
> I guess that I should have giving more context:
>
> void
> usage(void)
> {
> ...
> user = getenv("USER");
> if (!user)
> {
> #ifndef WIN32
> pw = getpwuid(geteuid());
> if (pw)
> user = pw->pw_name;
> ...
> #else
> user = "?";
> #endif
> }
> ...
> #if !defined(WIN32) && !defined(__CYGWIN__)
> if (pw)
> free(pw);
> #endif
> }
>
> The relevant Cygwin source (i.e., src/winsup/cygwin/passwd.cc) and the
> getpwuid() man page (from Solaris):
>
> The functions getpwnam(), getpwuid(), getpwent(), and
> fgetpwent() use *static* storage that is re-used in each call,
> making these routines unsafe for use in multithreaded appli-
> cations.
>
> seemed to indicate that free-ing the return value from getpwuid() was a
> bad idea. Can someone confirm or refute this supposition?
>
> Thanks,
> Jason
>
> --
> Jason Tishler
> Director, Software Engineering Phone: +1 (732) 264-8770 x235
> Dot Hill Systems Corporation Fax: +1 (732) 264-8798
> 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
> Hazlet, NJ 07730 USA WWW: http://www.dothill.com
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026