Re: DBD::ODBC install can't find boot_DBI

[Anonymous Monk]

What is DBI.xs.dll? See ex http://ppm4.activestate.com/MSWin32-x64/5.24/2400/T/TI/TIMB/DBI-1.636.d/log-20160604T182155.txt that unexpected file never appears

[DanEllison]

First, I'm using Strawberry and cpan, not ActiveState and ppm. And, the file is built, not extracted. Both the successful install and failed install perform the same compile:

dlltool --def DBI.def --output-exp dll.exp
g++ -o blib\arch\auto\DBI\DBI.xs.dll -Wl,--base-file -Wl,dll.base -mdl
+l -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib" DBI.o   "C:\
+STRAWB~1\perl\lib\CORE\libperl520.a" -lmoldname -lkernel32 -luser32 -
+lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 
+-lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp3
+2 -lcomctl32 dll.exp
dlltool --def DBI.def --base-file dll.base --output-exp dll.exp
g++ -o blib\arch\auto\DBI\DBI.xs.dll -mdll -s -L"C:\STRAWB~1\perl\lib\
+CORE" -L"C:\STRAWB~1\c\lib" DBI.o   "C:\STRAWB~1\perl\lib\CORE\libper
+l520.a" -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
+-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -l
+mpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 dll.exp 
"C:\Strawberry\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 755 
+blib\arch\auto\DBI\DBI.xs.dll

[Anonymous Monk]

I see the newer strawberry use .xs.dll :/ but ActiveState uses MinGW just like strawberry, as you can see from the full build log

? What do you get with  grep -r boot_DBI .

? What is the difference in the "same compile" between the successful install and failed install ? ( diff the build logs )

[DanEllison]

I get:

Binary file ./blib/arch/auto/DBI/DBI.xs.dll matches
./DBI.c:XS_EXTERNAL(boot_DBI); /* prototype to pass -Wmissing-prototyp
+es */
./DBI.c:XS_EXTERNAL(boot_DBI)
./DBI.def:  boot_DBI
Binary file ./DBI.o matches
Binary file ./dll.exp matches

on both machines.

The two machines extract the files and compile in a different order, but it appears to be the same files and same compile commands. The only difference I see before the failed test is that one machine refers to dmake as C:\STRAWB~1\c\bin\dmake.exe, while the other refers to it as C:\Strawberry\c\bin\dmake.EXE.