pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: Just some unfinished stuff.
14+ messages / 4 participants
[nested] [flat]
* Re: Just some unfinished stuff.
@ 1998-10-03 07:39 ` Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:30 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
2 siblings, 1 reply; 14+ messages in thread
From: Gerald Gryschuk @ 1998-10-03 07:39 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
Thomas G. Lockhart wrote:
> Anyway, is there any reason why you changed the behavior of configure to
> always prompt for the platform type? I've got patches which restore the
> Postgres configure behavior, which does not stop to prompt if it thinks
> it has a match.
Hmm... Forgive me a second. Are we talking when ./configure is done from
the top level Postgres directory(i.e. an integrated build) or are you
referring to a standalone build? Also I'm not sure what you mean by the
default Postgres behaviour. Remember I'm working from using the 6.3
source distribution. In the version I have Postgres, without any odbc
driver stuff, stops to prompt for my platform. If it doesn't stop in
the 6.4 version I don't think any of my changes should make it stop.
Maybe I should explain what I attempted and you can tell me if it
matches
what you see.
1) The 6.3 Postgres distribution configuration without our odbc stuff
stops to prompt for my platform, at least this is what I observed.
2) A STANDALONE odbc driver configuration stops to prompt for my
platform, this is because I started by copying the 6.3 configuration
files and edited to suit my needs.
3) My first run at integrating the two meant that the configuration
for an INTEGRATED build stopped twice.
4) After finding out that the TEMPLATE variable in the Postgres
configuration gets exported to the environment I made changes to
the odbc driver configuation such that if it was being built in
an integrated configuration that it's ./configure script would
NOT stop since it was able to get the TEMPLATE variable from the
environment.
5) After the changes in 4) a standalone build of the odbc driver
should still behave the same, i.e. it should stop and prompt for the
platform type.
If your saying that my observation in 1) is "wrong" than I don't
know what's up with that. If the original Postgres distribution,
without our integrated odbc source, isn't supposed to stop than
I don't think that any of my suggested changes to the Postgres
configure.in would have made it stop. On the other hand, your
working with the 6.4 configuation scripts, so... if the
6.4 configuration script doesn't stop AND it DOESN"T export
the TEMPLATE variable(condition 4 above) to the environment, than
attempting to build an integrated source with the odbc driver
WILL make it stop since the odbc configure script won't know
what the "current" value of TEMPLATE is. This would suggest to
me that there are "significant" changes to the 6.4 configure
script which I didn't have. Thus if you have fixes that can
easily be made to the odbc driver configure.in than by all
means make them.
NOTE: When I started this I always found it weird that the
6.3 configure script would stop and prompt. I had never seen
this before given that configure has access to exactly which
platform your running on through the AC_CONFIG_HOST(?) macro.
I was trying to make changes to avoid this behaviour but
I'm not good enough at this configure stuff yet to have
done it.
Sorry for the long winded explanation to what I'm sure seemed
like a straight forward question.
> Byron, apparently you and Gerald have already settled the WINDOWS vs.
> WIN32 problem? Do I have access to the latest source code? I hate asking
> you to do the ./configure integration if you don't have a way to test it
> (I'm not sure what your platform mix is, but assume that it has at least
> one windows machine :).
Don't worry I don't have Byron's changes either. Recall that I asked
Byron to check into this when I sent out my first configure attempt.
He reponsed(quite quickly I might add) that he had to change my
use of WINDOWS to WIN32 but that was it. I wasn't all that worried
figuring I'ld just pick up the new source in the next release but
I guess you should probably get it earlier than that.
>
> Gerald, do we have some ideas on who will take on the
> configure.in/template maintenance as we integrate more platforms (hint,
> hint)? I've got so many commitments to various pieces of Postgres
> already that I'd really like to avoid becoming the bottleneck for this
> support...
I have limited access to some SUN equipment for testing builds,
but I don't really like using it for this kind of thing since the
sys admin where the equipement is, is essentially doing me a favor
by keeping my (very) old account active. We have a Digital Alpha
dual boot system at work that I set up, so I can also do test builds
there under OSF/1 time permitted. Sooo.. I can't promise that I'll
put as much hard time in as I did on the configure and the original
port which both cut into my real job. But I'll stand as the Unix
"maintainer" if you like.
> Speaking of docs, Byron, do you have a preference for how we will do
> nice docs for the distribution? I've got some sgml source code for
> Unix-side issues, but have not integrated any other information. Could
> you summarize what docs resources currently exist, and which ones you
> would like to see in the future?
Oh goody. Real docs. I was hoping someone else would do them. Can I
assume that if your writing "nice docs" that I don't have to write
that new Readme I mentioned?
>
> A nice chapter on the odbc stuff in the main Postgres docs could also be
> built as a standalone document, which would give you both hardcopy and
> html for your distribution...
Just as a matter of completeness if your putting "maintainers" e-mail
addresses in the docs you might want to put in both of mine, at
work it's ggryschuk@scf.sk.ca and at home it's gerald.gryschuk@home.com.
Some day I'll set up my Linux accounts so my e-mail gets automatically
forwarded depending on the time of day but it doesn't seem quite that
important right now.
>
> btw, it might be nice to keep the discussion on the interfaces mailing
> list so others can offer help and keep up to date with progress.
Done, I've CC'ed this response to the mailing list.
--
Gerald Gryschuk
gerald.gryschuk@home.com
MidNightOil Consulting - "We burn the midnight oil so you don't have
to."
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Just some unfinished stuff.
1998-10-03 07:39 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
@ 1998-10-03 14:30 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 0 replies; 14+ messages in thread
From: Thomas G. Lockhart @ 1998-10-03 14:30 UTC (permalink / raw)
To: Gerald Gryschuk <gerald.gryschuk@home.com>; +Cc: Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
> > Speaking of docs, Byron, do you have a preference for how we will do
> > nice docs for the distribution? I've got some sgml source code for
> > Unix-side issues, but have not integrated any other information.
> > Could you summarize what docs resources currently exist, and which
> > ones you would like to see in the future?
> Oh goody. Real docs. I was hoping someone else would do them. Can I
> assume that if your writing "nice docs" that I don't have to write
> that new Readme I mentioned?
Well, I have good new and bad news...
First, the good news: We will have real odbc docs for this release.
Now the bad news: I'd like you to contribute to them *grin*
I've enclosed the existing sgml source and the html output (so you can
see what it looks like) for the odbc docs I've adapted and written.
afaik it doesn't have any of the generic or WIN32 info from Byron's
docs, but it should try to cover the Unix-specific stuff at least.
Could you look at it and add information you think is important? If you
get confused on the sgml markup just type in plain text in about the
right place without markup and I'll fix it up after you send it back
(maybe you can mark things with a "***" or "GGG" to make sure I find the
un-marked-up changes, if any).
At the moment I've got these docs in the Programmer's Guide, but I think
they should show up somewhere else, in either the User's Guide or the
Admin's Guide. Which would you vote for?
- Tom
Attachments:
odbc.sgml (text/html, 6.1K) download
<Chapter Id="odbc">
<DocInfo>
<AuthorGroup>
<Author>
<FirstName>Tim</FirstName>
<Surname>Goeke</Surname>
</Author>
<Author>
<FirstName>Thomas</FirstName>
<Surname>Lockhart</Surname>
</Author>
</AuthorGroup>
<Date>1998-08-25</Date>
</DocInfo>
<Title>ODBC Interface</Title>
<Para>
<Note>
<Para>
Background information originally by
<ULink url="mailto:tgoeke@xpressway.com">Tim Goeke</ULink>
</Para>
</Note>
<Para>
<acronym>ODBC</acronym> (Open Database Connectivity) is an abstract
<acronym>API</acronym>
which allows you to write standard "ODBC" applications.
<acronym>ODBC</acronym> provides a product-neutral interface
between frontend applications and database servers,
allowing a user or developer to write applications which are portable among servers.
<Sect1>
<Title>Background</Title>
<Para>
The <acronym>ODBC</acronym> <acronym>API</acronym> matches up
on the backend to an <acronym>ODBC</acronym>-compatible data source.
This could be anything from a text file to an Oracle or
<productname>Postgres</productname> <acronym>RDBMS</acronym>.
<Para>
The backend access come from <acronym>ODBC</acronym> drivers, or vendor specifc drivers that
allow data access. <productname>psqlODBC</productname> is such a driver, along with others that are
available, such as the OpenLink <acronym>ODBC</acronym> drivers.
<Para>
Once you write an <acronym>ODBC</acronym> application, you SHOULD be able to connect to ANY
back end database, regardless of the vendor, as long as the database schema
is the same.
<Para>
For example. you could have <productname>MS SQL Server</productname>
and <productname>Postgres</productname> servers which have
exactly the same data. Using <acronym>ODBC</acronym>, your Windows app would make exactly the
same calls and the back end data source would look the same (to the windows
app).
<para>
<ulink url="http://www.insightdist.com/">Insight Distributors</ulink> provides active and ongoing
support for the core <productname>psqlODBC</productname> distribution. They provide a
<ulink url="http://www.insightdist.com/psqlodbc/"><acronym>FAQ</acronym></ulink>, ongoing development
on the code base, and actively participate on the
<ulink url="mailto:interfaces@postgresql.org">interfaces mailing list</ulink>.
<sect1>
<title><productname>Windows</productname> Applications</title>
<Para>
In the real world, differences in drivers and the level of <acronym>ODBC</acronym> support
lessens the potential of <acronym>ODBC</acronym>:
<SimpleList>
<Member>
Access, Delphi, and Visual Basic all support <acronym>ODBC</acronym> directly.
<Member>
Under C++, such as Visual C++, you can use the C++ <acronym>ODBC</acronym> <acronym>API</acronym>.
<Member>
In Visual C++, you can use the CRecordSet class, which wraps the
<acronym>ODBC</acronym> <acronym>API</acronym>
set within an MFC 4.2 class. This is the easiest route if you are doing
Windows C++ development under Windows NT.
</SimpleList>
<Para>
If I write an app for <productname>Postgres</productname>
can I write it using <acronym>ODBC</acronym> calls
to the <productname>Postgres</productname> server, or is that only when another database program
like MS SQL Server or Access needs to access the data?
<Para>
Again, the <acronym>ODBC</acronym> <acronym>API</acronym> set is the way to go.
You can find out more at
Microsoft's web site or in your Visual C++ docs (if that's what you are using.)
<Para>
Visual Basic and the other RAD tools have Recordset objects that use <acronym>ODBC</acronym>
directly to access data. Using the data-aware controls, you can quickly
link to the <acronym>ODBC</acronym> back end database (<Emphasis>very</Emphasis> quickly).
<Para>
Playing around with MS Access will help you sort this out. Try using
File->Get External Data
<Para>
<Tip>
<Para>
You'll have to set up a DSN first.
</Para>
</Tip>
<!--
<Para>
<Tip>
<Para>
The <productname>Postgres</productname> datetime type will break MS Access.
</Para>
</Tip>
-->
<sect1>
<title>Unix Applications</title>
<para>
<productname>ApplixWare</productname> has an <acronym>ODBC</acronym> database interface
supported on at least some platforms. <productname>ApplixWare</productname> v4.4.1 has been
demonstrated under Linux with <productname>Postgres</productname> v6.4
using the <productname>psqlODBC</productname>
driver contained in the <productname>Postgres</productname> distribution.
<sect2>
<title>Configuration Files</title>
<para>
The <filename>~/.odbc.ini</filename> contains user-specified access information
for the <productname>psqlODBC</productname>
driver. The file uses conventions typical for <productname>Windows</productname>
Registry files, but despite this
restriction can be made to work.
<para>
Here is an example <filename>.odbc.ini</filename> file,
showing access information for three databases:
<programlisting>
[ODBC Data Sources]
DataEntry = Read/Write Database
QueryOnly = Read-only Database
Test = Debugging Database
Default = Postgres Stripped
[DataEntry]
ReadOnly = 0
Servername = localhost
Database = Sales
[QueryOnly]
ReadOnly = 1
Servername = localhost
Database = Sales
[Test]
Debug = 1
CommLog = 1
ReadOnly = 0
Servername = localhost
Username = tgl
Password = "no$way"
Port = 5432
Database = test
[Default]
Servername = localhost
Database = tgl
Driver = /opt/postgres/current/lib/libpsqlodbc.so
[ODBC]
InstallDir = /opt/applix/axdata/axshlib
</programlisting>
<para>
For Applix, here is an example ~/axhome/macros/login.am file:
<programlisting>
macro login
set_set_system_var@("sql_username@","tgl")
set_system_var@("sql_passwd@","no$way")
endmacro
</programlisting>
<sect1>
<title>Supported Platforms</title>
<para>
<productname>psqlODBC</productname> has been built and tested
on <productname>Linux</productname>. There have been reports of success
with FreeBSD and with Solaris.
</Chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"../reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:"/usr/lib/sgml/catalog"
sgml-local-ecat-files:nil
End:
-->
odbc.htm (text/html, 4.1K) download
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>ODBC Interface</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet version 1.18"><LINK
REL="HOME"
TITLE="PostgreSQL Programmer's Guide"
HREF="programmer.htm"><LINK
REL="PREVIOUS"
TITLE="pg_lo_export"
HREF="pgtcl-pgloexport.htm"><LINK
REL="NEXT"
TITLE="Windows Applications"
HREF="odbc4084.htm"></HEAD
><BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>PostgreSQL Programmer's Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="pgtcl-pgloexport.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="odbc4084.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
><A
NAME="ODBC"
>Chapter 19. ODBC Interface</A
></H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
><A
HREF="odbc.htm#AEN4060"
>Background</A
></DT
><DT
><A
HREF="odbc4084.htm"
><SPAN
CLASS="PRODUCTNAME"
>Windows</SPAN
> Applications</A
></DT
><DT
><A
HREF="odbc4114.htm"
>Unix Applications</A
></DT
><DT
><A
HREF="odbc4134.htm"
>Supported Platforms</A
></DT
></DL
></DIV
><P
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>Background information originally by
<A
HREF="mailto:tgoeke@xpressway.com"
TARGET="_top"
>Tim Goeke</A
></P
></BLOCKQUOTE
> </P
><P
><SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> (Open Database Connectivity) is an abstract
<SPAN
CLASS="ACRONYM"
>API</SPAN
>
which allows you to write standard "ODBC" applications.
<SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> provides a product-neutral interface
between frontend applications and database servers,
allowing a user or developer to write applications which are portable among servers. </P
><H1
CLASS="SECT1"
><A
NAME="AEN4060"
>Background</A
></H1
><P
>The <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> <SPAN
CLASS="ACRONYM"
>API</SPAN
> matches up
on the backend to an <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
>-compatible data source.
This could be anything from a text file to an Oracle or
<SPAN
CLASS="PRODUCTNAME"
>Postgres</SPAN
> <SPAN
CLASS="ACRONYM"
>RDBMS</SPAN
>. </P
><P
>The backend access come from <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> drivers, or vendor specifc drivers that
allow data access. <SPAN
CLASS="PRODUCTNAME"
>psqlODBC</SPAN
> is such a driver, along with others that are
available, such as the OpenLink <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> drivers. </P
><P
>Once you write an <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> application, you SHOULD be able to connect to ANY
back end database, regardless of the vendor, as long as the database schema
is the same. </P
><P
>For example. you could have <SPAN
CLASS="PRODUCTNAME"
>MS SQL Server</SPAN
>
and <SPAN
CLASS="PRODUCTNAME"
>Postgres</SPAN
> servers which have
exactly the same data. Using <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
>, your Windows app would make exactly the
same calls and the back end data source would look the same (to the windows
app). </P
><P
><A
HREF="http://www.insightdist.com/"
TARGET="_top"
>Insight Distributors</A
> provides active and ongoing
support for the core <SPAN
CLASS="PRODUCTNAME"
>psqlODBC</SPAN
> distribution. They provide a
<A
HREF="http://www.insightdist.com/psqlodbc/"
TARGET="_top"
><SPAN
CLASS="ACRONYM"
>FAQ</SPAN
></A
>, ongoing development
on the code base, and actively participate on the
<A
HREF="mailto:interfaces@postgresql.org"
TARGET="_top"
>interfaces mailing list</A
>. </P
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="pgtcl-pgloexport.htm"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="programmer.htm"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="odbc4084.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>pg_lo_export</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><SPAN
CLASS="PRODUCTNAME"
>Windows</SPAN
> Applications</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
odbc4084.htm (text/html, 3.4K) download
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>Windows Applications</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet version 1.18"><LINK
REL="HOME"
TITLE="PostgreSQL Programmer's Guide"
HREF="programmer.htm"><LINK
REL="UP"
TITLE="ODBC Interface"
HREF="odbc.htm"><LINK
REL="PREVIOUS"
TITLE="ODBC Interface"
HREF="odbc.htm"><LINK
REL="NEXT"
TITLE="Unix Applications"
HREF="odbc4114.htm"></HEAD
><BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>PostgreSQL Programmer's Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="odbc.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 19. ODBC Interface</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="odbc4114.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
CLASS="SECT1"
><A
NAME="AEN4084"
><SPAN
CLASS="PRODUCTNAME"
>Windows</SPAN
> Applications</A
></H1
><P
>In the real world, differences in drivers and the level of <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> support
lessens the potential of <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
>:
<P
></P
><TABLE
BORDER="0"
><TR
><TD
>Access, Delphi, and Visual Basic all support <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> directly. </TD
></TR
><TR
><TD
>Under C++, such as Visual C++, you can use the C++ <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> <SPAN
CLASS="ACRONYM"
>API</SPAN
>. </TD
></TR
><TR
><TD
>In Visual C++, you can use the CRecordSet class, which wraps the
<SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> <SPAN
CLASS="ACRONYM"
>API</SPAN
>
set within an MFC 4.2 class. This is the easiest route if you are doing
Windows C++ development under Windows NT.</TD
></TR
></TABLE
><P
></P
> </P
><P
>If I write an app for <SPAN
CLASS="PRODUCTNAME"
>Postgres</SPAN
>
can I write it using <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> calls
to the <SPAN
CLASS="PRODUCTNAME"
>Postgres</SPAN
> server, or is that only when another database program
like MS SQL Server or Access needs to access the data? </P
><P
>Again, the <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> <SPAN
CLASS="ACRONYM"
>API</SPAN
> set is the way to go.
You can find out more at
Microsoft's web site or in your Visual C++ docs (if that's what you are using.) </P
><P
>Visual Basic and the other RAD tools have Recordset objects that use <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
>
directly to access data. Using the data-aware controls, you can quickly
link to the <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> back end database (<I
CLASS="EMPHASIS"
>very</I
> quickly). </P
><P
>Playing around with MS Access will help you sort this out. Try using
File->Get External Data </P
><P
><BLOCKQUOTE
CLASS="TIP"
><P
><B
>Tip: </B
>You'll have to set up a DSN first.</P
></BLOCKQUOTE
>
</P
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="odbc.htm"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="programmer.htm"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="odbc4114.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>ODBC Interface</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="odbc.htm"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Unix Applications</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
odbc4114.htm (text/html, 3.4K) download
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>Unix Applications</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet version 1.18"><LINK
REL="HOME"
TITLE="PostgreSQL Programmer's Guide"
HREF="programmer.htm"><LINK
REL="UP"
TITLE="ODBC Interface"
HREF="odbc.htm"><LINK
REL="PREVIOUS"
TITLE="Windows Applications"
HREF="odbc4084.htm"><LINK
REL="NEXT"
TITLE="Supported Platforms"
HREF="odbc4134.htm"></HEAD
><BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>PostgreSQL Programmer's Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="odbc4084.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 19. ODBC Interface</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="odbc4134.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
CLASS="SECT1"
><A
NAME="AEN4114"
>Unix Applications</A
></H1
><P
><SPAN
CLASS="PRODUCTNAME"
>ApplixWare</SPAN
> has an <SPAN
CLASS="ACRONYM"
>ODBC</SPAN
> database interface
supported on at least some platforms. <SPAN
CLASS="PRODUCTNAME"
>ApplixWare</SPAN
> v4.4.1 has been
demonstrated under Linux with <SPAN
CLASS="PRODUCTNAME"
>Postgres</SPAN
> v6.4
using the <SPAN
CLASS="PRODUCTNAME"
>psqlODBC</SPAN
>
driver contained in the <SPAN
CLASS="PRODUCTNAME"
>Postgres</SPAN
> distribution. </P
><H2
CLASS="SECT2"
><A
NAME="AEN4123"
>Configuration Files</A
></H2
><P
>The <TT
CLASS="FILENAME"
>~/.odbc.ini</TT
> contains user-specified access information
for the <SPAN
CLASS="PRODUCTNAME"
>psqlODBC</SPAN
>
driver. The file uses conventions typical for <SPAN
CLASS="PRODUCTNAME"
>Windows</SPAN
>
Registry files, but despite this
restriction can be made to work. </P
><P
>Here is an example <TT
CLASS="FILENAME"
>.odbc.ini</TT
> file,
showing access information for three databases:
<PRE
CLASS="PROGRAMLISTING"
>[ODBC Data Sources]
DataEntry = Read/Write Database
QueryOnly = Read-only Database
Test = Debugging Database
Default = Postgres Stripped
[DataEntry]
ReadOnly = 0
Servername = localhost
Database = Sales
[QueryOnly]
ReadOnly = 1
Servername = localhost
Database = Sales
[Test]
Debug = 1
CommLog = 1
ReadOnly = 0
Servername = localhost
Username = tgl
Password = "no$way"
Port = 5432
Database = test
[Default]
Servername = localhost
Database = tgl
Driver = /opt/postgres/current/lib/libpsqlodbc.so
[ODBC]
InstallDir = /opt/applix/axdata/axshlib</PRE
> </P
><P
>For Applix, here is an example ~/axhome/macros/login.am file:
<PRE
CLASS="PROGRAMLISTING"
>macro login
set_set_system_var@("sql_username@","tgl")
set_system_var@("sql_passwd@","no$way")
endmacro</PRE
> </P
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="odbc4084.htm"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="programmer.htm"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="odbc4134.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><SPAN
CLASS="PRODUCTNAME"
>Windows</SPAN
> Applications</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="odbc.htm"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Supported Platforms</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
odbc4134.htm (text/html, 1.8K) download
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>Supported Platforms</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet version 1.18"><LINK
REL="HOME"
TITLE="PostgreSQL Programmer's Guide"
HREF="programmer.htm"><LINK
REL="UP"
TITLE="ODBC Interface"
HREF="odbc.htm"><LINK
REL="PREVIOUS"
TITLE="Unix Applications"
HREF="odbc4114.htm"><LINK
REL="NEXT"
TITLE="JDBC Interface"
HREF="jdbc.htm"></HEAD
><BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>PostgreSQL Programmer's Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="odbc4114.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 19. ODBC Interface</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="jdbc.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
CLASS="SECT1"
><A
NAME="AEN4134"
>Supported Platforms</A
></H1
><P
><SPAN
CLASS="PRODUCTNAME"
>psqlODBC</SPAN
> has been built and tested
on <SPAN
CLASS="PRODUCTNAME"
>Linux</SPAN
>. There have been reports of success
with FreeBSD and with Solaris. </P
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="odbc4114.htm"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="programmer.htm"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="jdbc.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Unix Applications</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="odbc.htm"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>JDBC Interface</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
* Re: Just some unfinished stuff.
@ 1998-10-03 07:42 ` Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-04 16:57 ` Re: [INTERFACES] Re: Just some unfinished stuff. Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 14+ messages in thread
From: Gerald Gryschuk @ 1998-10-03 07:42 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
Thomas G. Lockhart wrote:
>
> The configure/makefile builds the sources just fine. But "make install"
> fails when I try installing within the Postgres tree as the postgres su:
>
> golem$ make install
> /usr/bin/install -c -m 444 iodbc.h /usr/local/include/iodbc/iodbc.h
> /usr/bin/install: /usr/local/include/iodbc/iodbc.h: Permission denied
> make: *** [install-headers] Error 1
>
> Shouldn't this be going to somewhere in the Postgres tree? Or not done
> at all if the target isn't writable?
you bet it should be. That's a bug I'll squash the sucker and get back
to you.
(note: this message also CC'd to the list)
--
Gerald Gryschuk
gerald.gryschuk@home.com
MidNightOil Consulting - "We burn the midnight oil so you don't have
to."
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [INTERFACES] Re: Just some unfinished stuff.
1998-10-03 07:42 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
@ 1998-10-04 16:57 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 14+ messages in thread
From: Tom Lane @ 1998-10-04 16:57 UTC (permalink / raw)
To: Gerald Gryschuk <gerald.gryschuk@home.com>; +Cc: pgsql-interfaces
> Thomas G. Lockhart wrote:
>> The configure/makefile builds the sources just fine. But "make install"
>> fails when I try installing within the Postgres tree as the postgres su:
>>
>> golem$ make install
>> /usr/bin/install -c -m 444 iodbc.h /usr/local/include/iodbc/iodbc.h
>> /usr/bin/install: /usr/local/include/iodbc/iodbc.h: Permission denied
>> make: *** [install-headers] Error 1
Could it be that iodbc.h is getting installed twice by two different
makefiles in the distribution?
On my platform, once you've installed something with read-only
permission (and note the "-m 444" above), the local version of the
install script will not overwrite that file. So the second attempt
to install would fail, with exactly the above-displayed error.
Currently, I have to manually blow away /usr/local/pgsql/bin, .../lib,
and .../include before doing a fresh "make install". (I've been
intending to submit some kind of improvement to fix that, but it hasn't
yet got to the top of the to-do queue.)
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Just some unfinished stuff.
@ 1998-10-03 08:01 ` Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
2 siblings, 1 reply; 14+ messages in thread
From: Gerald Gryschuk @ 1998-10-03 08:01 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
Thomas G. Lockhart wrote:
>
> The configure/makefile builds the sources just fine. But "make install"
> fails when I try installing within the Postgres tree as the postgres su:
>
> golem$ make install
> /usr/bin/install -c -m 444 iodbc.h /usr/local/include/iodbc/iodbc.h
> /usr/bin/install: /usr/local/include/iodbc/iodbc.h: Permission denied
> make: *** [install-headers] Error 1
>
> Shouldn't this be going to somewhere in the Postgres tree? Or not done
> at all if the target isn't writable?
Me again. I just took a quick look at the Makefile set up and I'm at
a loss to see why this happened. So.. can you elaborate on what you
did and if your using my second set of configuration changes or
the first?
Is this an integrated make? Did you do the 'make install' from the
top level of the Postgres distribution? Did you run configure from
the top level? You get the idea. Oh and check the Makefle.global
in the odbc driver directory, the variable PSQLODBC should be
the location of your installed Postgres installation. To be on
the safe side please send me one line from your GNUmakefile.
Specifically, the install-headers target should have 3 lines for
actions to perform, they should all read similarly like follows,
$(INSTALL) $(INSTLOPTS) iodbc.h $(HEADERDIR)/iodbc/iodbc.h
HEADERDIR gets set in the Makefile.global to $(PSQLODBC)/include and
PSQLODBC should have been set to the "detected" Postgres installation
directory.
Thanks
--
Gerald Gryschuk
gerald.gryschuk@home.com
MidNightOil Consulting - "We burn the midnight oil so you don't have
to."
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Just some unfinished stuff.
1998-10-03 08:01 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
@ 1998-10-03 14:00 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-04 20:59 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
0 siblings, 1 reply; 14+ messages in thread
From: Thomas G. Lockhart @ 1998-10-03 14:00 UTC (permalink / raw)
To: Gerald Gryschuk <gerald.gryschuk@home.com>; +Cc: Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
> Me again. I just took a quick look at the Makefile set up and I'm at
> a loss to see why this happened. So.. can you elaborate on what you
> did and if your using my second set of configuration changes or
> the first?
OK, I've gotten your e-mails, and so now I understand where we are
starting from (maybe :). v6.3 had some brain-damage on the automatic
platform detection (or didn't try at all). Let me send you my patched
version of configure.in so you are starting with something closer to the
v6.4 behavior.
I'm also going to assume that I've got the most recent versions of
things, and will integrate and test changes here, then commit to the
Postgres source tree when we've worked through the configure stuff. Will
send the complete set to Byron for vetting at the same time, and we can
commit patches as he likes.
Uh, so here it is the configure.in...
- Tom
Attachments:
configure.in (text/plain, 6.6K) download
dnl Process this file with autoconf to produce a configure script.
AC_INIT(bind.c)
AC_PREFIX_DEFAULT(/usr/local)
if test -d ../../interfaces
then
if test "$prefix" = "NONE"
then
ODBCINSTDIR=$ac_default_prefix/pgsql
else
ODBCINSTDIR=$prefix
fi
else
if test "$prefix" = "NONE"
then
ODBCINSTDIR=$ac_default_prefix/share
else
ODBCINSTDIR=$prefix
fi
fi
AC_CANONICAL_HOST
case "$host_os" in
solaris*)
case "$host_cpu" in
sparc) os=sparc_solaris ;;
i386) os=i386_solaris ;;
esac ;;
sunos*) os=sunos4 ;;
aux*) os=aux ;;
linux*) os=linux ;;
bsdi*) os=bsdi ;;
freebsd*|netbsd*|openbsd*) os=bsd ;;
dgux*) os=dgux ;;
aix*) os=aix ;;
nextstep*) os=nextstep ;;
ultrix*) os=ultrix4 ;;
irix*) os=irix5 ;;
hpux*) os=hpux ;;
osf*) os=alpha ;;
sco*) os=sco ;;
machten*) os=machten ;;
cygwin*) os=win ;;
sysv4.2*)
case "$host_vendor" in
univel) os=univel ;;
*) os=unknown ;;
esac ;;
sysv4*) os=svr4 ;;
*) echo ""
echo "*************************************************************"
echo "configure does not currently recognize your operating system,"
echo "therefore you must do a manual configuration of:"
echo "$host_os"
echo "Please contact scrappy@hub.org to see about rectifying this, "
echo "including the above 'checking host system type...' line "
echo "*************************************************************"
echo ""
exit;;
esac
PORTNAME=${os}
AC_SUBST(PORTNAME)
echo "checking echo setting..."
if echo '\c' | grep -s c >/dev/null 2>&1
then
ECHO_N="echo -n"
ECHO_C=""
else
ECHO_N="echo"
ECHO_C='\c'
fi
cat <<EOT
**************************************************************
Postodbc v0.0250 Installation Program
Welcome to the new improved Postodbc installation program.
This configuration program is for version 0.0250 of the
Postodbc software.
EOT
dnl this part selects the template from the one in the
dnl template directory.
dnl if test "X$with_template" != "X"
dnl then
dnl TEMPLATE=template/$with_template
dnl else
dnl TEMPLATE=DO_NOT_CHANGE_THIS_INVALID_FILENAME
dnl fi
AC_MSG_CHECKING(setting template to)
AC_ARG_WITH(template,
[ --with-template=TEMPLATE
use operating system template file
see template directory],
[ TEMPLATE=$withval ],
[ host_no_ver=`echo "$host" | sed 's/[[0-9.]]*$//'`
GUESS=`grep "$host_no_ver" template/.similar | sed 's/.*=//' | tail -1`
if test "$GUESS"
then TEMPLATE="$GUESS"
else TEMPLATE=`uname -s | tr A-Z a-z`
fi
])
AC_MSG_RESULT($TEMPLATE)
if test ! -f "template/$TEMPLATE"
then
cat <<EOT
Please select a template from the ones listed below. If no
template is available, then select the 'generic' one and
consider emailling scrappy@hub.org with the above line which
starts 'checking host system type...'
**************************************************************
EOT
TEMPLATE=generic
GUESS=`grep "^$host_no_ver=" template/.similar 2>/dev/null`
if test ! "$GUESS"
then host_no_ver=`echo "$host" | sed 's/[[0-9.]]*$//'`
GUESS=`grep "$host_no_ver" template/.similar 2>/dev/null`
fi
if test "$GUESS"
then
TEMPLATE=`echo $GUESS | sed 's/.*=//'`
fi
export TEMPLATE
ls template
echo "**************************************************************"
$ECHO_N "Appropriate template file { $TEMPLATE }: $ECHO_C"
read a
if test "$a." != "."
then
TEMPLATE=$a
fi
if test ! -f template/$TEMPLATE
then
echo "You must choose an appropriate template file."
exit
fi
fi
TEMPLATE=template/$TEMPLATE
export TEMPLATE
echo ""
AROPT=`grep '^AROPT:' $TEMPLATE | awk -F: '{print $2}'`
SHARED_LIB=`grep '^SHARED_LIB:' $TEMPLATE | awk -F: '{print $2}'`
CFLAGS=`grep '^CFLAGS:' $TEMPLATE | awk -F: '{print $2}'`
SRCH_INC=`grep '^SRCH_INC:' $TEMPLATE | awk -F: '{print $2}'`
SRCH_LIB=`grep '^SRCH_LIB:' $TEMPLATE | awk -F: '{print $2}'`
DLSUFFIX=`grep '^DLSUFFIX:' $TEMPLATE | awk -F: '{print $2}'`
DL_LIB=`grep '^DL_LIB:' $TEMPLATE | awk -F: '{print $2}'`
CC=`grep '^CC:' $TEMPLATE | awk -F: '{print $2}'`
LIBS=`grep '^LIBS:' $TEMPLATE | awk -F: '{print $2}'`
a=$SRCH_INC
CPPFLAGS=`echo "$a" | sed 's@ *@ @g; s@^\([[^ ]]\)@-I\1@; s@ \([[^ ]]\)@ -I\1@g'`
export CPPFLAGS
echo "- setting CPPFLAGS=$CPPFLAGS"
a=$SRCH_LIB
LDFLAGS=`echo "$a" | sed 's@ *@ @g; s@^\([[^ ]]\)@-L\1@; s@ \([[^ ]]\)@ -L\1@g'`
export LDFLAGS
echo "- setting LDFLAGS=$LDFLAGS"
dnl Allow for overriding the default location of the odbcinst.ini
dnl file which is normally ${prefix}/share or ${prefix} if this is
dnl being compiled inside the postgres distribution.
AC_MSG_CHECKING(setting ODBCINST)
AC_ARG_WITH(
odbcinst,
[ --with-odbcinst=<datadir> change default directory for odbcinst.ini],
AC_DEFINE_UNQUOTED(ODBCINST, ${with_odbcinst}) AC_MSG_RESULT($with_odbcinst),
AC_DEFINE_UNQUOTED(ODBCINST, ${ODBCINSTDIR}) AC_MSG_RESULT(${ODBCINSTDIR})
)
if test "X$with_odbcinst" != "X"
then
ODBCINSTDIR=$with_odbcinst
fi
AC_SUBST(ODBCINSTDIR)
if test "X$with_compiler" != "X"
then
CC=$with_compiler
else
AC_PROG_CC
fi
AC_CONFIG_HEADER(config.h)
dnl Checks for programs.
AC_PROG_CPP
AC_SUBST(PORTNAME)
AC_SUBST(LDFLAGS)
AC_SUBST(CPPFLAGS)
AC_SUBST(AROPT)
AC_SUBST(SHARED_LIB)
AC_SUBST(CFLAGS)
AC_SUBST(DLSUFFIX)
AC_SUBST(DL_LIB)
INSTALLPATH="/usr/ucb:$PATH"
AC_PATH_PROGS(INSTALL, ginstall installbsd bsdinst scoinst install, NONE, $INSTALLPATH)
if test $INSTALL = "NONE"
then
echo "- No Install Script found - aborting."
exit 0;
fi
INSTLOPTS="-m 444"
INSTL_EXE_OPTS="-m 555"
INSTL_LIB_OPTS="-m 644"
case "`basename $INSTALL`" in
install|installbsd|scoinst)
INSTLOPTS="-c $INSTLOPTS"
INSTL_EXE_OPTS="-c $INSTL_EXE_OPTS"
INSTL_LIB_OPTS="-c $INSTL_LIB_OPTS";;
esac
echo "- Using $INSTALL"
AC_SUBST(INSTALL)
AC_SUBST(INSTLOPTS)
AC_SUBST(INSTL_LIB_OPTS)
AC_SUBST(INSTL_EXE_OPTS)
dnl Check the option to echo to inhibit newlines.
ECHO_N_OUT=`echo -n "" | wc -c`
ECHO_C_OUT=`echo "\c" | wc -c`
if test "$ECHO_N_OUT" -eq 0; then
DASH_N='-n'
BACKSLASH_C=
else
if test "ECHO_C_OUT" -eq 0; then
DASH_N=
BACKSLASH_C='\\\\c'
else
AC_MSG_ERROR("echo behaviour undetermined")
fi
fi
AC_SUBST(DASH_N)
AC_SUBST(BACKSLASH_C)
AC_PROG_LN_S
AC_PROG_MAKE_SET
AC_PROG_RANLIB
AC_PATH_PROG(find, find)
AC_PATH_PROG(tar, tar)
AC_PATH_PROG(split,split)
AC_CHECK_LIB(c, main)
AC_CHECK_LIB(m, main)
AC_CHECK_LIB(dl, main)
dnl Checks for header files.
AC_HEADER_STDC
AC_CHECK_HEADERS(sys/param.h pwd.h)
dnl Checks for typedefs, structures, and compiler characteristics.
dnl Check for any "odd" conditions
dnl Checks for library functions.
AC_CHECK_FUNCS(stricmp)
dnl Check for X libraries
dnl Check for X library
AC_OUTPUT(GNUmakefile Makefile.global)
* Re: [INTERFACES] Re: Just some unfinished stuff.
1998-10-03 08:01 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-10-04 20:59 ` Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-04 23:06 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 06:05 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 2 replies; 14+ messages in thread
From: Gerald Gryschuk @ 1998-10-04 20:59 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
Thomas G. Lockhart wrote:
> OK, I've gotten your e-mails, and so now I understand where we are
> starting from (maybe :). v6.3 had some brain-damage on the automatic
> platform detection (or didn't try at all). Let me send you my patched
> version of configure.in so you are starting with something closer to the
> v6.4 behavior.
>
> I'm also going to assume that I've got the most recent versions of
> things, and will integrate and test changes here, then commit to the
> Postgres source tree when we've worked through the configure stuff. Will
> send the complete set to Byron for vetting at the same time, and we can
> commit patches as he likes.
>
> Uh, so here it is the configure.in...
>
> - Tom
I tried this new configure.in and it works the way I expected. The
PSQLODBC setting in Makefile.global
gets set to /usr/local/pgsql. I didn't try to make install but I see no
reason this shouldn't
work by putting the files where I expect them(i.e. headers should go to
/usr/local/pgsql/include/iodbc).
The above worked whether I configure'd from the psqlodbc directory
embedded in the 6.3 distribution or from the top level
Postgres 'src' directory. So... are you still having
problems with the 'make install' trying to use '/usr/local' when
your building within the Postgres distribution? If you are, there
is one possible explanation, although I don't see why this
would happen. The psqlodbc configure script checks that the
variable 'prefix' is set to 'NONE' if it's anything else
it will use that prefix. Maybe somehow the 'prefix' variable
is being set to '/usr/local'? The version of configure I'm using
was generated by autoconf 2.12. Maybe a different version of
autoconf causes this prefix variable to be set to something
other than 'NONE' on entry to the configure script. Note that
I was working from the observed behaviour that 'prefix' was
only set to something other than 'NONE' if the user specifically
supplied the '--prefix=' on the './configure' command line.
You should be able to check this by putting an
'echo $prefix'
at the top of your configure.in and see what it spits out.
By the way, something's up with the html docs you sent. Netscape
version 4.05 refuses to display them. What's the magic command
to regenerate them from the sgml source?
--
Gerald Gryschuk
gerald.gryschuk@home.com
MidNightOil Consulting - "We burn the midnight oil so you don't have
to."
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [INTERFACES] Re: Just some unfinished stuff.
1998-10-03 08:01 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-04 20:59 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
@ 1998-10-04 23:06 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 0 replies; 14+ messages in thread
From: Thomas G. Lockhart @ 1998-10-04 23:06 UTC (permalink / raw)
To: Gerald Gryschuk <gerald.gryschuk@home.com>; +Cc: Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
> I tried this new configure.in and it works the way I expected. The
> PSQLODBC setting in Makefile.global gets set to /usr/local/pgsql. I
> didn't try to make install but I see no reason this shouldn't
> work by putting the files where I expect them(i.e. headers should go
> to /usr/local/pgsql/include/iodbc).
I'll try again and let you know...
> By the way, something's up with the html docs you sent. Netscape
> version 4.05 refuses to display them. What's the magic command
> to regenerate them from the sgml source?
No way. They must have gotten munged in the mailing since I'm using the
same browser and it works fine. In fact my reader displayed them in the
mail message itself, and allowed me to save them to a file.
The "magic command" involves reading the v6.3 (or newer) guide to the
docs which has a couple of procedures for installing jade, style sheets,
and support code. It isn't always trivial, though the rpm packaging if
you're running on Linux makes it pretty easy.
I'll send a tar file for you if you still need to see the current
results.
- Tom
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [INTERFACES] Re: Just some unfinished stuff.
1998-10-03 08:01 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-04 20:59 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
@ 1998-10-05 06:05 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 14:15 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 15:23 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <ggryschuk@scf.sk.ca>
1 sibling, 2 replies; 14+ messages in thread
From: Thomas G. Lockhart @ 1998-10-05 06:05 UTC (permalink / raw)
To: Gerald Gryschuk <gerald.gryschuk@home.com>; +Cc: Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
> > OK, I've gotten your e-mails, and so now I understand where we are
> > starting from (maybe :). v6.3 had some brain-damage on the automatic
> > platform detection (or didn't try at all).
> I tried this new configure.in and it works the way I expected.
OK, I went back and re-read your e-mails. I'd missed the details of the
one which described the changes I should put in to the main configure.in
and Makefile.global.in files. So I put those in, and...
Things seem to configure nicely, except that it is still trying to put
the odbc.h file into /usr/local/include rather than my actual Postgres
directory area /opt/postgres/current/include.
I'm not familiar with autoconf, so if you have any ideas let me know.
The alternative is for us to commit this to the cvs tree and let others
have a chance to look at it and make the corrections.
I hate sitting on these patches for any longer. Let me know if you think
I _shouldn't_ commit them to cvs as an "almost ready to go" set of code.
I'll go through and change WINDOWS to WIN32 beforehand.
Comments?
- Tom
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [INTERFACES] Re: Just some unfinished stuff.
1998-10-03 08:01 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-04 20:59 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-05 06:05 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-10-05 14:15 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 0 replies; 14+ messages in thread
From: Thomas G. Lockhart @ 1998-10-05 14:15 UTC (permalink / raw)
To: Gerald Gryschuk <gerald.gryschuk@home.com>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
> Things seem to configure nicely, except that it is still trying to put
> the odbc.h file into /usr/local/include rather than my actual Postgres
> directory area /opt/postgres/current/include.
Alright, I think I'm on the right track...
I've put a conditional include into the postodbc GNUmakefile.in to load
the Postgres Makefile.global if available. I've added a couple of
environment variables to that makefile to point to the right
installation locations, so if the odbc code is in the Postgres main tree
those locations determined locally are overridden by the main
installation parameters.
btw, you asked me to let you know if the interfaces/ area for psqlodbc
is _not_ named "psqlodbc". It isn't; it's always (afaik) been named
interfaces/odbc.
OK, so I've made some substantial changes to the source code and build
environment, and it now doesn't barf when the installation account is
not root, and it seems to do the right thing overall. I'll make the
WINDOWS->WIN32 changes, remove a few unused variables which gcc
complains about, and send you both a big tarball.
I'll commit the tarball to the Postgres distribution soon after that
unless I hear objections.
Talk to you soon...
- Tom
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [INTERFACES] Re: Just some unfinished stuff.
1998-10-03 08:01 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-04 20:59 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-05 06:05 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-10-05 15:23 ` Gerald Gryschuk <ggryschuk@scf.sk.ca>
1998-10-05 15:06 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 1 reply; 14+ messages in thread
From: Gerald Gryschuk @ 1998-10-05 15:23 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Gerald Gryschuk <gerald.gryschuk@home.com>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
Doh! I hate it when I do that, here the same message, this time replied
to All.
Thomas G. Lockhart wrote:
> OK, I went back and re-read your e-mails. I'd missed the details of the
> one which described the changes I should put in to the main configure.in
> and Makefile.global.in files. So I put those in, and...
>
> Things seem to configure nicely, except that it is still trying to put
> the odbc.h file into /usr/local/include rather than my actual Postgres
> directory area /opt/postgres/current/include.
Did you try putting 'echo $prefix' at the beginning of the odbc
configure.in
and rerunning autoconf on it? As I said previously this should spit out
the
prefix that is set before the rest of the odbc configure is run.
Other than the prefix being set prematurely
I can't think of any reason for this to fail. On the other hand given
that
your postgres directory is other than /usr/local/pgsql you must be
supplying
a --prefix on the Postgres configure command line right? If not please
explain how your getting your distribution into that directory.
Beyond this the only other thing is to check the odbc
Makefile.global.in.
Find the line that sets PSQLODBC and make sure it looks like this,
PSQLODBC=@prefix@
I don't recall sending out a Makefile.global.in that didn't have this
but maybe I made I did.
>
> I'm not familiar with autoconf, so if you have any ideas let me know.
> The alternative is for us to commit this to the cvs tree and let others
> have a chance to look at it and make the corrections.
The only other thing I can think of is rather "drastic". Rather than
sending me all of v6.4 so I can try it myself just send me the 6.4
configure.in,Makefile.global.in and GNUmakefile.in so I can have
a look at them.
>
> I hate sitting on these patches for any longer. Let me know if you think
> I _shouldn't_ commit them to cvs as an "almost ready to go" set of code.
> I'll go through and change WINDOWS to WIN32 beforehand.
Well you can if you want to but I really would like to get this fixed
first, but you have a dead line so do what you think is best.
--
Gerald Gryschuk(ggryschuk@scf.sk.ca)
Programmer Analyst
Saskatoon Cancer Centre
((306)655-2746)
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [INTERFACES] Re: Just some unfinished stuff.
1998-10-03 08:01 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-04 20:59 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-05 06:05 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 15:23 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <ggryschuk@scf.sk.ca>
@ 1998-10-05 15:06 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 17:07 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 20:36 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <ggryschuk@scf.sk.ca>
0 siblings, 2 replies; 14+ messages in thread
From: Thomas G. Lockhart @ 1998-10-05 15:06 UTC (permalink / raw)
To: Gerald Gryschuk <ggryschuk@scf.sk.ca>; +Cc: Gerald Gryschuk <gerald.gryschuk@home.com>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
> Did you try putting 'echo $prefix' at the beginning of the odbc
> configure.in and rerunning autoconf on it? As I said previously this
> should spit out the prefix that is set before the rest of the odbc
> configure is run.
> Other than the prefix being set prematurely
> I can't think of any reason for this to fail. On the other hand given
> that your postgres directory is other than /usr/local/pgsql you must
> be supplying a --prefix on the Postgres configure command line right?
> If not please explain how your getting your distribution into that
> directory.
Ah! That's the source of our confusion! I install into
/opt/postgres/current
rather than into /usr/local, but do so by setting the PGROOT environment
variable. I never have to specify any configure command-line options
when I build. Which is a good thing since I sometimes build several
times in a session as I'm developing backend code...
Now that I think about it, I also set PGLIB, so should make sure that
the odbc installation uses that rather than POSTGRESDIR/lib.
> Beyond this the only other thing is to check the odbc
> Makefile.global.in.
> Find the line that sets PSQLODBC and make sure it looks like this,
> PSQLODBC=@prefix@
> I don't recall sending out a Makefile.global.in that didn't have this
> but maybe I made I did.
It does look like this, but the top of configure.in has the line
AC_PREFIX_DEFAULT(/usr/local)
which pretty much sets everything which follows, and which is an
unconditional assignment. So without command-line switches, that's where
things went before my changes.
> The only other thing I can think of is rather "drastic". Rather than
> sending me all of v6.4 so I can try it myself just send me the 6.4
> configure.in,Makefile.global.in and GNUmakefile.in so I can have
> a look at them.
I will send you the 6.4 configure.in, Makefile.global.in, _and_ my
current interfaces/odbc directory. We need to make sure we are working
from the same set of complete sources so we don't drop any work.
The only thing which still annoys me is having to carry the template
directory inside interfaces/odbc. But I agree that it would be best to
have the Postgres tree carrying the full psqlodbc sources so that
someone can pick up just that part and carry it do a different client.
I've thought about having a "make standalone" which creates a tarball
with the template files included, but let's keep it simple (as-is) for
this release.
- Tom
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [INTERFACES] Re: Just some unfinished stuff.
1998-10-03 08:01 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-04 20:59 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-05 06:05 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 15:23 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <ggryschuk@scf.sk.ca>
1998-10-05 15:06 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-10-05 17:07 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 0 replies; 14+ messages in thread
From: Thomas G. Lockhart @ 1998-10-05 17:07 UTC (permalink / raw)
To: Gerald Gryschuk <ggryschuk@scf.sk.ca>; Gerald Gryschuk <gerald.gryschuk@home.com>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
> Ah! That's the source of our confusion! I install into
> /opt/postgres/current
> rather than into /usr/local, but do so by setting the PGROOT
> environment variable.
Well, almost right. I actually have a Makefile.custom in src/ which
looks like:
# Makefile.custom
# Thomas Lockhart 1998-03-01
POSTGRESDIR= /opt/postgres/current
CFLAGS+= -m486 # -g -O0
YFLAGS+= -v
USE_TCL= true
TCL_LIB= -ltcl
X_LIBS= -L/usr/X11/lib
TK_LIB= -ltk
# documentation
HSTYLE= /home/tgl/SGML/db118.d/docbook/html
PSTYLE= /home/tgl/SGML/db118.d/docbook/print
which is where the POSTGRESDIR is actually coming from.
- Tom
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [INTERFACES] Re: Just some unfinished stuff.
1998-10-03 08:01 ` Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-04 20:59 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-05 06:05 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 15:23 ` Re: [INTERFACES] Re: Just some unfinished stuff. Gerald Gryschuk <ggryschuk@scf.sk.ca>
1998-10-05 15:06 ` Re: [INTERFACES] Re: Just some unfinished stuff. Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-10-05 20:36 ` Gerald Gryschuk <ggryschuk@scf.sk.ca>
1 sibling, 0 replies; 14+ messages in thread
From: Gerald Gryschuk @ 1998-10-05 20:36 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Gerald Gryschuk <gerald.gryschuk@home.com>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
Thomas G. Lockhart wrote:
> Ah! That's the source of our confusion! I install into
> /opt/postgres/current
> rather than into /usr/local, but do so by setting the PGROOT environment
> variable. I never have to specify any configure command-line options
> when I build. Which is a good thing since I sometimes build several
> times in a session as I'm developing backend code...
No this shouldn't have mattered, I was trying to write the configure
script around the fact people might not install to /usr/local/pgsql.
However, I don't see how PGROOT and PGLIB get in here. I looked at
the 6.4 files you sent and back at the 6.3 files and none of them
(that I could see) make reference to PGROOT etc. So... is this something
new or what? How do these environment variables override anything, maybe
in the Postgres distribution Makefile.global.in that you didn't send me?
>
> Now that I think about it, I also set PGLIB, so should make sure that
> the odbc installation uses that rather than POSTGRESDIR/lib.
Well I think I have a more "comprehensive" solution. Not that yours is
bad. But it misses one semi-important file, the odbcinst.ini. Your
changes
will leave its installation directory unchanged. So the configure.in
file
you sent me would still cause it to be installed in /usr/local/share
even
with your changes.
More below.
>
> It does look like this, but the top of configure.in has the line
>
> AC_PREFIX_DEFAULT(/usr/local)
>
> which pretty much sets everything which follows, and which is an
> unconditional assignment. So without command-line switches, that's where
> things went before my changes.
O.k. I see the problem now. The configure.in file that you sent was
based
on the first version I sent you. The second configure.in has changes
specifically
meant to overcome the problem your seeing, why this didn't occur to me
before I don't know. However, the changes I made to configure.in still
don't take into
account using the PGROOT etc. environment variables, so I had to make
changes to
the Makefile.global.in. I would be much happier if you could explain
exactly how these override anything.
Anyway, again see below for more on this.
> The only thing which still annoys me is having to carry the template
> directory inside interfaces/odbc. But I agree that it would be best to
> have the Postgres tree carrying the full psqlodbc sources so that
> someone can pick up just that part and carry it do a different client.
> I've thought about having a "make standalone" which creates a tarball
> with the template files included, but let's keep it simple (as-is) for
> this release.
Ask and you shall receive. I've made some more changes, had to anyway to
fix
your other problems. Note that I removed your changes to the GNUmakefile
for
the reason I mentioned above. I moved the possible use of PGROOT and
PGLIB to
the odbc Makefile.global using the only manner that I could think the
Postgres distribution files do it. As I said I'm still in a fog as to
how they exactly get used in the Postgres distribution but I think I
made
a good surmise.
Regardless, I had to make changes to the configure.in to fix the root
problem.
I also made changes so that we don't have to carry the templates
directory
around. Basically I added a variable to the odbc configure.in called
TEMPLATEDIR.
Depending on where the source is being built this will get set to
either,
TEMPLATEDIR=../../template (integrated build)
or
TEMPLATEDIR=./template (standalone, requires that the template
directory
be in the same directory as the odbc source)
I than simply added a variable SOURCES to the GNUmakefile.in which is a
list of
all the source files that are in the odbc directory, including the
Windows build
files etc.
Lastly I simply added the targets 'standalone' and 'integrated'.
'standalone' will
create a tar file with all the files in SOURCES than it backs up to the
Postgres
src directory and appends the Postgres 'template' directory.
'integrated' simply does
the first step.
Note that I also added a target 'distclean' which does 'clean' plus gets
rid of the
config.h GNUmakefile and Makefile.global.
Lastly could you please remove the READMEBYRONANDTHOMAS.txt file from
the distribution,
that was meant to be for your eyes only and than deleted or moved
anyway.
The changes I made can be found in the attached files,
configure.in,GNUmakefile.in
and Makefile.global.in.
After copying these files to the 'interfaces/odbc' directory don't
forget to do
an autoconf.
By the way you might like to do a 'make integrated', copy the resultant
tarball to any directory outside the Postgres distribution and see what
happens
when you go to configure it. Either that or just read the configure.in.
Oh yeah, do you think were ready to get rid of the old
Makefile/Makefile.unx stuff. If
you think we are maybe you shouldn't leave them in the release.
--
Gerald Gryschuk(ggryschuk@scf.sk.ca)
Programmer Analyst
Saskatoon Cancer Centre
((306)655-2746)
Attachments:
GNUmakefile.in (text/plain, 3.9K) download
#-------------------------------------------------------------------------
#
# Makefile.inc--
# Build and install postgres.
#
# Copyright (c) 1994, Regents of the University of California
#
#
# IDENTIFICATION
# $Header: /usr/local/cvsroot/pgsql/src/GNUmakefile.in,v 1.24 1998/01/17 23:39:05 scrappy Exp $
#
#-------------------------------------------------------------------------
@SET_MAKE@
NAME = psqlodbc
SRCDIR=@srcdir@
ODBCSRCDIR=@srcdir@
include $(ODBCSRCDIR)/Makefile.global
include Version.mk
PORTNAME= @PORTNAME@
FIND = @find@
# assuming gnu tar and split here
TAR = @tar@
SPLIT = @split@
ifeq ($(PORTNAME), linux)
install-shlib-dep := install-shlib
shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
LDFLAGS_SL = -shared -soname lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
LDFLAGS_SL += -Bsymbolic $(LDFLAGS) -lc -lm
CFLAGS += -I. $(CFLAGS_SL)
endif
ifeq ($(PORTNAME), bsd)
ifdef BSD_SHLIB
install-shlib-dep := install-shlib
shlib := lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
LDFLAGS_SL = -x -Bshareable -Bforcearchive $(LDFLAGS)
CFLAGS += -I. $(CFLAGS_SL)
endif
endif
SOURCES = *.c *.h *.in Config.mk Makefile Makefile.unx README.Linux \
TODO.txt Version.mk config.guess config.sub configure \
install-sh license.txt notice.txt odbcinst.ini patch \
psqlodbc.aps psqlodbc.def psqlodbc.mak psqlodbc.mdp \
psqlodbc.ncb psqlodbc.rc readme.txt
OBJECTS = info.o bind.o columninfo.o connection.o convert.o drvconn.o \
environ.o execute.o lobj.o misc.o options.o \
pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o \
gpps.o tuple.o tuplelist.o dlg_specific.o $(OBJX)
CFLAGS += @DEFS@
all: libpsqlodbc.a $(shlib)
libpsqlodbc.a: $(OBJECTS)
$(AR) $(AROPT) libpsqlodbc.a $(OBJS)
$(RANLIB) libpsqlodbc.a
$(shlib): $(OBJECTS)
$(LD) $(LDFLAGS_SL) $(OBJECTS) \
-o $(shlib) $(LIBS)
.PHONY: beforeinstall-headers beforeinstall-ini install-headers
.PHONY: install install-libpsqlodbc install-shlib-dep
install: install-headers install-libpsqlodbc install-ini $(install-shlib-dep)
install-headers: beforeinstall-headers isql.h isqlext.h iodbc.h
$(INSTALL) $(INSTLOPTS) iodbc.h $(HEADERDIR)/iodbc/iodbc.h
$(INSTALL) $(INSTLOPTS) isql.h $(HEADERDIR)/iodbc/isql.h
$(INSTALL) $(INSTLOPTS) isqlext.h $(HEADERDIR)/iodbc/isqlext.h
beforeinstall-headers:
@if [ ! -d $(HEADERDIR)/iodbc ]; then mkdir $(HEADERDIR)/iodbc; fi
beforeinstall-ini:
@if [ ! -d $(ODBCINST) ]; then mkdir $(ODBCINST); fi
install-libpsqlodbc: libpsqlodbc.a
$(INSTALL) $(INSTL_LIB_OPTS) libpsqlodbc.a $(DESTDIR)$(LIBDIR)/lib$(NAME).a
install-shlib: $(shlib)
$(INSTALL) $(INSTL_LIB_OPTS) $(shlib) $(DESTDIR)$(LIBDIR)/$(shlib)
rm -f $(DESTDIR)$(LIBDIR)/lib$(NAME)$(DLSUFFIX)
rm -f $(DESTDIR)$(LIBDIR)/lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
cd $(DESTDIR)$(LIBDIR) && $(LN_S) -f $(shlib) lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
cd $(DESTDIR)$(LIBDIR) && $(LN_S) -f lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) lib$(NAME)$(DLSUFFIX)
install-ini: beforeinstall-ini odbcinst.ini
$(INSTALL) $(INSTL_LIB_OPTS) odbcinst.ini $(ODBCINST)/odbcinst.ini
depend dep:
$(CC) -MM *.c >depend
.PHONY: clean
clean:
-rm -f lib$(NAME).a $(shlib) $(OBJECTS) lib$(NAME)$(DLSUFFIX)
-rm -f config.log config.cache config.status
.PHONY: distclean
distclean: clean
-rm -f config.h GNUmakefile Makefile.global
.PHONY: standalone
standalone:
-rm -f psqlodbc-$(SO_MAJOR_VERSION)$(SO_MINOR_VERSION).tar.gz
tar -cf psqlodbc-$(SO_MAJOR_VERSION)$(SO_MINOR_VERSION).tar $(SOURCES)
tar -r -C ../.. -f psqlodbc-$(SO_MAJOR_VERSION)$(SO_MINOR_VERSION).tar template
gzip psqlodbc-$(SO_MAJOR_VERSION)$(SO_MINOR_VERSION).tar
.PHONY: integrated
integrated:
-rm -f psqlodbc-$(SO_MAJOR_VERSION)$(SO_MINOR_VERSION)-int.tar.gz
tar -cf psqlodbc-$(SO_MAJOR_VERSION)$(SO_MINOR_VERSION)-int.tar $(SOURCES)
gzip psqlodbc-$(SO_MAJOR_VERSION)$(SO_MINOR_VERSION)-int.tar
Makefile.global.in (text/plain, 4.5K) download
#----------------------------------------------------------------------------
#
# Makefile.global--
# global configuration for the Makefiles
#
# Copyright (c) 1994, Regents of the University of California
#
#
# IDENTIFICATION
# $Header$
#
# NOTES
# This is derived from the main Postgres makefile.
#
# When running standalone:
# To override the default setting, create a Makefile.custom in this
# directory and put your defines there. (Makefile.custom is included
# near the end of this file). Sometimes, a variable gets set in
# Makefile.global after Makefile.custom has been included, so you can't
# simply set that variable in Makefile.custom. In those cases, there is
# often another variable (like CUSTOM_COPT) that you can set in
# Makefile.custom that influences the later setting of the true variable
# of interest (like CFLAGS) by Makefile.global.
#
#
# If you change any of these defines you probably have to
# make clean; make
# since no dependencies are created for these. (of course you can
# be crafty and check what files really depend on them and just remake
# those).
#
# Before including this file, you must set the SRCDIR variable to the
# path of the top of the Postgres source tree (the directory that
# contains this file).
#
#-------------------------------------------------------------------------
##############################################################################
#
# CONFIGURATION SECTION
#
# Following are settings pertaining to the postgres build and
# installation.
# of the port.
#
# Ignore LINUX_ELF if you're not using Linux. But if you are, and you're
# compiling to a.out (which means you're using the dld dynamic loading
# library), set LINUX_ELF to null in Makefile.custom.
LINUX_ELF= true
#
# Ignore BSD_SHLIB if you're not using one of the BSD ports. But if you
# are, and it's one that doesn't have shared libraries (NetBSD/vax is an
# example of this), set BSD_SHLIB to null in Makefile.custom.
BSD_SHLIB= true
# For convenience, PSQLODBCDIR is where BINDIR, and LIBDIR
# and other target destinations are rooted. Of course, each of these is
# changable separately.
ifdef PGROOT
PSQLODBCDIR = $(PGROOT)
else
PSQLODBCDIR= @prefix@
endif
# Where the postgres executables live (changeable by just putting them
# somewhere else and putting that directory in your shell PATH)
BINDIR= $(PSQLODBCDIR)/bin
# Where libpsqlodbc.a gets installed. You must put it where your loader will
# look for it if you wish to use the -lpq convention. Otherwise you
# can just put the absolute pathname to the library at the end of your
# command line.
ifdef PGLIB
LIBDIR=$(PGLIB)
else
LIBDIR= $(PSQLODBCDIR)/lib
endif
# Where the man pages (suitable for use with "man") get installed.
POSTMANDIR= $(PSQLODBCDIR)/man
# Where the formatted documents (e.g., the reference manual) get installed.
POSTDOCDIR= $(PSQLODBCDIR)/doc
# Where the header files necessary to build frontend programs get installed.
HEADERDIR= $(PSQLODBCDIR)/include
# Where the odbcinst.ini file will be placed
ifdef PGROOT
ODBCINST=$(PGROOT)
else
ODBCINST= @ODBCINSTDIR@
endif
##############################################################################
#
# FEATURES
#
# To disable a feature, comment out the entire definition
# (that is, prepend '#', don't set it to "0" or "no").
##############################################################################
#
# Installation.
#
# For many ports, INSTALL is overridden below.
INSTALL= @INSTALL@
RANLIB= @RANLIB@
INSTLOPTS= @INSTLOPTS@
INSTL_EXE_OPTS= @INSTL_EXE_OPTS@
INSTL_LIB_OPTS= @INSTL_LIB_OPTS@
##############################################################################
#
# For building shell scripts:
#
# For many ports, these are overridden below.
# DASH_N is what we put before the text on an echo command when we don't
# want a trailing newline. BACKSLASH_C is what we put at the end of the
# string on a echo command when we don't want a trailing newline. On
# some systems, you do echo -n "no newline after this", while on others
# you do echo "no newline after this\c".
DASH_N= @DASH_N@
BACKSLASH_C= @BACKSLASH_C@
#-------------------------------------------------------------
# See the subdirectory template for default settings for these
#-------------------------------------------------------------
CC= @CC@
AROPT= @AROPT@
CFLAGS= -I$(ODBCSRCDIR) @CPPFLAGS@ @CFLAGS@
CFLAGS_SL= @SHARED_LIB@
LDFLAGS= @LDFLAGS@ @LIBS@
DLSUFFIX= @DLSUFFIX@
LN_S = @LN_S@
ifeq ($(CC), gcc)
CFLAGS+= -Wall -Wmissing-prototypes
endif
ifdef COPT
CFLAGS+= $(COPT)
endif
configure.in (text/plain, 7.9K) download
dnl Process this file with autoconf to produce a configure script.
AC_INIT(bind.c)
AC_PREFIX_DEFAULT(/usr/local)
if test -d ../../interfaces
then
TEMPLATEDIR=../../template
if test "$prefix" = "NONE"
then
ac_default_prefix=/usr/local/pgsql
ODBCINSTDIR=$ac_default_prefix
else
ODBCINSTDIR=$prefix
fi
else
TEMPLATEDIR=./template
if test "$prefix" = "NONE"
then
ODBCINSTDIR=$ac_default_prefix/share
else
ODBCINSTDIR=$prefix
fi
fi
echo "*** configuring psqlodbc ***"
AC_CANONICAL_HOST
case "$host_os" in
solaris*)
case "$host_cpu" in
sparc) os=sparc_solaris ;;
i386) os=i386_solaris ;;
esac ;;
sunos*) os=sunos4 ;;
aux*) os=aux ;;
linux*) os=linux ;;
bsdi*) os=bsdi ;;
freebsd*|netbsd*|openbsd*) os=bsd ;;
dgux*) os=dgux ;;
aix*) os=aix ;;
nextstep*) os=nextstep ;;
ultrix*) os=ultrix4 ;;
irix*) os=irix5 ;;
hpux*) os=hpux ;;
osf*) os=alpha ;;
sco*) os=sco ;;
machten*) os=machten ;;
cygwin*) os=win ;;
sysv4.2*)
case "$host_vendor" in
univel) os=univel ;;
*) os=unknown ;;
esac ;;
sysv4*) os=svr4 ;;
*) echo ""
echo "*************************************************************"
echo "configure does not currently recognize your operating system,"
echo "therefore you must do a manual configuration of:"
echo "$host_os"
echo "Please contact scrappy@hub.org to see about rectifying this, "
echo "including the above 'checking host system type...' line "
echo "*************************************************************"
echo ""
exit;;
esac
PORTNAME=${os}
AC_SUBST(PORTNAME)
echo "checking echo setting..."
if echo '\c' | grep -s c >/dev/null 2>&1
then
ECHO_N="echo -n"
ECHO_C=""
else
ECHO_N="echo"
ECHO_C='\c'
fi
dnl cat <<EOT
dnl **************************************************************
dnl Postodbc v0.0250 Installation Program
dnl
dnl Welcome to the new improved Postodbc installation program.
dnl This configuration program is for version 0.0250 of the
dnl Postodbc software.
dnl
dnl EOT
dnl this part selects the template from the one in the
dnl template directory.
dnl if test "X$with_template" != "X"
dnl then
dnl TEMPLATE=template/$with_template
dnl else
dnl TEMPLATE=DO_NOT_CHANGE_THIS_INVALID_FILENAME
dnl fi
AC_MSG_CHECKING(setting template to)
AC_ARG_WITH(template,
[ --with-template=TEMPLATE
use operating system template file
see template directory],
[ TEMPLATE=$withval ],
[ host_no_ver=`echo "$host" | sed 's/[[0-9.]]*$//'`
GUESS=`grep "$host_no_ver" $TEMPLATEDIR/.similar | sed 's/.*=//' | tail -1`
if test "$GUESS"
then TEMPLATE="$GUESS"
else TEMPLATE=`uname -s | tr A-Z a-z`
fi
])
AC_MSG_RESULT($TEMPLATE)
if test ! -d "$TEMPLATEDIR"
then
cat << EOT
**************************************************************
You seem to be missing the template directory needed by
configure. If you just copied the source from the Postgres
distribution you should instead have issued the command
'make standalone' which would have built a distribution
containing the necessary template directory. The other
option is that your trying to build from the source
which is meant to be placed in the Postgres distribution
directory 'interfaces/odbc'. Depending on your case either get the
standalone source from the following Web site:
www.insightdist.com/psqlodbc/
or issue the 'make standalone' command from the
'interfaces/odbc' directory of your Postgres Distribution,
or copy the distribution file you have to your Postgres
distribution's 'interfaces/odbc' directory and try
again.
If neither of these is the case than please complain
kindly to the maintainers, their e-mail addresses can
be found in the Readme files.
*************************************************************
EOT
exit
else
if test ! -f "$TEMPLATEDIR/$TEMPLATE"
then
cat <<EOT
Please select a template from the ones listed below. If no
template is available, then select the 'generic' one and
consider emailling scrappy@hub.org with the above line which
starts 'checking host system type...'
**************************************************************
EOT
TEMPLATE=generic
GUESS=`grep "^$host_no_ver=" $TEMPLATEDIR/.similar 2>/dev/null`
if test ! "$GUESS"
then host_no_ver=`echo "$host" | sed 's/[[0-9.]]*$//'`
GUESS=`grep "$host_no_ver" $TEMPLATEDIR/.similar 2>/dev/null`
fi
if test "$GUESS"
then
TEMPLATE=`echo $GUESS | sed 's/.*=//'`
fi
export TEMPLATE
ls $TEMPLATEDIR
echo "**************************************************************"
$ECHO_N "Appropriate template file { $TEMPLATE }: $ECHO_C"
read a
if test "$a." != "."
then
TEMPLATE=$a
fi
if test ! -f $TEMPLATEDIR/$TEMPLATE
then
echo "You must choose an appropriate template file."
exit
fi
fi
fi
TEMPLATE=$TEMPLATEDIR/$TEMPLATE
export TEMPLATE
echo ""
AROPT=`grep '^AROPT:' $TEMPLATE | awk -F: '{print $2}'`
SHARED_LIB=`grep '^SHARED_LIB:' $TEMPLATE | awk -F: '{print $2}'`
CFLAGS=`grep '^CFLAGS:' $TEMPLATE | awk -F: '{print $2}'`
SRCH_INC=`grep '^SRCH_INC:' $TEMPLATE | awk -F: '{print $2}'`
SRCH_LIB=`grep '^SRCH_LIB:' $TEMPLATE | awk -F: '{print $2}'`
DLSUFFIX=`grep '^DLSUFFIX:' $TEMPLATE | awk -F: '{print $2}'`
DL_LIB=`grep '^DL_LIB:' $TEMPLATE | awk -F: '{print $2}'`
CC=`grep '^CC:' $TEMPLATE | awk -F: '{print $2}'`
LIBS=`grep '^LIBS:' $TEMPLATE | awk -F: '{print $2}'`
a=$SRCH_INC
CPPFLAGS=`echo "$a" | sed 's@ *@ @g; s@^\([[^ ]]\)@-I\1@; s@ \([[^ ]]\)@ -I\1@g'`
export CPPFLAGS
echo "- setting CPPFLAGS=$CPPFLAGS"
a=$SRCH_LIB
LDFLAGS=`echo "$a" | sed 's@ *@ @g; s@^\([[^ ]]\)@-L\1@; s@ \([[^ ]]\)@ -L\1@g'`
export LDFLAGS
echo "- setting LDFLAGS=$LDFLAGS"
dnl Allow for overriding the default location of the odbcinst.ini
dnl file which is normally ${prefix}/share or ${prefix} if this is
dnl being compiled inside the postgres distribution.
AC_MSG_CHECKING(setting ODBCINST)
AC_ARG_WITH(
odbcinst,
[ --with-odbcinst=<datadir> change default directory for odbcinst.ini],
AC_DEFINE_UNQUOTED(ODBCINST, ${with_odbcinst}) AC_MSG_RESULT($with_odbcinst),
AC_DEFINE_UNQUOTED(ODBCINST, ${ODBCINSTDIR}) AC_MSG_RESULT(${ODBCINSTDIR})
)
if test "X$with_odbcinst" != "X"
then
ODBCINSTDIR=$with_odbcinst
fi
AC_SUBST(ODBCINSTDIR)
if test "X$with_compiler" != "X"
then
CC=$with_compiler
else
AC_PROG_CC
fi
AC_CONFIG_HEADER(config.h)
dnl Checks for programs.
AC_PROG_CPP
AC_SUBST(PORTNAME)
AC_SUBST(LDFLAGS)
AC_SUBST(CPPFLAGS)
AC_SUBST(AROPT)
AC_SUBST(SHARED_LIB)
AC_SUBST(CFLAGS)
AC_SUBST(DLSUFFIX)
AC_SUBST(DL_LIB)
INSTALLPATH="/usr/ucb:$PATH"
AC_PATH_PROGS(INSTALL, ginstall installbsd bsdinst scoinst install, NONE, $INSTALLPATH)
if test $INSTALL = "NONE"
then
echo "- No Install Script found - aborting."
exit 0;
fi
INSTLOPTS="-m 444"
INSTL_EXE_OPTS="-m 555"
INSTL_LIB_OPTS="-m 644"
case "`basename $INSTALL`" in
install|installbsd|scoinst)
INSTLOPTS="-c $INSTLOPTS"
INSTL_EXE_OPTS="-c $INSTL_EXE_OPTS"
INSTL_LIB_OPTS="-c $INSTL_LIB_OPTS";;
esac
echo "- Using $INSTALL"
AC_SUBST(INSTALL)
AC_SUBST(INSTLOPTS)
AC_SUBST(INSTL_LIB_OPTS)
AC_SUBST(INSTL_EXE_OPTS)
dnl Check the option to echo to inhibit newlines.
ECHO_N_OUT=`echo -n "" | wc -c`
ECHO_C_OUT=`echo "\c" | wc -c`
if test "$ECHO_N_OUT" -eq 0; then
DASH_N='-n'
BACKSLASH_C=
else
if test "ECHO_C_OUT" -eq 0; then
DASH_N=
BACKSLASH_C='\\\\c'
else
AC_MSG_ERROR("echo behaviour undetermined")
fi
fi
AC_SUBST(DASH_N)
AC_SUBST(BACKSLASH_C)
AC_PROG_LN_S
AC_PROG_MAKE_SET
AC_PROG_RANLIB
AC_PATH_PROG(find, find)
AC_PATH_PROG(tar, tar)
AC_PATH_PROG(split,split)
AC_CHECK_LIB(c, main)
AC_CHECK_LIB(m, main)
AC_CHECK_LIB(dl, main)
dnl Checks for header files.
AC_HEADER_STDC
AC_CHECK_HEADERS(sys/param.h pwd.h)
dnl Checks for typedefs, structures, and compiler characteristics.
dnl Check for any "odd" conditions
dnl Checks for library functions.
AC_CHECK_FUNCS(stricmp)
dnl Check for X libraries
dnl Check for X library
AC_OUTPUT(GNUmakefile Makefile.global)
end of thread, other threads:[~1998-10-05 20:36 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-10-03 07:39 ` Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:30 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-03 07:42 ` Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-04 16:57 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-03 08:01 ` Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-03 14:00 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-04 20:59 ` Gerald Gryschuk <gerald.gryschuk@home.com>
1998-10-04 23:06 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 06:05 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 14:15 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 15:23 ` Gerald Gryschuk <ggryschuk@scf.sk.ca>
1998-10-05 15:06 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 17:07 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-10-05 20:36 ` Gerald Gryschuk <ggryschuk@scf.sk.ca>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox