Windows static linking question
From my source...
```d
// main.d
pragma(lib, common.lib);
extern (C) void fun(bool something);
```
```d
// common.d
export extern (C) void fun(bool something) {
// ...
}
```
...I'm creating a static linked DLL with this command...
```
rdmd --build-only -L/DLL -L/OUT:common.dll -m64 -of=common.dll
common.d
```
... and this works.
However, I get a ```std.file.FileException@std\file.d(991):
Attempting to rename file common.dll.tmp to common.dll``` error
every time at compiling because of the ```-L/OUT``` argument. But
I cannot omit it because it would create and link a
common.dll.tmp instead - for whatever reason.
I know there is a ```-lib``` switch which also can create a
common.lib, but that's obviously not the same as the LIB does not
target to the DLL and the code ends just compiled in than linked.
So, is there another switch combo to achieve static linking by
creating a LIB-file? Like a ```-lib -target=```?
Re: Windows static linking question
On Tuesday, 27 April 2021 at 06:29:40 UTC, frame wrote: From my source... ```d // main.d pragma(lib, common.lib); extern (C) void fun(bool something); ``` [...] Did you mean to use rdmd and not dmd? 樂
Re: Windows static linking question
On Tuesday, 27 April 2021 at 07:13:16 UTC, Imperatorn wrote: On Tuesday, 27 April 2021 at 06:29:40 UTC, frame wrote: From my source... ```d // main.d pragma(lib, common.lib); extern (C) void fun(bool something); ``` [...] Did you mean to use rdmd and not dmd? 樂 I could not get it working using dmd. It gaves me LNK2001 linker errors. I honestly have no idea what rdmd else applies to the linker (should inspect it with sysinternals). But this should not have any impact on the LIB-file. I build the EXE also with rdmd and if the LIB-file contains the link to the DLL everything is fine.
Re: Windows static linking question
On Tuesday, 27 April 2021 at 07:55:53 UTC, Mike Parker wrote: On Tuesday, 27 April 2021 at 07:41:28 UTC, frame wrote: Did you mean to use rdmd and not dmd? 樂 I could not get it working using dmd. It gaves me LNK2001 linker errors. I honestly have no idea what rdmd else applies to the linker (should inspect it with sysinternals). What is your dmd command line? not very different: ``` dmd -L/DLL -L/OUT:common.dll -m64 -of=common.dll -I=sources common.d ```
Re: Windows static linking question
On Tuesday, 27 April 2021 at 07:41:28 UTC, frame wrote: Did you mean to use rdmd and not dmd? 樂 I could not get it working using dmd. It gaves me LNK2001 linker errors. I honestly have no idea what rdmd else applies to the linker (should inspect it with sysinternals). What is your dmd command line?
Re: Windows static linking question
On Tuesday, 27 April 2021 at 08:33:23 UTC, frame wrote: On Tuesday, 27 April 2021 at 07:55:53 UTC, Mike Parker wrote: On Tuesday, 27 April 2021 at 07:41:28 UTC, frame wrote: Did you mean to use rdmd and not dmd? 樂 I could not get it working using dmd. It gaves me LNK2001 linker errors. I honestly have no idea what rdmd else applies to the linker (should inspect it with sysinternals). What is your dmd command line? not very different: ``` dmd -L/DLL -L/OUT:common.dll -m64 -of=common.dll -I=sources common.d ``` What specifically are the linker errors? Is it referring to `_DLLMainCRTStartup` or something else? Also, I suspect the reason you're getting the renaming errors with rdmd is because you're passing both `-L/OUT:common.dll` and `-of=common.dll`. You should only need one of them (same goes for dmd). But I don't think rdmd is intended to actually compile a distributable binary. You should try to get this working with dmd to solve your linker errors.
Re: Windows static linking question
On Tuesday, 27 April 2021 at 10:43:20 UTC, frame wrote: On Tuesday, 27 April 2021 at 08:50:37 UTC, Mike Parker wrote: What specifically are the linker errors? Is it referring to `_DLLMainCRTStartup` or something else? Various "unresolved external symbol", mostly ```..._ClassZ```, ```...__ModuleInfoZ```, ```..._initZ``` from my classes and functions but also ```_D3std5regex__T8CapturesTAyaZQo6__initZ``` Also, I suspect the reason you're getting the renaming errors with rdmd is because you're passing both `-L/OUT:common.dll` and `-of=common.dll`. No, it's caused by ```-L/OUT``` only. ```-of``` is redudant here indeed, but doesn't change anything. So you have more than just common.d? You need to compile and link all of your source modules. The big `-I` is for imports, for the compiler to know what symbols are available. You will also need to either include all of the source files on the command line OR specify `-i`, which will tell the compiler to compile all imported files except the `std` namespace. rdmd does that by default.
Re: Windows static linking question
On Tuesday, 27 April 2021 at 08:50:37 UTC, Mike Parker wrote: What specifically are the linker errors? Is it referring to `_DLLMainCRTStartup` or something else? Various "unresolved external symbol", mostly ```..._ClassZ```, ```...__ModuleInfoZ```, ```..._initZ``` from my classes and functions but also ```_D3std5regex__T8CapturesTAyaZQo6__initZ``` Also, I suspect the reason you're getting the renaming errors with rdmd is because you're passing both `-L/OUT:common.dll` and `-of=common.dll`. No, it's caused by ```-L/OUT``` only. ```-of``` is redudant here indeed, but doesn't change anything.
Install of nightly with install.sh is not latest version
When using the install.sh script and choosing 'dmd-nightly' I'm currently getting DMD v2.091.0-beta.2-master-ec39fe5 (the folder downloaded is dmd-master-2020-03-10). I can install a more recent version using install 'dmd' etc. Is this a bug? Or am I just using it incorrectly? Cheers
Re: Windows static linking question
On Tuesday, 27 April 2021 at 11:08:29 UTC, Mike Parker wrote: So you have more than just common.d? You need to compile and link all of your source modules. The big `-I` is for imports, for the compiler to know what symbols are available. You will also need to either include all of the source files on the command line OR specify `-i`, which will tell the compiler to compile all imported files except the `std` namespace. rdmd does that by default. Indeed, rdmd passes some other files too. Ahh.. this makes sense now. I know the option but I always thought it's enabled on default. Thanks!
Re: DIP1000 and immutable
On Tuesday, 27 April 2021 at 14:28:12 UTC, jmh530 wrote: However, should it ever matter if you escape an immutable? Your example is a pretty clear case of use-after-free if gloin actually did escape the reference and kept it after main returned. I tried basically the same thing in Rust and it doesn't generate errors (their borrow checker should be assuming scope by default). That means it treats gloin as if it is scope, so it isn't the same as your D code since the gloin there is NOT borrowing.
Re: DIP1000 and immutable
On Tuesday, 27 April 2021 at 14:44:48 UTC, Adam D. Ruppe wrote: On Tuesday, 27 April 2021 at 14:28:12 UTC, jmh530 wrote: However, should it ever matter if you escape an immutable? Your example is a pretty clear case of use-after-free if gloin actually did escape the reference and kept it after main returned. I tried basically the same thing in Rust and it doesn't generate errors (their borrow checker should be assuming scope by default). That means it treats gloin as if it is scope, so it isn't the same as your D code since the gloin there is NOT borrowing. Hmmm, good points. Thanks.
Re: vibe-core sporadic internal errors
On Tuesday, 27 April 2021 at 15:48:01 UTC, Steven Schveighoffer wrote: I suspect vibe-core or event core may have some subtle bugs in them that are not easily repeatable, but often result in half-rendered web pages. [...] Need a full trace to be able to get anywhere I think.
Re: Install of nightly with install.sh is not latest version
On Tuesday, 27 April 2021 at 12:35:52 UTC, Jamie wrote: When using the install.sh script and choosing 'dmd-nightly' I'm currently getting DMD v2.091.0-beta.2-master-ec39fe5 (the folder downloaded is dmd-master-2020-03-10). I can install a more recent version using install 'dmd' etc. Is this a bug? Or am I just using it incorrectly? Cheers Which I think stems from that fact that the nightly releases aren't updated here: http://downloads.dlang.org/nightlies/
vibe-core sporadic internal errors
I suspect vibe-core or event core may have some subtle bugs in them that are not easily repeatable, but often result in half-rendered web pages. Has anyone else seen this? I recently updated to the latest vibe-core and vibe to see if the problem goes away and it doesn't. A log of the exceptions isn't super helpful: ``` Error occurred while accessing /management/sales/translate_option: code 500, (Internal Server Error) Stack Trace: Internal Server Error Error occurred while accessing /management/sales/translate_option: code 500, (Internal Server Error) Stack Trace: Internal Server Error Error occurred while accessing /management/sales/translate_option: code 500, (Internal Server Error) Stack Trace: Internal Server Error Error occurred while accessing /management/sales/translate_option: code 500, (Internal Server Error) Stack Trace: Internal Server Error ``` I also get occasional segfaults. In the distant past, I had problems so frequent that the site required frequent refreshes to get to the next page, and some of my REST-based apps failed. But upgrading to the newest vibe made that much less frequent. But still, it concerns me with the frequency that this happens. I don't know where to begin to debug this. I'll turn tracing on to see if it garners any more information. -Steve
DIP1000 and immutable
What is the motivation for DIP1000 also applying to immutable?
For instance, in the code (compiled with -dip1000), adapted from
the spec [1], you get the same errors with immutable function
parameters as you would with mutable ones. However, should it
ever matter if you escape an immutable?
```d
@safe:
void thorin(scope immutable(int)*) {}
void gloin(immutable(int)*) {}
immutable(int)* balin(scope immutable(int)* q)
{
thorin(q);
gloin(q); // error, gloin() escapes q
return q; // error, cannot return 'scope' q
}
void main() {
immutable(int) x = 2;
immutable(int)* ptrx =
immutable(int)* ptrz = balin(ptrx);
}
```
I tried basically the same thing in Rust and it doesn't generate
errors (their borrow checker should be assuming scope by default).
```rust
#![allow(unused_variables)]
fn gloin(x: ) {
}
fn ballin(x: ) -> {
gloin(x);
return x;
}
fn main() {
let x = 2;
let ptrx =
let ptrz = ballin(ptrx);
}
```
[1] https://dlang.org/spec/function.html#scope-parameters
