Installation problems with DBD::mysql on Widows server 2022

[geekdad1]

DBD::mysql version

5.010

MySQL client version

No response

Server version

Windows server 2022

Operating system version

Server 2022

What happened?

Please remove all references to using short filenames. they seem to be no longer supported under windows server 2022 and they haven't been a thing since windows 3.1 went away.

Other information

No response

[dveeden]

The only reference I can find is this:

DBD-mysql/Makefile.PL

Line 70 in 5a669fb

$opt->{'mysql_config'} = Win32::GetShortPathName($opt->{'mysql_config'})

[dveeden]

There is a fsutil 8dot3name utility that can help to see if short names are enabled on the system and on the volume:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name

The docs of Win32 ( https://metacpan.org/pod/Win32#Win32::GetShortPathName(PATHNAME) ) say that the short (8.3) components are only used when available and that otherwise full length paths are used.

The available options are:

• Win32::GetLongPathName(PATHNAME)
• Win32::GetShortPathName(PATHNAME)
• Win32::GetFullPathName(FILENAME)
• Win32::GetANSIPathName(FILENAME)

There is also this note: https://metacpan.org/pod/Win32#Short-Path-Names

So DBD::mysql now uses GetShortPathName(), which returns an relative path with short components where available. A logical alternative would be GetLongPathName() which also gives relative paths, but with with longname components.

GetFullPathName() gives an absolute path instead of a relative one.

GetANSIPathName() gives a relative path that may use the shortname if the longname does not have a representation on the system codepage.

The docs seem to suggest that GetANSIPathName() is the right option if you want to pass the result along.

Small test:

use v5.20;
use Win32;

print("short: " . Win32::GetShortPathName("Users\\danie\\Documents\\test.pl") . "\n");
print("long: " . Win32::GetLongPathName("Users\\danie\\Documents\\test.pl") . "\n");
print("full: " . Win32::GetFullPathName("Users\\danie\\Documents\\test.pl") . "\n");
print("ansi: " . Win32::GetANSIPathName("Users\\danie\\Documents\\test.pl") . "\n");

Result:

C:\>perl Users\danie\Documents\test.pl
short: Users\danie\DOCUME~1\test.pl
long: Users\danie\Documents\test.pl
full: C:\Users\danie\Documents\test.pl
ansi: Users\danie\Documents\test.pl

C:\>

[dveeden]

Some more info on my system:

C:\>fsutil 8dot3name query c:
The volume state is: 0 (8dot3 name creation is enabled).
The registry state is: 2 (Per volume setting - the default).

Based on the above settings, 8dot3 name creation is enabled on c:

C:\>chcp
Active code page: 850

C:\>ver

Microsoft Windows [Version 10.0.19045.5131]

C:\>

[dveeden]

@geekdad1 does #456 look ok to you? Is this what you meant?

[geekdad1]

I’m not a C programmer (did some small things about 100 years ago) so not 100% sure about all the command line references that I need or am using. Here is the g++ line that is failing: g++ mysql.def -o blib\arch\auto\DBD\mysql\mysql.xs.dll -shared -s -L"c:\mysql\install\lib" -L"c:\mysql\install\lib\debug" -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib" -L"C:\STRAWB~1\c\x86_64-w64-mingw32\lib" -L"C:\STRAWB~1\c\lib\gcc\x86_64-w64-mingw32\13.2.0" dbdimp.o mysql.o socket.o "C:\STRAWB~1\perl\lib\CORE\libperl540.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libmoldname.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libkernel32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libuser32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libgdi32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libwinspool.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libcomdlg32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libadvapi32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libshell32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libole32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\liboleaut32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libnetapi32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libuuid.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libws2_32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libmpr.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libwinmm.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libversion.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libodbc32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libodbccp32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libcomctl32.a" -Wl,--enable-auto-image-base I get a lot of undefined references in this compile. C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: dbdimp.o: in function `mysql_dr_connect': C:/Perl64/cpan/build/DBD-mysql-5.010-0/dbdimp.c:1208:(.text+0xa74): undefined reference to `mysql_server_init' C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Perl64/cpan/build/DBD-mysql-5.010-0/dbdimp.c:1209:(.text+0xa81): undefined reference to `mysql_init' … I ran dependencywalker across the mysql.dll file that is contained in the c:\mysql\install\lib folder which is referenced in the first line as -L”c:\mysql\install\lib” That file showed that it contained those functions mysql_server_init and mysql_init and all the rest of the missing references. Is that the right way to define it in the command line or am I missing something else entirely? Doug Poulin Chief Technology Officer Medinet Health Systems, Inc. Voice: 604-742-8845 Support: 604-737-1477 Toll free:800-737-3771 From: Daniël van Eeden ***@***.***> Sent: December 15, 2024 10:45 PM To: perl5-dbi/DBD-mysql ***@***.***> Cc: Doug Poulin ***@***.***>; Author ***@***.***> Subject: Re: [perl5-dbi/DBD-mysql] Installation problems with DBD::mysql on Widows server 2022 (Issue #454) The only reference I can find is this: https://github.com/perl5-dbi/DBD-mysql/blob/5a669fb407fe373986eda0cd55642582d3f0196d/Makefile.PL#L70 — Reply to this email directly, view it on GitHub<#454 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACWG55BMV2RIKB6RGOX4Z732FZZF3AVCNFSM6AAAAABTVF3BL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBUG4ZTGOJUGY>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[dveeden]

Note that these happen both with and without #456:

"\x{0159}" does not map to cp850 at C:/Strawberry/perl/lib/ExtUtils/MakeMaker.pm line 1271.
"\x{0159}" does not map to cp850 at C:/Strawberry/perl/lib/ExtUtils/MakeMaker.pm line 1271.
"\x{0159}" does not map to cp850 at C:/Strawberry/perl/lib/ExtUtils/MakeMaker.pm line 1271.

This is probably because various files contain a ë that is part of my name.

I can confirm that #456 improves things a bit (perl Makefile.PL ... output):

Before:

  mysql_config  (Users choice ) = c:\STRAWB~1\c\bin\MYSQL_~1.BAT

After:

  mysql_config  (Users choice ) = c:\Strawberry\c\bin\mysql_config.bat