we need a winlibs subset #57
Comments
|
Now I look at the winlibs site, I see it has versions without LLVM. I'll keep this open as we still need to clean up the extra dlls, and sub in a more recent version of patch.exe (noted in #56 (comment)). |
|
An audit of the dll dependencies of executables in the The "clashes" are DLLs for which there exists both a strawberry perl version and one from winlibs. The "Users' list is the set of DLLs in the The short summary is that we cannot easily remove the "clashing" DLLs from the distribution. This might have downstream effects on CPAN modules. (There are no clashes for libgmp, libmpfr and libmpc as we currently only build static versions). Clashes:
{
libexpat-1__.dll "libexpat-1.dll",
libiconv-2__.dll "libiconv-2.dll",
liblzma-5__.dll "liblzma-5.dll",
zlib1__.dll "zlib1.dll"
}
Users:
{
libexpat-1.dll [
[0] "gdb.exe"
],
libgmp-10.dll [
[0] "lto-dump.exe"
],
libiconv-2.dll [
[0] "c++.exe",
[1] "cpp.exe",
[2] "doxygen.exe",
[3] "g++.exe",
[4] "gcc.exe",
[5] "gcov-dump.exe",
[6] "gcov-tool.exe",
[7] "gcov.exe",
[8] "gdb.exe",
[9] "gfortran.exe",
[10] "lto-dump.exe"
],
libintl-8.dll [
[0] "addr2line.exe",
[1] "ar.exe",
[2] "as.exe",
[3] "c++filt.exe",
[4] "dlltool.exe",
[5] "dllwrap.exe",
[6] "elfedit.exe",
[7] "gmake.exe",
[8] "gprof.exe",
[9] "ld.exe",
[10] "mingw32-make.exe",
[11] "nm.exe",
[12] "objcopy.exe",
[13] "objdump.exe",
[14] "ranlib.exe",
[15] "readelf.exe",
[16] "size.exe",
[17] "strings.exe",
[18] "strip.exe",
[19] "windmc.exe",
[20] "windres.exe"
],
libisl-23.dll [
[0] "lto-dump.exe"
],
liblzma-5.dll [
[0] "gdb.exe"
],
libmpc-3.dll [
[0] "lto-dump.exe"
],
libmpfr-6.dll [
[0] "gdb.exe",
[1] "lto-dump.exe"
],
libncursesw6.dll [
[0] "gdb.exe"
],
libsource-highlight-4.dll [
[0] "gdb.exe"
],
libzstd.dll [
[0] "ccache.exe",
[1] "lto-dump.exe"
],
mman-win.dll [
[0] "ccache.exe",
[1] "gdb.exe"
],
xxhash.dll [
[0] "gdb.exe"
],
zlib1.dll [
[0] "addr2line.exe",
[1] "ar.exe",
[2] "as.exe",
[3] "c++filt.exe",
[4] "dlltool.exe",
[5] "gcov.exe",
[6] "gdb.exe",
[7] "gprof.exe",
[8] "ld.exe",
[9] "lto-dump.exe",
[10] "nm.exe",
[11] "objcopy.exe",
[12] "objdump.exe",
[13] "ranlib.exe",
[14] "readelf.exe",
[15] "size.exe",
[16] "strings.exe",
[17] "strip.exe",
[18] "windmc.exe",
[19] "windres.exe"
]
}
Code: use 5.020;
use strict;
use warnings;
use Data::Printer;
use Path::Tiny '0.018';
my $bindir = $ARGV[0] // 'c/bin';
my @files = grep {$_ !~ /x86_64-w64|nvptx/} Path::Tiny->cwd->child($bindir)->children (qr /.exe$/);
my %uses;
my $exclude = qr /__|stdc++|winpthread|x86_64|libgcc_s_seh|msvcrt|api-ms-win-crt/;
foreach my $file (@files) {
#$file = "$file";
my @deps =
grep {!-e "/mnt/c/Windows/System32/$_"}
map {s/\s+DLL\sName\:\s*(.+)\n/$1/r}
grep {$_ !~ $exclude}
grep {/DLL Name/}
`objdump -x $file`;
foreach my $dep (@deps) {
push @{$uses{$dep}}, $file->basename;
}
}
my %clash;
foreach my $name (sort keys %uses) {
my $alt_name = ($name =~ s/.dll/__.dll/r);
if (path($bindir)->child($alt_name)->exists) {
$clash{$alt_name} = $name;
}
}
say STDERR "Clashes:";
p %clash;
say STDERR "Users:";
p %uses;
|
It's not apparent to me why this would be a problem. Can you provide a demo case that would make this issue clearer to me. Cheers, |
It might well be that there are no issues and that I'm just overthinking things. The modules under But that still leaves user-installed modules under I assume clashes like this are a reason why Strawberry perl has always appended one or two underscores to the DLL names. Or maybe the reasons are completely different but now lost in time. |
|
There should be no need for concern. There's probably an Similarly for the other 3 "clashes", the import lib specifies only the double-underscore variant. There are 3 libraries in c/lib that specify "zlib1__.dll" - namely libz.a, libzlib.a and libzdll.a. In providing those underscore variants, you ensure that it's strawberry's dlls that are being loaded. Cheers, |
|
Alien modules that link to dynamic libs might have issues, though. I maintain a few that don't do static linking and go looking for DLLs. I'll run some checks with FFI::CheckLib. |
|
An |
If the module expects to access third party dlls, then the ".a" file it links to needs to be an import library. (Not entirely sure this is relevant to your issue ;-) Cheers, |
libgdal under Alien::gdal links to the underscored DLLs so it looks like we're ok on this front. |
|
The gcc-13 winlibs distribution includes ~60MB of python files. It would be nice to not need these, as much as anything to reduce download sizes. The only exe or dll file that depends on this is gdb.exe. I have added code to the build-extlibs repo (not yet pushed to a PR) to build a gdb that depends on other extlibs deps. It will be included in the next dev release. I'll close this once the release is out and the code has been pushed. (And FWIW, the python files have already been removed from the last gcc-13 based dev release, so its gdb does not work). |
|
The latest dev release includes our own gdb.exe. I'll close this issue now. |
The winlibs gcc11 system we are currently using has a large number of extra files in it. We need to sort out which ones to retain.
A quick diff of the bin dir filenames between the strawberry perl 8.3 set and the winlibs gcc11 set is below. I filtered out all lines with clang or LLVM assuming we don't need them.
Many of the DLLs we have our own versions of via the extlibs builds (e.g. zlib1.dll) but others might be useful (ninja.exe?).
Others we need to get from elsewhere.
gmake is one example. We do already have it at https://strawberryperl.com/package/kmx/64_tools/ although that's a 2014 build. Maybe we can grab one from msys2?
The text was updated successfully, but these errors were encountered: