My huge reply to this thread (which is a problem/solution report) appears below the ==== separator line. If you found this email posting to be
Helpful, please drop me an email.

- Brian

From: Jonathan Leffler
Sent: Wednesday, August 10, 2005 4:53 PM
Cc: DBI Users Mailing List
Subject: Re: Informix DBD build on Windows - Better

-----Original Message-----
On 8/8/05, CAMPBELL, BRIAN D (BRIAN) wrote:

All in all I uncovered 9 bugs in the build process for DBD.
Should I go ahead and publish my findings to this mailing list (DBI

As Ron said ("Publish and Be Damned")

Yes - please post bug reports - preferably with the patches to fix them - to the list. They may help other people; eventually, they'll help me help you.

As discussed wholly separately, t08fork.t failures indicate problems in the test, and t91udts.t failures indicate that the database wasn't as clean as it should be (arguably a test problem in itself). Not dreadfully significant, though both should ideally be fixed.

-----Original Message-----
Sent: Wednesday, August 03, 2005 4:42 PM
To: 'dbi-users@perl.org'

I tried building the recently released Informix DBD 2005.02 today. I apparently have a successful compile and link. But I'm having a major problem on the test. Below is the link input and output, and the first test. All remaining tests look like the first test. Help and suggestions needed. Here's the message I'm getting upon running the first test (and all the rest).

Can't find 'boot_DBD__Informix' symbol in ./Informix.dll

[stuff snipped]

My Environment:
* Windows 2000 [Version 5.00.2195] SP4
* ActiveState Perl v5.8.7 built for MSWin32-x86-multi-thread, Binary build 813 [148120]
* DBI: 1.48
* ESQL: IBM Informix CSDK Version 2.90, IBM Informix-ESQL Version 2.90.TC1
* Microsoft Visual C++ 6.0
* Connection to Informix DB server 9.21.FC4 on an Alpha box running Compaq Tru64 Unix.


This posting documents the problems I had while trying to build the recently
released Informix DBD 2005.02 on Windows.

First of all, the makefile generator produces this notice for Windows systems:

This is a semi-experimental version of Makefile.PL with Win32 (NT)
support. Previous versions have been tested on NT, but there could
still be bugs in this code. Please help save the world by trying
to debug the NT code and reporting the results back to the DBI
Users mailing list.

So once again, here I go, saving the world...

In the documetation below, I use the following "pattern language" for
each problem:
The symptom - the message from the console.
The reason - my best guess on what is causing the symptom.
A workaround (sometimes) - I provided an expediant "Workaround", which
I used to keep going.
A recommended solution - Usually just a description and nothing as fancy
as a real patch.

A preliminary remark: I recently upgraded my Perl to 5.8.7. In doing so,
I took my own previous advice and installed it in "C:\Perl" which I believe
is the default path provided by the ActiveState installer. Previously,
it was installed in "C:\Program Files\Perl", per a local site installation
process. Having that blank char in the Perl path caused all kinds of grief
in previous build attempts, as well documented in my previous post on the
The majority of problems I encountered then had that one root cause.
The build process uses several Perl modules to due some preliminary set
up; these modules were not good at handling spaces in file paths.
Thus, I was able to avoid a class of problems I had encountered previously.
It was also helpful to use my Batch file tip and CPAN/Config.pm tip as
described near the bottom of that posting.

OK, now on to the problem set...

Problem 1


When running the makefile generator (Makefile.pl):

This warning occurs:

Note: Some of the code here or in ESQL/C may work properly if
%INFORMIXDIR% contains spaces.

Then I got this:

'C:\Program' is not recognized as an internal or external command, operable program or batch file.


The cautionary note is true about the "spaces" concern, but is mistaken
about the env var when running under Windows. It didn't help when I changed
my INFORMIXDIR var from:
C:\Program Files\Informix\Client-SDK

The script's path of execution for Windows does not look at the %INFORMIXDIR%
env var. Instead, the script locates the Informix folder value by searching
all folders in the PATH list, testing if ESQL.EXE is located in any of them,
and then trims \BIN from the discovery.

The problem with this "PATH search" approach is that the PATH is typically
set by the Informix SDK installation using the file name with blanks.


One can update their PATH setting to remove the blanks or do what I did.
I put the perl Makefile.pl in a batch script, and temporarily altered the
PATH list to include my preferred path as follows. It used my path instead
of the installation path, because mine comes first.

SET INFORMIXDIR=C:\Progra~1\Informix\Client-SDK
perl Makefile.pl

Recommended solution:

When running under Windows:
The Makefile.pl script should consider using INFORMIXDIR, if present.
The script should at least test for blanks and complain when blanks are found.
Or better yet, translate the path to the alternate 8.3 "blankless" name
(Win32::GetShortPathName may be of help here).

Problem 2


When running the makefile:

dbdimp.ec(32) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory


File dbdimp.ec has this, which doesn't compile in MSVC.

#include <unistd.h>

Recommended solution:

Replace the line with the following solution found in ixblob.ec.

#ifdef _WIN32
#include <io.h>
#include <unistd.h>
#endif /* _WIN32 */

Problem 3


When running the makefile:

ixblob.ec(126) : error C2065: 'F_OK' : undeclared identifier


File ixblob.ec refers to the undefined symbol F_OK, whis is passed to the
function access (declared in io.h). My verions of MSVC doesn't define the

Recommended solution:

Add this to the file. The definition comes from my Unix platform in
<sys/access.h>. It would seem that the same defined value works on Windows

#ifdef _WIN32
#define F_OK 00 /* E_ACC does file exist */
#endif /* _WIN32 */

Problem 4


When running the makefile:

'INFORMIXC' is not recognized as an internal or external command, operable program or batch file.


This line is in the makefile.


This defines a system command which includes the INFORMIXC and ESQLLD as
Unix-style shell parameters preceding the command $(LDCMD). A reference to
LD is here in the Informix.dll target $(INST_DYNAMIC). Shell parameters
don't work on Windows.



Remove the paramaters from the LD definition:


Modify the Informix DLL target (where LD is referenced) to have ESQLLD and ESQLLD
on separate lines (in DOS style without quotes).


Recommended solution:

For Windows systems, have the make file generator Makefile.pl create the
makefile lines as described above.

Problem 5


When running the makefile:

'-out' is not recognized as an internal or external command, operable program or batch file.

Or at least I think that's what I got (I don't have a saved record of this
this portion of my build).


Makefile sets the LD command using this:


Or modified as this, using the solution from Problem 4:


And later in the file, this sets LDCMD to the ESQLC "wrapper" around the linker.


The linker command LDCMD is defined late in the file, so variable LD sees
the ESQLC command value as an undefined empty string.


Move the LDCMD= definition before the LD= definition.
Or just set LD to $(ESQL).
Or just replace $(LD) with $(ESQL) in the Informix.dll target.

Recommended solution:

Have the make file generator Makefile.pl generate a makefile
using one of the above alternatives.

Problem 6


When running the makefile:

msvcrt.lib(crtexe.obj) : error LNK2001: unresolved external symbol _main
Informix.exe : fatal error LNK1120: 1 unresolved externals

In the makefile target, described above, LDDLFLAGS includes the option:
Which is the incorrect ESQLC option for creating .DLL. Thus, it tries to create
a complete program and complains because an implementation for "main()" can't
be found.


Change the option in LDDLFLAGS to be:
As documented in IBM publication:
Informix-ESQL/C, Programmer's Supplement for Microsoft Windows Environments

Recommended solution:

Have the make file generator Makefile.pl define LDDLFLAGS as described above.

Problem 7


When running the supplied tests, virtually every test file returned something
like this:

t/t00basic..........install_driver(Informix) failed: Can't find 'boot_DBD__Informix' symbol in ./Informix.dll
at (eval 1) line 3
Compilation failed in require at (eval 1) line 3.

at D:\build\DBD\DBD-Informix-2005.02\blib\lib/DBD/Informix/TestHarness.pm line 185
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-41
Failed 41/41 tests, 0.00% okay


It took me a while to dig into this one. I had to understand, to some extent,
what was going in on the code, in the file Informix.c. This is file is
automatically generated from a "XS" language in Informix.xs and uses macros
extensively. At the suggestion of a colleague, I ran the c-preprocessor to see
what was really being compiled in the Informix.c file. And what symbols were
put in the .DLL by looking at the link map. Long story short, all the symbols
in Informix.c were omitted from the DLL because a required "Informix.def" file
was NOT properly passed to the MSVC linker. That was because it was not
properly specifed on the ESQL command.

These lines occur in the makefile:

BASEEXT = Informix

The token -def: should not appear. The argument is just supposed to be a bare
file according to the IBM publication:
Informix-ESQL/C, Programmer's Supplement for Microsoft Windows Environments


I expect that just removing the -def: prefix from the EXPORT_LIST reference,
above, should work. But before I spotted that in the file, my solution was
to add the file to the LDDLFLAGS variable:

LDDLFLAGS = ...stuff here... Informix.def

Recommended solution:

Have the make file generator Makefile.pl define the def option as described
above (remove the prefix -def:).

Problem 8


When running the supplied tests, virtually every test file failed. The Informix
DLL was crashing. I don't have an exact record of this portion of the build,
but the symptom look similar to that of Problem 7.

Background and Reason:

I recognized this problem, having patched it in previous builds of the
Informix DBD I have built in 2003 and 2004. I think it's crashing because
it's freeing memory from a different pool (using free) that it was allocated
(needs to use SqlFreeMem instead per PTS Bug B83831).


In dbdimp.ec add this above the function: count_descriptors
This must be place "low" in the file; placing this "high" in the file cause
compile errors on includes.

Recommended Solution:

Not sure. Add this to the dbdimp.ec file? (But not too high in the file.)

#ifdef _WIN32
#endif /* _WIN32 */

Problem 9


DBI Can't load Informix DBD in my own scripts.

When running the installation process, 3 files did not get copied to:
I think they needed to be in a similar path in the build folder I was using.
I don't think the makefile put them there; it left them in the top level of
the build folder.


I copied them manually. They were.

Recommended Solution:

The makefile needs to ensure the link output gets into the proper place in the
build folder before the installation step.

Other Issues

All tests passed, except 4 were skipped and two tests had failures:

The first test produced this message:

Informix has no driver CLONE() function so is unsafe threaded DBD::Informix::db prepare failed: handle 2 is owned by thread 15e6014 not current thread 214b68c (handles can't be shared between threads and your driver may need a CLONE method added) at t\t08fork.t line 32.

This message is cryptic to me, but suggests to me that an Informix connection
can't span multiple threads.

Several messages from the 2nd test appeared similar to:

DBD::Informix::db do failed: SQL: -9991: Named row type (dbd_ix_udts_named) already exists in database. at D:\build\DBD\DBD-Informix-2005.02\blib\lib/DBD/Informix/TestHarness.pm line 347.

This and other output suggests to me that the testplan can't clean up User
defined data types in the database that were created in an earlier test.
It wants to clean them up, in order to recreate them in a new test.

That's it.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbi-users @
postedAug 11, '05 at 6:12p
activeAug 11, '05 at 6:12p

1 user in discussion




site design / logo © 2022 Grokbase