Basic mysql-native dub app does not compile with dmd 2.095.0

[reyvaleza]

I have an app written and running in Ubuntu but does not compile on Windows 10. I need it to run on Windows ten. The db server is MySQL 8.0.23. Here is the error I get:

empapp.obj : error LNK2001: unresolved external symbol _D5mysql12__ModuleInfoZ
.dub\build\application-debug-windows-x86_64-dmd_v2.095.0-dirty-BB4DEF503CB41185FCFD2A9F67C6DA61\empapp.exe : fatal error LNK1120: 1 unresolved externals
Error: linker exited with status 1120
C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1.

Anybody who knows why? On my Windows machine, I uninstalled MySQL 8.0.23 and installed the older MySQL 5.7.32, then I compiled my project again. Same error.

[schveiguy]

How are you compiling your app? Are you using dub or dmd directly?

That error suggests that there is a missing symbol that would normally be included if you are linking against the mysql-native library. It's possible this is a compiler error, but also could just be related to how you are building.

Note that the installation of MySQL has nothing to do with building mysql-native. The library does not use any code/library from it, and does not require any access to a running server to build.

[schveiguy]

I'll also note that I don't regularly use Windows. So it might be hard to help, though I can certainly try to build if you post some minimal application to try, and how you build it.

[karitoy]

Thanks for your reply!
On Windows 10, simply create a new project with dub and compile and run the default project with dub to test that it runs. Then use dub to add mysql-native. Compile and run, and it will still run. Then in app.d (or a new class if you want), add an 'import mysql;' line. Compile and run. It won't compile. That is the simplest way I tested it, on two machines already.

[schveiguy]

oof! That is not good, I'll try it out. Thanks for the clear instructions!

[schveiguy]

I tried it, and it worked for me. But I was on compiler 2.094.0. I updated to 2.095, and get the error you are talking about. So it seems like it's a compiler error that either wasn't in 2.094 or was exposed with differences in the library.

Can you try building with 2.094 for now? I'll file an issue against the compiler.

[schveiguy]

Here is the archive for 2.094.2, if that doesn't work, I think I was on 2.094.0.

http://downloads.dlang.org/releases/2.x/2.094.2/

[schveiguy]

It happens without vibe-d as a dependency as well. I will try to narrow this down.

[karitoy]

Thanks a lot!

Thanks for the link to the older versions too!

[karitoy]

I tried all three versions of the compiler now (2.094.0, 2.094.2, 2.095) and I got the same error, unfortunately.

[schveiguy]

Hm... that's odd. I did not get the error before upgrading to 2.095.0. I'm running dustmite right now. But it's slooooow. Hopefully it will show the minimal case to submit as a compiler bug.

[karitoy]

Yes, I'm surprised too. Thanks!

[karitoy]

Hi, are there any developments?

[schveiguy]

Sorry, dustmite is still running. Not sure how long it will take, but I'm afraid to try anything else while it's running.

[karitoy]

Thanks!

[schveiguy]

Finished, I'll take a look. Done in 44351 tests and 1 day, 22 hours, 29 minutes, 28 secs, and 940 ms; lol

In the meantime, I'll try to recreate what worked before (with what I thought was 2.094)

[schveiguy]

AAARGGH! dustmite reduced everything to having NO source code. I need to revisit what I need to do here. That was a huge waste of time.

[karitoy]

Thanks for the updates. My computer is offline as Toronto is experiencing heavy snow right now, so I’m using my phone. Sent from Yahoo Mail for iPhone On Tuesday, January 26, 2021, 10:58 AM, Steven Schveighoffer <[email protected]> wrote: AAARGGH! dustmite reduced everything to having NO source code. I need to revisit what I need to do here. That was a huge waste of time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[schveiguy]

It's most definitely an issue with 2.095, and specifically with the new release of dub.

If you download a previous version of dub, and DELETE the %USERPROFiLE%\AppData\Local\dub directory, it will work.

The short explanation is that dub is internally now excluding the main file from one configuration in any other configuration. The idea behind it is that if you have a file that is supposed to be the "main" file of a configuration, then it probably isn't for the other configurations. However, mysql-native (for some reason) names mysql/package.d as the main file for one of the configurations.

Replacing dub with a prior version ALONE will not work. You have to re-download the mysql-native library. That is because dub exports a processed copy of the dub recipe file (which contains these exclusionary items).

[schveiguy]

If you use 2.094.0 (at least) and remove the dub directory in AppData, it should work.

[schveiguy]

@Abscissa I know that it's been a LONG time since you looked at this, but can you recall why mainSourceFile was used in this configuration?

You added it here: 36c6e30

dub just broke mysql-native by adopting the (reasonable but hacky) rule that any mainSourceFile directives should be excluded from other configurations. See dlang/dub#2039

Regardless of the fact that dub shouldn't be breaking existing packages, even if the recipe files are hackish themselves, it would be good to have some rationale to understand why one might want to do this.

[karitoy]

Thanks for the detailed instructions, Steven. Toronto is still down, at least mine is, due to the heavy snow. Sent from Yahoo Mail for iPhone On Tuesday, January 26, 2021, 4:00 PM, Steven Schveighoffer <[email protected]> wrote: If you use 2.094.0 (at least) and remove the dub directory in AppData, it should work. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[Abscissa]

@schveiguy: Umm, wait a minute, I think I might have misunderstood...Are you saying that in the latest dub, if one configuration specifies a mainSourceFile, then that entire file is deliberately not even compiled in other configurations, even if those configurations never asked for the file to be excluded??? I hope I'm misunderstanding this because, if not, then that's boneheaded even by dub standards. (Seriously, I swear to god, ever since its creation, dub and its moronic one-size-fits-all notions have always been dlang's greatest enemy.)

To hopefully answer your question: Unless I'm forgetting something (like you said, it's been awhile), there wasn't any big special reason for the mainSourceFile in that commit. GitHub makes it difficult to go from that commit and see all the nearby commits, so I can't be 100% certain, but based on what I'm remembering and seeing in that commit alone, I think I just wanted to be sure all relevant files were included in the unittest builds. Granted, dub doesn't base source-file inclusion upon the import tree like rdmd does, but IIRC, mysql-native's phobos-based tests rely on rdmd instead of dub. So it's entirely possible that setting the "root" file for that configuration was only done to be consistent with with the rdmd-based Phobos-thread unittest build.

I say, try making whatever changes are needed to make the latest dub happy. IIRC, there should be a simple envar in the travis stuff to make the testsuite use unitthreaded instead of Druntime's default testrunner. Unitthreaded prints out a list of all test being run, so using that, it should be possible to verify that all tests are still being run even with your changes to dub's mainSourceFile.

[schveiguy]

@Abscissa you are not misunderstanding. However, the entire point of mainSourceFile is pretty silly to begin with. If I understand the discussion on slack properly, the sole purpose is to say "this is where the main function lives". It's only used (prior to this change) when issuing dub test, so that dub can use it's own main function for unit tests (this dates from back when unit testing by default would run the main function after unit tests were run). It's both clunky and not fit for purpose IMO. Technically, if you have multiple main functions defined in your source tree, then wishing to exclude them in the other configs might be reasonable. But the wording and function are so awkward (this excludes not just the main function but ALL the code in that file).

You probably should not have ever used this directive. In fact, I'd say most people probably should never have used it. I'm a bit curious as to how many projects used that directive.

A better name for that should have been "excludeForUnitTesting" or "excludeInOtherConfigs" (in the latest iteration).

And if I may rant even a bit more, the way it's implemented is via a rewrite. What this means is that doing something like dub add somedep will actually INSERT excludedSourceFiles directives into the other configurations Edit: no, actually it doesn't do it in this case. This happens when downloading the dependency from git! So if you use dmd 2.095's dub to download the mysql-native package as a dependency, those get in there, and then try downgrading your compiler (as the OP did), it now has that directive making it not compile. This was a really confusing issue to track down. I dare say only because a kind person on the forums noticed the directives in the regurgitated dub.json file is the only reason I could properly diagnose this.

The problem I have with the dub change is that nobody can upgrade to 2.095 and still use mysql-native tagged 3.0.0 and prior. So changing it now does not fix that problem (I could go back and add releases for all the branches, but I think this change needs to get reverted).

[schveiguy]

I'm a bit curious as to how many projects used that directive.

There's actually a warning in dub if you don't! So probably quite a few people used it. I wonder if this has something to do with why you added it.

https://github.com/dlang/dub/blob/e89341227ec5a05a6a603b41e57e203f28a188c4/source/dub/project.d#L659

[karitoy]

Thanks for your efforts! Meanwhile I was able to port my app using MongoDB. Now I have two database backends that I can switch to at a moment's notice. But I'll still be waiting for any developments on the MySQL end. Thanks!

[Geod24]

Fix: #229

[reyvaleza]

I still cannot compile.

…

________________________________ From: Mathias LANG ***@***.***> Sent: Saturday, May 22, 2021 4:43 AM To: mysql-d/mysql-native ***@***.***> Cc: reyvaleza ***@***.***>; Author ***@***.***> Subject: Re: [mysql-d/mysql-native] Basic mysql-native dub app does not compile with dmd 2.095.0 (#224) Fix: #229<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmysql-d%2Fmysql-native%2Fpull%2F229&data=04%7C01%7C%7C11a6951ba38642b17c4608d91d16cc90%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637572806024191072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=c5DmOkPeDk89bJhKaB9n1kcgp6R5OgZ%2BphPeOtTnggc%3D&reserved=0> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmysql-d%2Fmysql-native%2Fissues%2F224%23issuecomment-846396227&data=04%7C01%7C%7C11a6951ba38642b17c4608d91d16cc90%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637572806024201063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kuNOCSmNbC7GmqdBvBanG1agcEGlt%2BQelPLjW8iL6no%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FASRJACLNN23O6SU6PEW5XBDTO6KFRANCNFSM4WPG7MJA&data=04%7C01%7C%7C11a6951ba38642b17c4608d91d16cc90%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637572806024211066%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uVidEOTHwssXL2c3O0dDsUE5tKXMcLtqUcJliouw0io%3D&reserved=0>.

[Geod24]

You have to wait for a new release.

[schveiguy]

I expect a new release soon. For sure by this weekend.

[karitoy]

I see. Thanks! On Thursday, May 27, 2021, 11:55:17 a.m. EDT, Steven Schveighoffer ***@***.***> wrote: I expect a new release soon. For sure by this weekend. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[schveiguy]

New release out! I triggered it in code.dlang.org, you just have to wait for it to show up. Should fix this issue.

[karitoy]

Thanks! On Friday, May 28, 2021, 10:18:31 p.m. EDT, Steven Schveighoffer ***@***.***> wrote: Closed #224. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[reyvaleza]

Finally built and ran my app! Thanks to everyone for all the hard work!

[Abscissa]

I'm a bit curious as to how many projects used that directive.

There's actually a warning in dub if you don't! So probably quite a few people used it. I wonder if this has something to do with why you added it.

https://github.com/dlang/dub/blob/e89341227ec5a05a6a603b41e57e203f28a188c4/source/dub/project.d#L659

Yea, that certainly sounds about right. I definitely remember having to bend over backwards to shut up some of dub's misguided warnings, just so I could trick the goddamn thing into not screwing up...yet again. That's classic dub - you're endlessly dodging a constant stream of cover-fire just to get anything done. (I generally like warnings, but not when they push you towards bad ideas...as I very distinctly remember dub frequently trying to do.) Dub, and its idiotic philosophy of "do it all my way (whatever that happens to mean in the latest, greatest version)", for as long as its been around, has always been D's biggest Achilles's heel, and one of the reasons I finally, gladly, gave up on both D and software dev.