Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 19:19:09 UTC, bauss wrote: On Saturday, 5 November 2022 at 14:54:52 UTC, Hipreme wrote: On Saturday, 5 November 2022 at 14:14:16 UTC, bauss wrote: On Saturday, 5 November 2022 at 13:42:08 UTC, rikki cattermole wrote: Try ldc, if that works then its just a missing library that needs to be linked against regarding MS CRT. Using LDC doesn't seem to work either, it has similar linking problems. ``` lld-link: error: undefined symbol: fileno referenced by druntime-ldc.lib(dmain2.obj):(_d_print_throwable) referenced by phobos2-ldc.lib(stdio.obj):(_D3std5stdio4File4syncMFNeZv) referenced by phobos2-ldc.lib(stdio.obj):(_D3std5stdio4File13windowsHandleMFNdZPv) referenced 18 more times lld-link: error: undefined symbol: execv referenced by phobos2-ldc.lib(process.obj):(_D3std7process6execv_FIAyaIAQfZi) lld-link: error: undefined symbol: execve referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execve_FIAyaIAQfIQeZi) lld-link: error: undefined symbol: execvp referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execvp_FIAyaIAQfZi) lld-link: error: undefined symbol: execvpe referenced by phobos2-ldc.lib(process.obj):(_D3std7process8execvpe_FIAyaIAQfIQeZi) lld-link: error: undefined symbol: tzset referenced by phobos2-ldc.lib(timezone.obj):(_D3std8datetime8timezone9LocalTime9singletonFNeZ12__dgliteral4MFNaNbNiNfZOb) Error: linking with LLD failed ldc2 failed with exit code 1. ``` Not sure what to do at this point. Just posted the other day how to use the MSVC Linker on windows. Using LLD is quite complicated in my experience because I was getting a lot of undefined symbols from the libcmt. Check this post: https://forum.dlang.org/thread/frixfbbucsbgcrsvm...@forum.dlang.org Remember that for using the MSVC Linker you will need to have visual studio build tools on your PC (or install the visual studio with desktop development with C++). Then you can modify your `sc.ini` and it should work. I have both VS 2019 and 2022, but only 2019 has c++ build tools etc. I assume that should be fine? So I will try this now and see how goes. Currently having some trouble getting it to work, but probably because I am editing sc.ini wrong. Is it possible you could post your sc.ini so I can compare with mine? I get an error like the following when linking: ``` Linking... Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\Hostx86\x64', check PATH C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1. ``` I put this in sc.ini under [Environment] and [Environment64] ``` LINKCMD=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\Hostx86\x64 ``` Manually editing / moving files is not recommended for Visual Studio installs I recommend the following: - Uninstall both version of VS - Reboot - Install the latest version of VS + sdk - Reboot - Reinstall DMD just to make sure
Re: Makefiles and dub
On Saturday, 5 November 2022 at 12:17:14 UTC, rikki cattermole wrote: But yes, it has two others (although idk how much they get used, or how complete). Using the first two all the time. IIRC VisualD projects respect --combined
Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 19:19:09 UTC, bauss wrote: On Saturday, 5 November 2022 at 14:54:52 UTC, Hipreme wrote: [...] I have both VS 2019 and 2022, but only 2019 has c++ build tools etc. I assume that should be fine? [...] You forgot to put \link.exe in the path
Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 19:24:54 UTC, Imperatorn wrote: On Saturday, 5 November 2022 at 13:30:43 UTC, bauss wrote: Fresh install of DMD and when trying to use ex. std.file from Phobos I get the following linking error: (I can trigger different ones depending on modules imported etc.) [...] Im also on Windows 10 and 11 and don't have any problems with dmd On my other Windows 10 machine I have never faced problems and I am not sure why I am facing these problems now. I assumed it would work just the same.
Re: Makefiles and dub
On 05.11.22 12:38, rikki cattermole wrote: We have a few build formats that dub can generate for you automatically: ``` visuald - VisualD project files sublimetext - SublimeText project file cmake - CMake build scripts build - Builds the package directly ``` Unfortunately none of them are make, it would be nice to have that if you are looking to contribute! If cmake works, then cmake could generate a normal makefile :) Kind regards, Christian
Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 13:30:43 UTC, bauss wrote: Fresh install of DMD and when trying to use ex. std.file from Phobos I get the following linking error: (I can trigger different ones depending on modules imported etc.) [...] Im also on Windows 10 and 11 and don't have any problems with dmd
Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 14:54:52 UTC, Hipreme wrote: On Saturday, 5 November 2022 at 14:14:16 UTC, bauss wrote: On Saturday, 5 November 2022 at 13:42:08 UTC, rikki cattermole wrote: Try ldc, if that works then its just a missing library that needs to be linked against regarding MS CRT. Using LDC doesn't seem to work either, it has similar linking problems. ``` lld-link: error: undefined symbol: fileno referenced by druntime-ldc.lib(dmain2.obj):(_d_print_throwable) referenced by phobos2-ldc.lib(stdio.obj):(_D3std5stdio4File4syncMFNeZv) referenced by phobos2-ldc.lib(stdio.obj):(_D3std5stdio4File13windowsHandleMFNdZPv) referenced 18 more times lld-link: error: undefined symbol: execv referenced by phobos2-ldc.lib(process.obj):(_D3std7process6execv_FIAyaIAQfZi) lld-link: error: undefined symbol: execve referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execve_FIAyaIAQfIQeZi) lld-link: error: undefined symbol: execvp referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execvp_FIAyaIAQfZi) lld-link: error: undefined symbol: execvpe referenced by phobos2-ldc.lib(process.obj):(_D3std7process8execvpe_FIAyaIAQfIQeZi) lld-link: error: undefined symbol: tzset referenced by phobos2-ldc.lib(timezone.obj):(_D3std8datetime8timezone9LocalTime9singletonFNeZ12__dgliteral4MFNaNbNiNfZOb) Error: linking with LLD failed ldc2 failed with exit code 1. ``` Not sure what to do at this point. Just posted the other day how to use the MSVC Linker on windows. Using LLD is quite complicated in my experience because I was getting a lot of undefined symbols from the libcmt. Check this post: https://forum.dlang.org/thread/frixfbbucsbgcrsvm...@forum.dlang.org Remember that for using the MSVC Linker you will need to have visual studio build tools on your PC (or install the visual studio with desktop development with C++). Then you can modify your `sc.ini` and it should work. I have both VS 2019 and 2022, but only 2019 has c++ build tools etc. I assume that should be fine? So I will try this now and see how goes. Currently having some trouble getting it to work, but probably because I am editing sc.ini wrong. Is it possible you could post your sc.ini so I can compare with mine? I get an error like the following when linking: ``` Linking... Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\Hostx86\x64', check PATH C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1. ``` I put this in sc.ini under [Environment] and [Environment64] ``` LINKCMD=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\Hostx86\x64 ```
Re: Linking not working properly Windows 11
I've looked up three of those names, they are all deprecated. I'm wondering if Microsoft have removed them.
Re: return scope vs. scope return
On Saturday, 5 November 2022 at 16:13:18 UTC, 0xEAB wrote:
Apparently there a difference between:
- ```d
Message withBody(Body body_) return scope { /* … */ }
```
- ```d
Message withBody(Body body_) scope return { /* … */ }
```
```
Deprecation: returning `this._body` escapes a reference to
parameter `this`
perhaps change the `return scope` into `scope return`
```
What is it?
And why (…does the order of attributes matter)?
Basically, the `return` attribute is a modifier, and has no
meaning on its own. Either it modifies `ref` to create `return
ref`, or it modifies `scope` to create `return scope`. (In the
case of a struct method, like in your example, the `ref` is
implicit.)
In the past, if you used all 3 of `ref`, `scope`, and `return` on
a single parameter, it was ambiguous whether the `return` was
modifying `ref` or `scope`. This lead to a lot of confusion and
frustration (see [this thread][1] for the gory details).
To resolve the ambiguity, Walter decided to make the *order* of
the keywords significant: if you write `return scope`, in exactly
that order, then `return` modifies `scope`; otherwise, it
modifies `ref`.
I believe that the plan is to eventually require `return ref` to
be written in exactly that order as well (see Walter's reply in
[this thread][2]), but that's a breaking change, and will require
a deprecation period. So in the meantime, we have kind of an
awkward half-solution, where keyword order is significant for
`return scope` but not for `return ref`.
[1]:
https://forum.dlang.org/post/nbbtdbgifaurxokny...@forum.dlang.org
[2]: https://forum.dlang.org/post/snnd0r$132p$1...@digitalmars.com
return scope vs. scope return
Apparently there a difference between:
- ```d
Message withBody(Body body_) return scope { /* … */ }
```
- ```d
Message withBody(Body body_) scope return { /* … */ }
```
```
Deprecation: returning `this._body` escapes a reference to
parameter `this`
perhaps change the `return scope` into `scope return`
```
What is it?
And why (…does the order of attributes matter)?
Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 13:30:43 UTC, bauss wrote:
Fresh install of DMD and when trying to use ex. std.file from
Phobos I get the following linking error: (I can trigger
different ones depending on modules imported etc.)
```
lld-link: error: undefined symbol: tzset
```
I assume it has something to do with the C runtime or
something, but everything should be setup correct, so maybe
some path or something that is incorrect that I may need to
modify? I have no idea what I need to do however.
I am using dub as well, so basically compiling using:
```
dub build -a=x86_64
```
Is there anything I am missing or what should I do? Currently D
is unusable for me on my new machine because of this.
If anybody knows how I can just get things to work, it seems
like D never works out of the box, which is very unfortunate.
This is literally my file:
```d
module main;
import std.file : readText, exists, write;
void main() {}
```
It's as minimal as an example as I can give pretty much.
A similar issue was with C++ runtime libraries such as
libcmt.lib not being linked and I ended up having to move the
files manually to my project folder, as I don't know how to fix
it properly as there aren't any clear instructions anywhere on
how to fix invalid paths etc. or what to do when linking just
doesn't find the files despite them existing.
If anyone can help me fix this then I will be very grateful.
do you have visual studio installed? if so what version?
do you have msys installed? is it in your PATH?
Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 14:14:16 UTC, bauss wrote: On Saturday, 5 November 2022 at 13:42:08 UTC, rikki cattermole wrote: Try ldc, if that works then its just a missing library that needs to be linked against regarding MS CRT. Using LDC doesn't seem to work either, it has similar linking problems. ``` lld-link: error: undefined symbol: fileno referenced by druntime-ldc.lib(dmain2.obj):(_d_print_throwable) referenced by phobos2-ldc.lib(stdio.obj):(_D3std5stdio4File4syncMFNeZv) referenced by phobos2-ldc.lib(stdio.obj):(_D3std5stdio4File13windowsHandleMFNdZPv) referenced 18 more times lld-link: error: undefined symbol: execv referenced by phobos2-ldc.lib(process.obj):(_D3std7process6execv_FIAyaIAQfZi) lld-link: error: undefined symbol: execve referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execve_FIAyaIAQfIQeZi) lld-link: error: undefined symbol: execvp referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execvp_FIAyaIAQfZi) lld-link: error: undefined symbol: execvpe referenced by phobos2-ldc.lib(process.obj):(_D3std7process8execvpe_FIAyaIAQfIQeZi) lld-link: error: undefined symbol: tzset referenced by phobos2-ldc.lib(timezone.obj):(_D3std8datetime8timezone9LocalTime9singletonFNeZ12__dgliteral4MFNaNbNiNfZOb) Error: linking with LLD failed ldc2 failed with exit code 1. ``` Not sure what to do at this point. Just posted the other day how to use the MSVC Linker on windows. Using LLD is quite complicated in my experience because I was getting a lot of undefined symbols from the libcmt. Check this post: https://forum.dlang.org/thread/frixfbbucsbgcrsvm...@forum.dlang.org Remember that for using the MSVC Linker you will need to have visual studio build tools on your PC (or install the visual studio with desktop development with C++). Then you can modify your `sc.ini` and it should work.
Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 13:42:08 UTC, rikki cattermole wrote: Try ldc, if that works then its just a missing library that needs to be linked against regarding MS CRT. Using LDC doesn't seem to work either, it has similar linking problems. ``` lld-link: error: undefined symbol: fileno referenced by druntime-ldc.lib(dmain2.obj):(_d_print_throwable) referenced by phobos2-ldc.lib(stdio.obj):(_D3std5stdio4File4syncMFNeZv) referenced by phobos2-ldc.lib(stdio.obj):(_D3std5stdio4File13windowsHandleMFNdZPv) referenced 18 more times lld-link: error: undefined symbol: execv referenced by phobos2-ldc.lib(process.obj):(_D3std7process6execv_FIAyaIAQfZi) lld-link: error: undefined symbol: execve referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execve_FIAyaIAQfIQeZi) lld-link: error: undefined symbol: execvp referenced by phobos2-ldc.lib(process.obj):(_D3std7process7execvp_FIAyaIAQfZi) lld-link: error: undefined symbol: execvpe referenced by phobos2-ldc.lib(process.obj):(_D3std7process8execvpe_FIAyaIAQfIQeZi) lld-link: error: undefined symbol: tzset referenced by phobos2-ldc.lib(timezone.obj):(_D3std8datetime8timezone9LocalTime9singletonFNeZ12__dgliteral4MFNaNbNiNfZOb) Error: linking with LLD failed ldc2 failed with exit code 1. ``` Not sure what to do at this point.
Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 13:42:08 UTC, rikki cattermole wrote: Try ldc, if that works then its just a missing library that needs to be linked against regarding MS CRT. I will give it a try
Re: Linking not working properly Windows 11
Try ldc, if that works then its just a missing library that needs to be linked against regarding MS CRT.
Re: Linking not working properly Windows 11
On Saturday, 5 November 2022 at 13:30:43 UTC, bauss wrote: ``` lld-link: error: undefined symbol: tzset ``` I don't know if this is relevant, so I will just put it here just in case: ``` lld-link: error: undefined symbol: tzset referenced by phobos64.lib(timezone_151f_37a.obj):(_D3std8datetime8timezone9LocalTime9singletonFNeZ9__lambda3FNbNiNfZb) Error: linker exited with status 1 ```
Linking not working properly Windows 11
Fresh install of DMD and when trying to use ex. std.file from
Phobos I get the following linking error: (I can trigger
different ones depending on modules imported etc.)
```
lld-link: error: undefined symbol: tzset
```
I assume it has something to do with the C runtime or something,
but everything should be setup correct, so maybe some path or
something that is incorrect that I may need to modify? I have no
idea what I need to do however.
I am using dub as well, so basically compiling using:
```
dub build -a=x86_64
```
Is there anything I am missing or what should I do? Currently D
is unusable for me on my new machine because of this.
If anybody knows how I can just get things to work, it seems like
D never works out of the box, which is very unfortunate.
This is literally my file:
```d
module main;
import std.file : readText, exists, write;
void main() {}
```
It's as minimal as an example as I can give pretty much.
A similar issue was with C++ runtime libraries such as libcmt.lib
not being linked and I ended up having to move the files manually
to my project folder, as I don't know how to fix it properly as
there aren't any clear instructions anywhere on how to fix
invalid paths etc. or what to do when linking just doesn't find
the files despite them existing.
If anyone can help me fix this then I will be very grateful.
Re: Hipreme's #4 Tip of the day - Don't use package.d
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote: 3. I'm currently having a bug on my API module that every duplicated file name, even when located at different directories(modules), are generating duplicate symbol. The major problem is that this is currently undebuggable, as the MSVC Linker does not show the full directory of the libraries/object files that caused this clash, not even the symbol! Do you have a (reduced) example of this?
Re: Hipreme's #4 Tip of the day - Don't use package.d
On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote: Package.d is a real problem existing on our currently modules design. First is that it means to take the directory name to use as a module. If the example mentioned in this thread is not confusing, package.d is a godsend. https://forum.dlang.org/post/kmgwcapkusvoxqapx...@forum.dlang.org SDB@79
Re: Hipreme's #4 Tip of the day - Don't use package.d
On Saturday, 5 November 2022 at 10:18:33 UTC, Hipreme wrote: On Saturday, 5 November 2022 at 01:34:04 UTC, ryuukk_ wrote: On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote: Package.d is a real problem existing on our currently modules design. First is that it means to take the directory name to use as a module. This is a problem for 3 reasons: 1. You won't be able to find your module by the file name. This is incredibly common, for instance, in Visual Studio Code, when you hit CTRL+P and type the file name, nope, you will need to write path/to/folder/package.d, beyond that, when you search package.d there will be so many files with the same name. 2. As being an exception to how the module system works, this has already caused me a few headaches (inexplicable bugs), that happens with symbols aliasing, when the time it happened, I had no idea on what it could be and I don't even remember how I solved, instead, I only knew it was related to package.d. 3. I'm currently having a bug on my API module that every duplicated file name, even when located at different directories(modules), are generating duplicate symbol. The major problem is that this is currently undebuggable, as the MSVC Linker does not show the full directory of the libraries/object files that caused this clash, not even the symbol! The duplicate symbol currently only happens in MSVC Linker, which makes me think if the bug is in the D language or the linker itself, as on LLD this does not happen. So, my current advice is always try making your file names unique, this will bring a much better debuggability in your project. i use that feature a lot, just search with the folder name, then "package" https://i.imgur.com/cHb7isl.png it's also very useful to avoid having all of your code in a giant unreadable single file it's also very useful to avoid using dub.. just an import path to the folder and that's it https://i.imgur.com/Wy6WOXK.png also very useful when you want to simplify using importc, put your c files under the c folder, and the package.d, public import the c files, and you can put some helper code in D there, very nice to have I believe that needing to write `package.d` manually is pretty useless. Most of the time it means "import everything from this directory". The only real usage that helped me is when I needed to create a `version(Release) import something.opt; else version(Debug) import something.hotload;` basically. But that does not really require package.d. Those historic issues that Adam said are the real cause of their current design. Take into account how would you do it in Java. `import mypackage.*;` is how it was done, and I haven't never had any problem doing this, and this is pretty descriptive. package.d feels a lot more Haxe's `import.hx`, but it has a main difference that import.hx is a REAL special file that changes a bit on what happens on your source files. They are automatically included in its dir/subdir (think of a per directory object.d). The problem is that I'm not saying package.d is worthless, but it is a pool of bugs in the language that needs a real fix and only that post has already showed 4 bugs people have had. (Although I still don't like searching files by package.d, it is counter intuitive). oh i am with you, i just wanted to point out few usecase in case someone would want to improve/remove/change package.d functionality
Re: Makefiles and dub
On 06/11/2022 1:16 AM, Imperatorn wrote: On Saturday, 5 November 2022 at 11:38:09 UTC, rikki cattermole wrote: We have a few build formats that dub can generate for you automatically: ``` visuald - VisualD project files sublimetext - SublimeText project file cmake - CMake build scripts build - Builds the package directly ``` Unfortunately none of them are make, it would be nice to have that if you are looking to contribute! Wait, dub can generate all those? I only knew about visuald build is just dub and doesn't emit any project files. But yes, it has two others (although idk how much they get used, or how complete).
Re: Makefiles and dub
On Saturday, 5 November 2022 at 11:38:09 UTC, rikki cattermole wrote: We have a few build formats that dub can generate for you automatically: ``` visuald - VisualD project files sublimetext - SublimeText project file cmake - CMake build scripts build - Builds the package directly ``` Unfortunately none of them are make, it would be nice to have that if you are looking to contribute! Wait, dub can generate all those? I only knew about visuald
Re: Makefiles and dub
We have a few build formats that dub can generate for you automatically: ``` visuald - VisualD project files sublimetext - SublimeText project file cmake - CMake build scripts build - Builds the package directly ``` Unfortunately none of them are make, it would be nice to have that if you are looking to contribute!
Re: Hipreme's #4 Tip of the day - Don't use package.d
On Saturday, 5 November 2022 at 01:34:04 UTC, ryuukk_ wrote: On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote: Package.d is a real problem existing on our currently modules design. First is that it means to take the directory name to use as a module. This is a problem for 3 reasons: 1. You won't be able to find your module by the file name. This is incredibly common, for instance, in Visual Studio Code, when you hit CTRL+P and type the file name, nope, you will need to write path/to/folder/package.d, beyond that, when you search package.d there will be so many files with the same name. 2. As being an exception to how the module system works, this has already caused me a few headaches (inexplicable bugs), that happens with symbols aliasing, when the time it happened, I had no idea on what it could be and I don't even remember how I solved, instead, I only knew it was related to package.d. 3. I'm currently having a bug on my API module that every duplicated file name, even when located at different directories(modules), are generating duplicate symbol. The major problem is that this is currently undebuggable, as the MSVC Linker does not show the full directory of the libraries/object files that caused this clash, not even the symbol! The duplicate symbol currently only happens in MSVC Linker, which makes me think if the bug is in the D language or the linker itself, as on LLD this does not happen. So, my current advice is always try making your file names unique, this will bring a much better debuggability in your project. i use that feature a lot, just search with the folder name, then "package" https://i.imgur.com/cHb7isl.png it's also very useful to avoid having all of your code in a giant unreadable single file it's also very useful to avoid using dub.. just an import path to the folder and that's it https://i.imgur.com/Wy6WOXK.png also very useful when you want to simplify using importc, put your c files under the c folder, and the package.d, public import the c files, and you can put some helper code in D there, very nice to have I believe that needing to write `package.d` manually is pretty useless. Most of the time it means "import everything from this directory". The only real usage that helped me is when I needed to create a `version(Release) import something.opt; else version(Debug) import something.hotload;` basically. But that does not really require package.d. Those historic issues that Adam said are the real cause of their current design. Take into account how would you do it in Java. `import mypackage.*;` is how it was done, and I haven't never had any problem doing this, and this is pretty descriptive. package.d feels a lot more Haxe's `import.hx`, but it has a main difference that import.hx is a REAL special file that changes a bit on what happens on your source files. They are automatically included in its dir/subdir (think of a per directory object.d). The problem is that I'm not saying package.d is worthless, but it is a pool of bugs in the language that needs a real fix and only that post has already showed 4 bugs people have had. (Although I still don't like searching files by package.d, it is counter intuitive).
