On 1/26/21 1:33 PM, Andre Pany wrote:
On Tuesday, 26 January 2021 at 16:04:29 UTC, Steven Schveighoffer wrote:
I have a bug report in mysql-native that if you try to create the
following file, and add mysql-native as a dependency it fails to link
on Windows 10:
import std.stdio;
import mysql;
void main()
{
writeln("Edit source/app.d to start your project.");
}
You might recognize that as the default dub file, with an extra import.
The link error is:
testmysql.obj : error LNK2001: unresolved external symbol
_D5mysql12__ModuleInfoZ
So I figured I'd try dustmite, and used:
dub dustmite ..\dusted --linker-status=1
The result after almost 2 days: a bunch of directories with mostly no
d files, and no source code in any of the d files.
What did I do wrong? Is this even worth trying again? 2 days is a long
time to tie up my windows vm.
I think the behavior can be explained. Your search criteria (linked
status) is not precise. It can be triggered by the real problem but also
by a few empty d files. Therefore Dustmite did a good job, it reduced
your code base to a minimum which still trigger a linker error.
You might search the linker error text instead.
Yes, thanks. I think probably this would work. I would suggest however,
that dub not provide an option that is almost certainly likely to result
in completely useless results. I had assumed that using that would keep
the linker error the same. Maybe if --linker-status or --compiler-status
is provided, not do anything unless there are other options (i.e.
--compiler-regex or --linker-regex) which is what I should have added as
well.
In the meantime, I'm going to try manually reducing the dependencies, to
try and reduce down the dustmite search (mysql-native depends on a lot
of vibe stuff, which is probably not necessary to reproduce this). I
didn't expect 2 days of running.
-Steve
