In order to make DBD-mysql work on VMS, I had to change the section where the DBI make variables are defined. On VMS, the "postamble" section appears below the place where the actual variables are used in the makefile, so "make" complains about undefined DBI variables.
Also, a change was necessary to the linker flags for VMS because the ones hardcoded in Makefile.PL are Unix-specific.
I tested this change on RedHat Linux and everything *seems* to work...
(see attachment: Patch for Makefile.PL)

It's been a while, but I'm wondering how the current 3.0007 works with
VMS? I had changed the way VMS obtains its compile flags many releases
back and would like to know if that fixes the compile on VMS.

I tried it out this morning. One minor problem with makefile.pl:
ssl (guessed ) = 0
Use of uninitialized value in printf at makefile.pl line 172, <PIPE> line 4.
Due to trying to print out some sort of ssl information I think, even
though ssl=0.
Also, the code is attempting to sneak other compiler options in under
the include path, which will work for Unix but nothing else. You set
makemaker's INC to be things like -g and -Dvariable_name, and when
makemaker gets them, the VMS include path gets set to:
/Include=($(PERL_INC),[.$(DBI_INSTARCH_DIR)],MYSQL_ROOT:[INCLUDE],perl_root:[lib.site_perl.vms_axp.auto.dbi],[.-DDBD_MYSQL_INSERT_ID_IS_GOOD],[.-g]
.. which will not do what you want, although it won't give any errors
since the compiler will simply ignore any paths that it can't find.
You have to use DEFINE, not INC, to pass C compiler flags like
preprocessor definitions (-D) to makemaker. For generic C flags, you
can use CCFLAGS, but this is strongly not recommended since it will be
compiler specific and will not work on anything other than a Unix
compiler.
The DBI_INSTARCH_DIR variable is still not being set before it is
used; it is getting set in the postamble which is too late for the
include path to work. This is what my original patch fixed.
During compilation, I got a warning:
bind->is_null= &(fbh->is_null);
......^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the
pointer value "&(fbh->is_null)" is "int", which is not compatible with
"char".
at line number 2766 in file DBDIMP.C;1
I think is_null is just a binary flag so it's sort of ok to cast to
char. So I added a cast and now it's only an informational, which is
ok and compilation can continue:
bind->is_null= &(char)(fbh->is_null);
......................^
%CC-I-LVALUECAST, In this statement, the result of the cast
"(char)(fbh->is_null)" is used as an lvalue.
at line number 2766 in file DBDIMP.C;2
After I fixed this, everything linked just fine and all the tests
passed. Thanks for checking in on this.
-Eric
On 9/15/06, Patrick Galbraith via RT <bug-DBD-mysql@rt.cpan.org> wrote:
Show quoted text

>
> <URL: http://rt.cpan.org/Ticket/Display.html?id=11982 >
>
> It's been a while, but I'm wondering how the current 3.0007 works with
> VMS? I had changed the way VMS obtains its compile flags many releases
> back and would like to know if that fixes the compile on VMS.
>

Eric,
Would your original patch still fix this issue? I'll put it in. I just
have no way of testing ;) I don't think we have a VMS box, plus I don't
recall how to use VMS - that was way back during a Fortran 77 class ;)
Thanks!
Patrick
eam23@cornell.edu via RT wrote:
Show quoted text

> Queue: DBD-mysql
> Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=11982 >
>
>I tried it out this morning. One minor problem with makefile.pl:
>
> ssl (guessed ) = 0
>Use of uninitialized value in printf at makefile.pl line 172, <PIPE> line 4.
>
>Due to trying to print out some sort of ssl information I think, even
>though ssl=0.
>
>Also, the code is attempting to sneak other compiler options in under
>the include path, which will work for Unix but nothing else. You set
>makemaker's INC to be things like -g and -Dvariable_name, and when
>makemaker gets them, the VMS include path gets set to:
>/Include=($(PERL_INC),[.$(DBI_INSTARCH_DIR)],MYSQL_ROOT:[INCLUDE],perl_root:[lib.site_perl.vms_axp.auto.dbi],[.-DDBD_MYSQL_INSERT_ID_IS_GOOD],[.-g]
>.. which will not do what you want, although it won't give any errors
>since the compiler will simply ignore any paths that it can't find.
>You have to use DEFINE, not INC, to pass C compiler flags like
>preprocessor definitions (-D) to makemaker. For generic C flags, you
>can use CCFLAGS, but this is strongly not recommended since it will be
>compiler specific and will not work on anything other than a Unix
>compiler.
>The DBI_INSTARCH_DIR variable is still not being set before it is
>used; it is getting set in the postamble which is too late for the
>include path to work. This is what my original patch fixed.
>
>During compilation, I got a warning:
> bind->is_null= &(fbh->is_null);
>......^
>%CC-W-PTRMISMATCH, In this statement, the referenced type of the
>pointer value "&(fbh->is_null)" is "int", which is not compatible with
>"char".
>at line number 2766 in file DBDIMP.C;1
>
>I think is_null is just a binary flag so it's sort of ok to cast to
>char. So I added a cast and now it's only an informational, which is
>ok and compilation can continue:
> bind->is_null= &(char)(fbh->is_null);
>......................^
>%CC-I-LVALUECAST, In this statement, the result of the cast
>"(char)(fbh->is_null)" is used as an lvalue.
>at line number 2766 in file DBDIMP.C;2
>
>
>After I fixed this, everything linked just fine and all the tests
>passed. Thanks for checking in on this.
>
>-Eric
>
>
>On 9/15/06, Patrick Galbraith via RT <bug-DBD-mysql@rt.cpan.org> wrote:
>
>

>><URL: http://rt.cpan.org/Ticket/Display.html?id=11982 >
>>
>>It's been a while, but I'm wondering how the current 3.0007 works with
>>VMS? I had changed the way VMS obtains its compile flags many releases
>>back and would like to know if that fixes the compile on VMS.
>>
>>
>>