method. Fix a number of places where shared libraries were linked without
mentioning all the libraries they depend on; the Darwin and AIX ports
are known to require this, and it doesn't seem to hurt any other supported
platforms. (Hence, remove code in pl/tcl makefile that tried to avoid
mentioning other libs if not needed.)
Win32 port is now called 'win32' rather than 'win'
add -lwsock32 on Win32
make gethostname() be only used when kerberos4 is enabled
use /port/getopt.c
new /port/opendir.c routines
disable GUC unix_socket_group on Win32
convert some keywords.c symbols to KEYWORD_P to prevent conflict
create new FCNTL_NONBLOCK macro to turn off socket blocking
create new /include/port.h file that has /port prototypes, move
out of c.h
new /include/port/win32_include dir to hold missing include files
work around ERROR being defined in Win32 includes
contains the patches to Makefile.global.in and Makefile.unixware. The
Makefile.unixware patch has been updated to include the contents of
LD_LIBRARY_PATH, if present, to the -rpath (-R) option. This change
will simplify configuring and building PostgreSQL on systems that
support LD_LIBRARY_PATH. You can set LD_LIBRARY_PATH to include all
the directorys you want to have searched for additional libraries, run
configure, then run make. The paths in LD_LIBRARY_PATH will then be
embedded in the executables via the -rpath (-R) option to the linker,
and so will not require LD_LIBRARY_PATH in order to run.
Billy G. Allie
> > > > found in the postmaster and not included from elsewhere)
> >
> > shared libs on AIX need to be able to resolve all symbols at linkage time.
> > Those two symbols are in backend/utils/SUBSYS.o but not in the postgres
> > executable.
>
> They are defined in backend/utils/mb/conv.c and declared in
> include/mb/pg_wchar.h. They're also linked into the
> postmaster. I don't see anything unusual.
Attached is a patch to fix the mb linking problems on AIX. As a nice side effect
it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so
(all shlibs that are not postmaster loadable modules).
Please apply to current (only affects AIX).
The _LARGE_FILES problem is unfortunately still open, unless Peter
has fixed it per his recent idea.
Zeugswetter Andreas SB SD
Eliminate the mysterious games that the Cygwin build plays with the linker
flag variables. DLLLIBS is gone, use SHLIB_LINK like everyone else.
Detect cygipc in configure, after the linker flags are set up, otherwise
configure might not work at all.
Make sure everything is covered by make clean.
Fix the build of the new conversion procedure modules.
Add new DLLIMPORT markers where required.
Finally, the compiler complains if we use an explicit
-I/usr/local/include, so don't do that. Curiously, -L/usr/local/lib is
still necessary.
patch is low risc, thus could be applied now, but can also wait for 7.3
Old Makefile shows, that -bnoentry is available since 4.1 .
Andreas Zeugswetter
> > -patches as well.
>
> The -Bdynamic probably ought to disappear.
That was there already, but I have no objections. I was trying to
make minimal changes.
Larry Rosenman
> Can someone research this and figure out what the proper solution for
> this is? Seems we are going around in circles if we keep
> adding/removing DLLIMPORT.
I believe that the attached patch is the correct solution -- I apologize
for the gyrations. With the attached patch, Cygwin libpq++ builds
cleanly again. The root cause was that DLLIMPORT was defaulting to
__declspec(dllimport) since BUILDING_DLL was *not* defined when building
the libpq++ DLL.
Unfortunately, to test my patch requires changing the following makefile:
src/interfaces/libpq++/examples/Makefile
and the #includes in all of the *.cc to build against the source tree
instead of the following hardcoded installation directory structure:
/usr/local/pgsql
I was able to manually build
src/interfaces/libpq++/examples/testlibpq0.exe
against my Cygwin libpq++ without errors. However, I have not tried to
actually test testlibpq0.exe.
Is this sufficient? Or, do you want me to clean up libpq++/examples too?
(Or, is it silly to even ask? :,)) Let me know how you want to proceed and
I will submit a patch to pgsql-patches.
Jason Tishler
system. Some systems did not understand the 'l' section, and in general
it wasn't entirely appropriate.
On SCO OpenServer, the man pages won't be installed at all until someone
figures out their man system.
in interfaces/perl5 a brief while ago.
Also, since building PL/Perl without a shared libperl actually works on
some platforms we can enable it there to get some development happening.
I've only checked off linux right now, but others should be added in the
future.
under Cygwin. The root cause of this problem is that (Sun) java is a
native Win32 app and hence does not understand Cygwin Posix style paths.
The solution is to use Cygwin's cygpath utility to convert the Posix style
JDBC installation directory path into a Win32 one before invoking ant.
I'm not sure if my patch is the best way to correct this issue but
my goal was to confine the Cygwin specific constructs to
Jason Tishler
it does not support 64bit integers. AFAIK that's the default data type for
OIDs, so I am not surprised that this does not work. Use gcc instead.
BTW., 7.1 does not compile as is with gcc either, I believed the
required patches made it into the 7.1.1 release but obviously I missed
the deadline.
Since the ports mailing list does not seem to be archived I have attached
a copy of the patch (for 7.1 and 7.1.1).
I've just performed a build of a Watcom compiled version and found a couple
of bugs in the watcom specific part of that patch. Please use the attached
version instead.
Tegge, Bernd
PostgreSQL Daemon