Tom,
On Sun, Dec 31, 2000 at 05:53:09PM -0500, Tom Lane wrote:
> Jason Tishler <Jason.Tishler@dothill.com> writes:
> >> These changes look fine as far as they go, but if you think
> >> TransactionCommandContext needs to be DLLIMPORT, why not the other
> >> global context variables, too?
>
> > I took the minimalist approach -- meaning that I only made the minimum
> > number of changes necessary to get PostgreSQL to compile cleanly under
> > Cygwin. You are correct, the other global context variables should
> > also be marked DLLIMPORT. There are probably other global variables
> > that should be marked too.
>
> > The completeness approach would DLLIMPORT "everything" (similar to
> > the way that Python uses DL_EXPORT), but that would be a lot of source
> > code changes...
>
> Seems like that's heading in the wrong direction. Isn't there a
> compiler switch or something we could give to make ALL global vars be
> automatically marked DLLIMPORT? That's generally how it works on Unix
> platforms (for example, on HPUX the -E linker switch makes these symbols
> available to dynamically linked shlibs).
There is a way and the PostgreSQL build is already taking advantage of
it:
dlltool --export-all --output-def postgres.def access/SUBSYS.o ...
However, there is a downside to the above. Now all functions and global
variables are exported from postgres.exe -- not just the ones that make
sense. This is why the Python approach may be considered "better."
Unfortunately, the above still does not mitigate the need for marking
global variables DLLIMPORT in their corresponding header files to
prevent unresolved linker errors by clients of libpostgres.a.
> I don't really like the idea of cluttering the source code for the
> benefit of one platform...
Agreed.
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