Thread: Cygwin PostgreSQL CVS build issues
I'm in the process of creating some patches to fix the Cygwin specific build issues mentioned in the following post: http://archives.postgresql.org/pgsql-cygwin/2003-04/msg00053.php I was able to resolve all problems except for the following: 1. src/include/port/win32defs.h does not seem to be in CVS yet. 2. ecpg_compat_mode is declared in src/interfaces/ecpg/ecpglib/connect.c but does not seem to be defined yet. Also, I would like to know whether or not the following is an acceptable way to get ecpg.dll linked against libpgtypes.a: +++ interfaces/ecpg/ecpglib/Makefile 2003/04/29 17:40:25 @@ -22,6 +22,9 @@ OBJS= execute.o typename.o descriptor.o connect.o misc.o SHLIB_LINK= $(libpq) +ifeq ($(PORTNAME), cygwin) +SHLIB_LINK+= -L../pgtypeslib -lpgtypes +endif If not, what is the recommended approach? Any help with the above will be greatly appreciated. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Jason Tishler wrote: > I'm in the process of creating some patches to fix the Cygwin specific > build issues mentioned in the following post: > > http://archives.postgresql.org/pgsql-cygwin/2003-04/msg00053.php > > I was able to resolve all problems except for the following: > > 1. src/include/port/win32defs.h does not seem to be in CVS yet. Requirement removed. That file isn't needed anymore. > 2. ecpg_compat_mode is declared in > src/interfaces/ecpg/ecpglib/connect.c but does not seem to be > defined yet. > > Also, I would like to know whether or not the following is an acceptable > way to get ecpg.dll linked against libpgtypes.a: > > +++ interfaces/ecpg/ecpglib/Makefile 2003/04/29 17:40:25 > @@ -22,6 +22,9 @@ OBJS= execute.o typename.o descriptor.o > connect.o misc.o > > SHLIB_LINK= $(libpq) > +ifeq ($(PORTNAME), cygwin) > +SHLIB_LINK+= -L../pgtypeslib -lpgtypes > +endif > > If not, what is the recommended approach? Michael Meskes will have to answer these. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Jason Tishler <jason@tishler.net> writes:
> Also, I would like to know whether or not the following is an acceptable
> way to get ecpg.dll linked against libpgtypes.a:
> +++ interfaces/ecpg/ecpglib/Makefile 2003/04/29 17:40:25
> @@ -22,6 +22,9 @@ OBJS= execute.o typename.o descriptor.o
> connect.o misc.o
> SHLIB_LINK= $(libpq)
> +ifeq ($(PORTNAME), cygwin)
> +SHLIB_LINK+= -L../pgtypeslib -lpgtypes
> +endif
Why would Cygwin need that if other platforms don't? (Perhaps other
platforms do too? I've never tried to actually run ecpg ...)
regards, tom lane
Tom, On Tue, Apr 29, 2003 at 03:36:34PM -0400, Tom Lane wrote: > Jason Tishler <jason@tishler.net> writes: > > Also, I would like to know whether or not the following is an > > acceptable way to get ecpg.dll linked against libpgtypes.a: > > > > [snip] > > Why would Cygwin need that if other platforms don't? Why? Because Cygwin is Windows after all... :,) DLLs, unlike shared libraries under Unix, need all symbols resolved at link as opposed to load time. AFAICT, this is why constructs like BE_DLLLIBS are part of PostgreSQL's makefiles. > (Perhaps other platforms do too? ...) I don't know. Are their other platforms with "shared" libraries that have the same link time requirement as Windows? Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Bruce, On Tue, Apr 29, 2003 at 02:26:39PM -0400, Bruce Momjian wrote: > Jason Tishler wrote: > > I was able to resolve all problems except for the following: > > > > 1. src/include/port/win32defs.h does not seem to be in CVS yet. > > Requirement removed. That file isn't needed anymore. Should one of my forthcoming patches remove the above mentioned #include? Or, will you take care of this? Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
On Tue, Apr 29, 2003 at 04:23:37PM -0400, Jason Tishler wrote: > Why? Because Cygwin is Windows after all... :,) > > DLLs, unlike shared libraries under Unix, need all symbols resolved at > link as opposed to load time. AFAICT, this is why constructs like > BE_DLLLIBS are part of PostgreSQL's makefiles. That's not true at all. You can just as well dynamicly load dll's in windows. Maybe it's just that cygwin doesn't do it. Kurt
Jason Tishler wrote: > Bruce, > > On Tue, Apr 29, 2003 at 02:26:39PM -0400, Bruce Momjian wrote: > > Jason Tishler wrote: > > > I was able to resolve all problems except for the following: > > > > > > 1. src/include/port/win32defs.h does not seem to be in CVS yet. > > > > Requirement removed. That file isn't needed anymore. > > Should one of my forthcoming patches remove the above mentioned > #include? Or, will you take care of this? I can handle it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> > Also, I would like to know whether or not the following is an acceptable > > way to get ecpg.dll linked against libpgtypes.a: > > > > +++ interfaces/ecpg/ecpglib/Makefile 2003/04/29 17:40:25 > > @@ -22,6 +22,9 @@ OBJS= execute.o typename.o descriptor.o > > connect.o misc.o > > > > SHLIB_LINK= $(libpq) > > +ifeq ($(PORTNAME), cygwin) > > +SHLIB_LINK+= -L../pgtypeslib -lpgtypes > > +endif > > > > If not, what is the recommended approach? I think AIX will need this too. Anyway I can't check it, since the snapshots are not produced anymore (last is from 24.3.) (Marc ?) :-( (I am behind a firewall here, no reliable socks proxy available) Andreas
Kurt, On Tue, Apr 29, 2003 at 10:42:35PM +0200, Kurt Roeckx wrote: > On Tue, Apr 29, 2003 at 04:23:37PM -0400, Jason Tishler wrote: > > Why? Because Cygwin is Windows after all... :,) > > > > DLLs, unlike shared libraries under Unix, need all symbols resolved > > at link as opposed to load time. AFAICT, this is why constructs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **************************** > > like BE_DLLLIBS are part of PostgreSQL's makefiles. > > That's not true at all. Unfortunately, it is. Otherwise, porting Unix software with shared library components to Cygwin would be much easier. > You can just as well dynamicly load dll's in windows. Of course, but this fact is irrelevant to the discussion. See below... > Maybe it's just that cygwin doesn't do it. No, Cygwin has dlopen() and friends. It appears that you did not read my previous post carefully or you misunderstood it -- in particular the phrase marked by asterisks above. By "link" and "load" time, I meant build and run time, respectively. This is a build issue (as indicated by the subject) and has nothing to do with dynamically loading DLLs at run time. A Windows DLL must have *all* symbols resolved at link (i.e., build) time. Otherwise, the link with fail. Unfortunately, this is a basic Windows DLL requirement. Since ecpg.dll is dependent on pgtypes.dll, it must be linked against libpgtypes.a (i.e., the corresponding import library). Otherwise, the link will fail with errors like to following: dllwrap -o ecpg.dll --dllname ecpg.dll --def ecpg.def execute.o ... execute.o(...):execute.c: undefined reference to`_PGTYPESnumeric_to_asc' execute.o(...):execute.c: undefined reference to `_PGTYPESnumeric_to_asc' execute.o(...):execute.c:undefined reference to `_PGTYPESdate_to_asc' ... Additionally, PostgreSQL is already linking against libpostgres.a (i.e, the import library for postgres.exe) under Cygwin in many places: $ find . -type f | xargs fgrep BE_DLLLIBS ./backend/utils/mb/conversion_procs/proc.mk:SHLIB_LINK := $(BE_DLLLIBS) ./makefiles/Makefile.cygwin:BE_DLLLIBS= -L$(top_builddir)/src/backend -lpostgres ./makefiles/Makefile.win:BE_DLLLIBS=-L$(top_builddir)/src/backend -lpostgres ./pl/plperl/GNUmakefile:SHLIB_LINK = $(perl_embed_ldflags)$(BE_DLLLIBS) ./pl/plpgsql/src/Makefile:SHLIB_LINK = $(BE_DLLLIBS) ./pl/plpython/Makefile:SHLIB_LINK= $(BE_DLLLIBS) $(python_libspec) ./test/regress/GNUmakefile:SHLIB_LINK = $(BE_DLLLIBS) ./tutorial/Makefile:SHLIB_LINK = $(BE_DLLLIBS) Hence, the need to link with the necessary import libraries under Cygwin is very real and cannot be avoided. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> I think AIX will need this too. Anyway I can't check it, since
> the snapshots are not produced anymore (last is from 24.3.) (Marc ?) :-(
That's fixed as of last night (thanks Marc) --- seems cvs.postgresql.org
had an old bison and so the build was failing.
regards, tom lane
This seems an old topic to the list,
but it's one of the confusing area for
postgresql users -
example table:
1. about "like" and "similar to" operators
postgresql can't use index if your database
encoding is anything other than 'C'. After I did
this, I knew this will not take care of
'%pattern%' map, which requires the text search module.
question 1: query uses the index, why the performance is still bad?
emrxdbs=# explain analyze select * from patient where lastname like 'BEC%';
QUERY PLAN
----------------------------------------------------------------------------
--------------------------Index Scan using patient_lname_idx on patient (cost=0.00..251.65 rows=62
width=176) (actual time=63.48..8860.14 rows=1732 loops=1) Index Cond: ((lastname >= 'BEC'::character varying) AND
(lastname<
'BED'::character varying)) Filter: (lastname ~~ 'BEC%'::text)Total runtime: 8870.27 msec
emrxdbs=# explain analyze select * from patient where firstname like
'RAN%'; QUERY PLAN
----------------------------------------------------------------------------
--------------------------Index Scan using patient_fname_idx on patient (cost=0.00..18.25 rows=4
width=176) (actual time=39.84..12515.44 rows=2649 loops=1) Index Cond: ((firstname >= 'RAN'::character varying) AND
(firstname<
'RAO'::character varying)) Filter: (firstname ~~ 'RAN%'::text)Total runtime: 12532.38 msec
question 2: why "not like" is not using index?
emrxdbs=# explain analyze select * from patient where firstname not like
'MAR%'; QUERY PLAN
----------------------------------------------------------------------------
---------------------------------------Seq Scan on patient (cost=0.00..20102.05 rows=745897 width=176) (actual
time=0.09..76515.69 rows=717610 loops=1) Filter: (firstname !~~ 'MAR%'::text)Total runtime: 81983.46 msec
(3 rows)
2. about POSIX Regular Expressions, it doesn't use index at all?!
emrxdbs=# explain analyze select * from patient where firstname ~ 'RAN%';
QUERY PLAN
----------------------------------------------------------------------------
------------------------------------Seq Scan on patient (cost=0.00..20102.05 rows=5985 width=176) (actual
time=25040.93..25040.93 rows=0 loops=1) Filter: (firstname ~ 'RAN%'::text)Total runtime: 25041.23 msec
(3 rows)
3. what's the general guidelines in terms of simple pattern
match in postgresql (not the text search module)?
Can someone help to clear the above questions?
thanks.
johnl
============================================================================
========
exmple table - count=750000 Column | Type |
Modifiers
----------------+-----------------------------patseq | integer | not null default
nextval('public.patient_patseq_seq'::text)mpin | character varying(12) | not nullmrn |
charactervarying(18) | not nullfacilityid | character varying(12) | not nulldob | date
|sex | character(1) |lastname | character varying(30) |firstname
| character varying(30) |middlename | character varying(30) |terminatedcare | boolean
|iscurrent | boolean | not nullfielda | character varying(10) |fieldb
| character varying(10) |fieldc | character varying(10) |fieldd | character varying(10)
|fielde | character varying(10) |fieldf | timestamp without time zone | default
('now'::text)::timestamp(6) with time zone
Indexes: patient_pkey primary key btree (patseq), patient_fname_idx btree (firstname), patient_lname_idx
btree(lastname), patient_mpin_idx btree (mpin), patient_mrnfac_idx btree (mrn, facilityid)
> I think AIX will need this too. Anyway I can't check it, since > the snapshots are not produced anymore (last is from 24.3.) (Marc ?) :-( >That's fixed as of last night (thanks Marc) --- seems cvs.postgresql.org >had an old bison and so the build was failing. Thanks! In fact I could build from the (24.3) snapshot removing the ecpg directory. I will try to compile the code from cvs again and report you back of any problems I get. Thanks Jason and all for your support in cygwin! ===== Regards, Francisco Figueiredo Jr. --- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi _______________________________________________________________________ Yahoo! Mail O melhor e-mail gratuito da internet: 6MB de espaço, antivírus, acesso POP3, filtro contra spam. http://br.mail.yahoo.com/