- don't pollute CFLAGS with extra optimizer flags
- remove part of patch-ac which forces -pthread instead of -lc_r
(was included in the main distribution)
- don't name freebsd version in mit-pthreads/config/configure
explicitly. settings work for 2.*, 3.* and 4.*.
The API for libmysqlclient was changed a bit for mysql322.
(xmysqladmin was written for mysql321.) So a db argument for
mysql_real_connect() is necessary now and mysql_init() has to be
called in order to initialize the connection struct.
Problem reported by: jhk
The default is mysql322 now, but take mysql321 if it is installed.
(mysql321 installs a static libmysqlclient.a only, mysql322 installs a
static and shared version of the library. Note that the build dependency
to mysql321 is a no op actually. It is in there to improve understanding(?).)
Start up a /usr/ports/YEAR2000 file to provide a central location for all
software. Will be buildling a nightly run shell script to pull all the Y2K
variables from ports, so that the central list remains reasonably up to date...
Use newly introduced %%PARL_ARCH%% for dirname of architecture
dependent libraries.
(i.e. s!%%PERL_VER%%/i386-freebsd!%%PERL_VER%%/%%PERL_ARCH%%!)
Approved by: asami
On October 12 this port was marked BROKEN_ELF by jsegar because it
depended on the then BROKEN_ELF databases/mysql321. mysql321 was
unBROKEN_ELF'd by jsegar 4 days later, but this port remained BROKEN_ELF
until now.
-------
cc -c -I/usr/local/pgsql/include -I/usr/local/include -O -pipe -DVERSION=\"1.6.1\" -DXS_VERSION=\"1.6.1\" -DPIC -fpic -I/usr/local/lib/perl5/5.00502/i386-freebsd/CORE Pg.c
In file included from /usr/local/pgsql/include/postgres.h:40,
from Pg.xs:25:
/usr/local/pgsql/include/config.h:247: warning: `USE_LOCALE' redefined
/usr/local/lib/perl5/5.00502/i386-freebsd/CORE/perl.h:342: warning: this is the location of the previous definition
Pg.xs: In function `XS_Pg_PQexec':
Pg.xs:300: sizeof applied to an incomplete type
Pg.xs: In function `XS_PG_conn_exec':
Pg.xs:702: sizeof applied to an incomplete type
*** Error code 1
Stop.
-------
:
cc -c -I/usr/local/pgsql/include -I/usr/local/include/pgsql -I/usr/include/pgsql -I/usr/local/lib/perl5/5.00502/i386-freebsd/DBI -I/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/DBI -I/usr/local/include -O -pipe -DVERSION=\"0.72\" -DXS_VERSION=\"0.72\" -DPIC -fpic -I/usr/local/lib/perl5/5.00502/i386-freebsd/CORE dbdimp.c
dbdimp.c: In function `dbd_db_ping':
dbdimp.c:135: dereferencing pointer to incomplete type
dbdimp.c:136: dereferencing pointer to incomplete type
dbdimp.c:140: dereferencing pointer to incomplete type
dbdimp.c:140: dereferencing pointer to incomplete type
dbdimp.c:141: dereferencing pointer to incomplete type
dbdimp.c:142: dereferencing pointer to incomplete type
dbdimp.c:146: dereferencing pointer to incomplete type
dbdimp.c:146: dereferencing pointer to incomplete type
dbdimp.c:146: dereferencing pointer to incomplete type
dbdimp.c:146: dereferencing pointer to incomplete type
dbdimp.c:147: dereferencing pointer to incomplete type
dbdimp.c:148: dereferencing pointer to incomplete type
*** Error code 1
Stop.
something already there (PORTOBJFORMAT, OSVERSION) or move stuff from after
.include <bsd.port.mk> to before.
(This is not by any means the complete list but just the ones I've noticed
recently.)
not only using -lc_r what would result in linking in libc and libc_r
Submitted by: Dirk Froemberg <ibex@physik.TU-Berlin.DE>
Obtained from: John Birrell
agreed by Josh Tiefenbach <josh@ican.net>, thanks Josh for your
previous work on this port.
Port is no more broken. Requested by new maintainer and tested by
me with a -current system.
/usr/ports/databases/mysql/work/mysql-3.21.33/scripts/mysql_install_db
Didn't find the 'data' directory in the current directory
You should be in the distribution directory when executing this script
Please go to the directory where you unpacked this distribution
and start this script with 'scripts/mysql_install_db'
*** Error code 1
Move msql to 87:87 so that package-building works again. I have an
extremely strong suspicion that msql does not need _reserved_ uid:gid's at
all, but I can't even fetch the distfile to check...
===
## make package
>> Checksum OK for PyGreSQL-2.1.tgz.
===> Extracting for py-PyGreSQL-2.1
===> py-PyGreSQL-2.1 depends on executable: python - found
===> py-PyGreSQL-2.1 depends on shared library: pq\.1\. - found
===> Patching for py-PyGreSQL-2.1
===> Configuring for py-PyGreSQL-2.1
test: syntax error
/bin/cp /usr/ports/databases/py-PyGreSQL/scripts/Makefile /usr/ports/databases/py-PyGreSQL/work
/bin/cp /usr/ports/databases/py-PyGreSQL/scripts/Makefile.in /usr/ports/databases/py-PyGreSQL/work
/bin/cp /usr/ports/databases/py-PyGreSQL/scripts/configure.in /usr/ports/databases/py-PyGreSQL/work
install -c -m 0555 /usr/ports/databases/py-PyGreSQL/scripts/install-sh /usr/ports/databases/py-PyGreSQL/work
install -c -m 0555 /usr/ports/databases/py-PyGreSQL/scripts/configure.local /usr/ports/databases/py-PyGreSQL/work/configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
checking for gcc... cc
checking whether the C compiler (cc -O2 -pipe -L/usr/local/lib/python1.5/config -L/usr/local/pgsql/lib) works... yes
checking whether the C compiler (cc -O2 -pipe -L/usr/local/lib/python1.5/config -L/usr/local/pgsql/lib) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether cc accepts -g... yes
checking for python... /usr/local/bin/python
checking for pow in -lm... yes
checking for read_history in -lreadline... yes
checking for crypt in -lcrypt... yes
checking for PyArg_Parse in -lpython1.5... no
configure: error: The Python 1.5 library could not be found.
*** Error code 1
:
===
Note the "test: syntax error" in the first line output from configure.
Satoshi
Many bugfixes and cosmetic changes
Changes by Scrappy and me
My additional changes:
- had to link libpgtcl.so with the crypt library to get rid of the
pgaccess error message, that crypt is missing
- had to add -i option in the startup script, so that pgaccess is
able to connect to the postmaster process
- removed all unnecessary patches
- updated PLIST
Thanks to the postgresql developement team, who did a great job to
simplify the postgresql port, by applying the patches and making
the autoconf mechanism more consistent.
Submitted by: The Hermit Hacker <scrappy@hub.org>
Now, I know you tested it (who doesn't? :), Andreas, but you need to
test it *twice* with a "make deinstall" in between, or you may not
catch files that were left from the previous installation (as it was
in this case).
the bug-gnats mailing list. There are a ton of bugfixes and
some good new features (like user defined states).
I should have used the makefile's patch code to deal with this,
but the patches had differning formats and there were order dependancies,
so I built these patch ffiles by hand.
From the author:
Date: Sun, 04 Jan 1998 12:44:48 +0200
From: Constantin Teodorescu <teo@flex.ro>
Organization: FLEX Consulting Braila
Subject: Bug in PgAccess 0.7x , fixed in 0.73 !
Hello all,
recently Dave Chapeskie has discovered a bug in visual query builder,
when deleting table or links! This was due to last changed in source
code made in order to allow table aliasing.
All previously released 0.7x versions of PgAccess are buggy from this
point of view!
I have released today the 0.73 version that fixes it! Please use the new
versions and keep me informed !!!
This new version is also using a drop-down-like combo for choosing
tables in visual query builder! I will probably use it in other places
in order to enhance PgAccess.
Thanks again for testing PgAccess.
from the author:
"I started to write at the Reports module.
from a table, no filters, no sorts (yet) !
Of course, no prints ! Only fields in output report (no labels, lines or
rectangles)!
I am working now at region resizing (page header, footer, detail, etc)
Reports will be generated as Postscript file!
stay close ..."
Update to version 0.70
From his announcement:
> PgAccess v0.70 handles now user defined forms and scripts!
>
> Manipulating forms, PgAccess could be enhanced by the user in order to
> generate new applications.
> The powerfull scripting feature inherited from Tcl/Tk, the native
> environment of PgAccess, allow users to define and use new procedures,
> libraries and even call "system" procedures that I have been used
> writting PgAccess. I would say that PgAccess will be able to accept
> "plugin" modules in order to make him more powerfull. It will make him
> just a "shell" who will set up only a "working environment" for newly
> developed applications!!!!
>
> More information and some examples you will find at
> http://www.flex.ro/pgaccess/pga-rad.html
>
> Once more, I would like to thank you folks for giving me PostgreSQL and
> Visual Tcl, and hoping that PgAcces would help making them more popular!
- author was so nice to add a version number in the source file, hurray.
- "dynamically" patch the path to libpgtcl.so ${PREFIX}/pgsql/lib/libpgtcl.so|
depending on the PREFIX variable using new post-configure script
- tested building, installing, packaging
