Ok, well obviously PHP isn't make'ing because of the missing iodbc.h:

My openlink4 dir (/usr/local/openlink/odbcsdk/include) 
contains: 

isql.h       isqltypes.h  sqlext.h     udbcext.h
isqlext.h    sql.h        sqltypes.h

I just unzipped the Openlink 3.2, and the dir contained:
iodbc.h    isql.h     isqlext.h  udbcext.h
^^^^^^
^^^^^^

In both instances, only lmbrzzzz.taz and lmkozzzz.taz were used to install openlink. I'll try using the v3.2 iodbc.h (and a few other things if that doesn't work).

Well using the old (ver3.2) iodbc.h doesn't work with ver 4 :(

gcc  -I. -I/tmp/php-4.0.2/main -I/tmp/php-4.0.2 -I/tmp/php-4.0.2/main -I/tmp/apache_1.3.17/src/include -I/tmp/apache_1.3.17/src/os/unix -I/tmp/php-4.0.2/Zend -I/tmp/php-4.0.2 -I/tmp/php-4.0.2/ext/mysql/libmysql -I/usr/local/openlink/odbcsdk/include -I/tmp/php-4.0.2/ext/xml/expat/xmltok -I/tmp/php-4.0.2/ext/xml/expat/xmlparse  -DXML_BYTE_ORDER=12 -g -O2  -c internal_functions.c && touch internal_functions.lo
In file included from /tmp/php-4.0.2/ext/odbc/php_odbc.h:115,
                 from internal_functions.c:38:
/usr/local/openlink/odbcsdk/include/udbcext.h:47: warning: `SQL_LEN_DATA_AT_EXEC' redefined
/usr/local/openlink/odbcsdk/include/sqlext.h:250: warning: this is the location of the previous definition
In file included from /usr/local/openlink/odbcsdk/include/sql.h:37,
                 from /usr/local/openlink/odbcsdk/include/isql.h:32,
                 from /tmp/php-4.0.2/ext/odbc/php_odbc.h:113,
                 from internal_functions.c:38:
/usr/local/openlink/odbcsdk/include/sqltypes.h:68: conflicting types for `WORD'
/usr/local/openlink/odbcsdk/include/iodbc.h:25: previous declaration of `WORD'
/usr/local/openlink/odbcsdk/include/sqltypes.h:69: conflicting types for `DWORD'
/usr/local/openlink/odbcsdk/include/iodbc.h:26: previous declaration of `DWORD'
/usr/local/openlink/odbcsdk/include/sqltypes.h:75: redefinition of `BOOL'
/usr/local/openlink/odbcsdk/include/iodbc.h:31: `BOOL' previously declared here
/usr/local/openlink/odbcsdk/include/sqltypes.h:150: redefinition of `HWND'
/usr/local/openlink/odbcsdk/include/iodbc.h:30: `HWND' previously declared here
make[2]: *** [internal_functions.lo] Error 1
make[2]: Leaving directory `/tmp/php-4.0.2/main'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/php-4.0.2/main'
make: *** [all-recursive] Error 1

Modified Openlink3.2 iodbc.h so that it could be used with openlink4:

contents of /usr/local/openlink/odbcsdk/include/iodbc.h now:
##########################################

#ifndef _CONFIG_H
#define _CONFIG_H

# if    !defined(WINDOWS) && !defined(WIN32_SYSTEM)
#  define       _UNIX_

#  include      <stdlib.h>
#  include      <sys/types.h>

#  define       MEM_ALLOC(size) (malloc((size_t)(size)))
#  define       MEM_FREE(ptr)   {if(ptr) free(ptr);}

#  define       STRCPY(t, s)    (strcpy((char*)(t), (char*)(s)))
#  define       STRNCPY(t,s,n)  (strncpy((char*)(t), (char*)(s), (size_t)(n)))
#  define       STRCAT(t, s)    (strcat((char*)(t), (char*)(s)))
#  define       STRNCAT(t,s,n)  (strncat((char*)(t), (char*)(s), (size_t)(n)))
#  define       STREQ(a, b)     (strcmp((char*)(a), (char*)(b)) == 0)
#  define       STRLEN(str)     ((str)? strlen((char*)(str)):0)

#  define       EXPORT
#  define       CALLBACK
#  define       FAR


# endif /* _UNIX_ */

# if    defined(WINDOWS) || defined(WIN32_SYSTEM)

#  include      <windows.h>
#  include      <windowsx.h>

#  ifdef        _MSVC_
#   define      MEM_ALLOC(size) (fmalloc((size_t)(size)))
#   define      MEM_FREE(ptr)   ((ptr)? ffree((PTR)(ptr)):0))
#   define      STRCPY(t, s)    (fstrcpy((char FAR*)(t), (char FAR*)(s)))
#   define      STRNCPY(t,s,n)  (fstrncpy((char FAR*)(t), (char FAR*)(s), (size_t)(n)))
#   define      STRLEN(str)     ((str)? fstrlen((char FAR*)(str)):0)
#   define      STREQ(a, b)     (fstrcmp((char FAR*)(a), (char FAR*)(b) == 0)
#  endif

#  ifdef        _BORLAND_
#   define      MEM_ALLOC(size) (farmalloc((unsigned long)(size))
#   define      MEM_FREE(ptr)   ((ptr)? farfree((void far*)(ptr)):0)
#   define      STRCPY(t, s)    (_fstrcpy((char FAR*)(t), (char FAR*)(s)))
#   define      STRNCPY(t,s,n)  (_fstrncpy((char FAR*)(t), (char FAR*)(s), (size_t)(n)))
#   define      STRLEN(str)     ((str)? _fstrlen((char FAR*)(str)):0)
#   define      STREQ(a, b)     (_fstrcmp((char FAR*)(a), (char FAR*)(b) == 0)
#  endif

# endif /* WINDOWS */

# define        SYSERR          (-1)

# ifndef        NULL
#   define      NULL            ((void FAR*)0UL)
# endif

#endif

##########################################

Compiled OK(version 404sp1); './configure' '--with-openlink=/usr/local/openlink' '--with-mysql' '--with-apache=../apache_1.3.17' '--enable-track-vars' 

Caused This WARNING when make-ing: 

make[3]: Entering directory `/tmp/php-4.0.4pl1/ext/odbc'
gcc  -I. -I/tmp/php-4.0.4pl1/ext/odbc -I/tmp/php-4.0.4pl1/main -I/tmp/php-4.0.4pl1 -I/tmp/apache_1.3.17/src/include -I/tmp/apache_1.3.17/src/os/unix -I/tmp/php-4.0.4pl1/Zend -I/tmp/php-4.0.4pl1/ext/mysql/libmysql -I/usr/local/openlink/odbcsdk/include -I/tmp/php-4.0.4pl1/ext/xml/expat/xmltok -I/tmp/php-4.0.4pl1/ext/xml/expat/xmlparse -I/tmp/php-4.0.4pl1/TSRM  -DXML_BYTE_ORDER=12 -g -O2  -c php_odbc.c && touch php_odbc.lo
In file included from php_odbc.h:128,
                 from php_odbc.c:31:
/usr/local/openlink/odbcsdk/include/udbcext.h:47: warning: `SQL_LEN_DATA_AT_EXEC' redefined
/usr/local/openlink/odbcsdk/include/sqlext.h:250: warning: this is the location of the previous definition

***

Now Apache won't run; NOTHING reported in /etc/httpd/logs - where can i find failure reason?

Trying again with older versions of PHP and Apache.

Compiling Openlink4 with PHP 403sp1 and Apache 1.3.12 using the custom iodbc.h file I have included WORKS "FINE":

as in 
 - it compiles without errors
 - has warning: `SQL_LEN_DATA_AT_EXEC' redefined
 - produces a fully PHP-functional apache webserver

I still cannot manage to properly communicate to talbles using Openlink4, however, I recieve:

SQL error: [OpenLink][ODBC][Driver]Syntax error or access, SQL state 37000 in SQLExecDirect for complex selects such as "SELECT TOP 10 RECORD_NR, StatusField, ExtendedStatusField, PICTURE, SURNAME, FIRSTNAME, FORM, DOB, DESTINATION, EXPIRY FROM (SELECT TOP 10 * FROM WELLGIRLS ORDER BY RECORD_NR ASC,RECORD_NR ASC) ORDER BY RECORD_NR DESC,RECORD_NR DESC"

and for simple selects "SELECT * FROM TABLENAME", i get 

Warning: SQL error: [OpenLink][ODBC][Driver]Driver not capable, SQL state S1C00 in SQLExecDirect in /home/sites/home/web/current/Admin/admin_odbcsetup.php on line 125

The battle continues ... 

- Siggy

Allegedly PHP404sp1 fixes this Openlink problem ... but see bug id http://bugs.php.net/?id=9088&edit=1 for why i couldnt get PHP404sp1 to work with apache :(

Copied contents of /ext/odbc/ of PHP404sp1 and tried compiling this with PHP403sp1 ... Compile fine; but Driver Not Capable error continues.

sorry i'm late... (1 year) ... 
I think teh problem could be the glibc version... 
I have installed php4.2.2(also 4.2.1 and 4.2.3) + 
apache(1.3.27 and the now httpd release at this 
time 2.0.43) in the Red Hat 7.3 version, and 
everithing works fine (except for a problem in the 
Openlink lite version driver for SQL-Server whe 
you make a odbc_exec() call), but when i've tryed 
to install the same configuration in the redhat 
7.2 throws the same make-error taht you comment... 
 
try to update to rh 7.3 (maybe 8.0), or update 
glibc or the lib used to compile... 
 
Sorry if i'm wrong... 
 
Regards Adriano

You need to give more detailed information on what exactly the errors are.  OpenLink works just fine on the three test platforms I'm using, and has worked fine since 4.1 release.  You should really though being using the --with-iodbc flag, as --with-openlink is deprecated.

Yes, OpenLink drivers are glibc sensitive - ensure you are 
using the correct version please.  I've had no problems 
doing several builds of iODBC with PHP4, including the 
latest 4.2.3.

No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".