Re: Dub failing to use the linker correctly.
On Friday, 22 October 2021 at 21:57:02 UTC, Ruby The Roobster wrote: On Friday, 22 October 2021 at 21:21:41 UTC, jfondren wrote: On Friday, 22 October 2021 at 19:56:37 UTC, Ruby The Roobster wrote: I have a simple vibe-d project built with dub. Running the command, dub build --force returns the following output: I'd start by running `dub -v build --force` instead, to see the exact commands that dub is running. Nevermind. I edited the source and it seems to work for some reason. For better context, changing ``` shared static this()``` to ``` void main()``` fixed the problem.
Re: Why do we have Dmain?
On Friday, 22 October 2021 at 09:01:53 UTC, Kagamin wrote: Actually C runtime is many megabytes in size. A couple of samples: $ wc -c /usr/lib/libc-2.33.so 2150424 /usr/lib/libc-2.33.so % wc -c /lib/libc.so.7 1981952 /lib/libc.so.7 I would hardly call two megabytes 'many'.
Re: Dub failing to use the linker correctly.
On 10/22/21 5:21 PM, jfondren wrote: On Friday, 22 October 2021 at 19:56:37 UTC, Ruby The Roobster wrote: I have a simple vibe-d project built with dub. Running the command, dub build --force returns the following output: I'd start by running `dub -v build --force` instead, to see the exact commands that dub is running. Note that dub -v does not tell you what DMD passes to the linker. I've complained about this before, but I think on discord/slack. The way you have to see the linker commands is use dub -v to get the link command (which calls dmd), and then copy/paste that command adding the -v flag. Which doesn't always work, since dub will sometimes use temporary files/directories. -Steve
Re: Dub failing to use the linker correctly.
On Friday, 22 October 2021 at 21:21:41 UTC, jfondren wrote: On Friday, 22 October 2021 at 19:56:37 UTC, Ruby The Roobster wrote: I have a simple vibe-d project built with dub. Running the command, dub build --force returns the following output: I'd start by running `dub -v build --force` instead, to see the exact commands that dub is running. Nevermind. I edited the source and it seems to work for some reason.
Re: Dub failing to use the linker correctly.
On Friday, 22 October 2021 at 19:56:37 UTC, Ruby The Roobster wrote: I have a simple vibe-d project built with dub. Running the command, dub build --force returns the following output: I'd start by running `dub -v build --force` instead, to see the exact commands that dub is running.
Dub failing to use the linker correctly.
I have a simple vibe-d project built with dub. Running the command, dub build --force returns the following output: Performing "debug" build using E:\Programs\D\dmd2\windows\bin\dmd.exe for x86_64. mir-linux-kernel 1.0.1: building configuration "library"... taggedalgebraic 0.11.22: building configuration "library"... eventcore 0.9.18: building configuration "winapi"... stdx-allocator 2.77.5: building configuration "library"... vibe-core 1.21.0: building configuration "winapi"... vibe-d:crypto 0.9.4: building configuration "library"... vibe-d:utils 0.9.4: building configuration "library"... vibe-d:data 0.9.4: building configuration "library"... diet-ng 1.8.0: building configuration "library"... vibe-d:stream 0.9.4: building configuration "library"... vibe-d:textfilter 0.9.4: building configuration "library"... vibe-d:inet 0.9.4: building configuration "library"... vibe-d:tls 0.9.4: building configuration "openssl-mscoff"... vibe-d:http 0.9.4: building configuration "library"... vibe-d:mail 0.9.4: building configuration "library"... vibe-d:mongodb 0.9.4: building configuration "library"... vibe-d:redis 0.9.4: building configuration "library"... vibe-d:web 0.9.4: building configuration "library"... vibe-d 0.9.4: building configuration "vibe-core"... web ~master: building configuration "application"... Compiling Diet HTML template caccount.dt... Linking... lld-link: error: subsystem must be defined Error: linker exited with status 1 Does anybody know why this happens? I am on the latest version of the dmd compiler(2.098.0.) Thanks in advance.
Re: Can we use "ImportC" used yet?
On Friday, 22 October 2021 at 06:11:35 UTC, data pulverizer wrote: On Thursday, 21 October 2021 at 23:06:18 UTC, jfondren wrote: [...] I've double-checked and the types names are fine in translated C file. [...] I think you ran into this [issue](https://issues.dlang.org/show_bug.cgi?id=22404). The bug fix isn’t part of a released dmd yet.
Re: TimeoutException for connecting to MySQL using a hunt-entity.
On Friday, 22 October 2021 at 11:42:34 UTC, greenbyte wrote: Hi, all! I use the hunt-entity library to work with MySQL. I get the hunt.Exceptions.TimeoutException: "Timeout in 30 secs" when trying to connect. I configured MySQL and ran the code from the instructions https://github.com/huntlabs/hunt-entity MySQL: mysql Ver 8.0.27 for Linux on x86_64 (MySQL Community Server - GPL) DUB: version 1.25.0, built on Apr 23 2021 In dub.json enabled "hunt-entity": "~>2.7.3" From the error message you posted it seems like it's failing to connect. Did you check that the IP address and port you are connecting to are correct? In case of localhost, try 127.0.0.1 instead of "localhost"
TimeoutException for connecting to MySQL using a hunt-entity.
Hi, all! I use the hunt-entity library to work with MySQL. I get the hunt.Exceptions.TimeoutException: "Timeout in 30 secs" when trying to connect. I configured MySQL and ran the code from the instructions https://github.com/huntlabs/hunt-entity MySQL: mysql Ver 8.0.27 for Linux on x86_64 (MySQL Community Server - GPL) DUB: version 1.25.0, built on Apr 23 2021 In dub.json enabled "hunt-entity": "~>2.7.3"
Re: Why do we have Dmain?
Actually C runtime is many megabytes in size.
Re: Why do we have Dmain?
On Friday, 22 October 2021 at 07:00:25 UTC, Mike Parker wrote: The entry point for your program is a function `_start`. That's implemented in the C runtime, which all D programs depend on. It in turn calls `main`, as it does for C and C++ programs. It is possible, in both C and D, to write your own `_start` and not depend on the C runtime. This is something you want to do only if necessary though - C runtime is so small that you don't want to drop it for any realistic desktop or even a smartphone program. The usual reason to do this is if there is no C runtime easily available - meaning mainly embedded targets.
Re: Why do we have Dmain?
On Friday, 22 October 2021 at 07:00:25 UTC, Mike Parker wrote: [...] Thank you for such a clear explanation Mike and for a quick reply!
Re: Why do we have Dmain?
On Friday, 22 October 2021 at 05:54:21 UTC, Kirill wrote: I am not a compiler expert, but I genuinely would like to know why we have Dmain. I've been looking at the generated assembly code recently and noticed the _Dmain function. I didn't notice it before. Then there is main, where Dmain is called. Why is that? The entry point for your program is a function `_start`. That's implemented in the C runtime, which all D programs depend on. It in turn calls `main`, as it does for C and C++ programs. The D compiler generates an `extern(C) main` function that hands control off to DRuntime for initialization, then in turn calling your application `main` (a.k.a. `_DMain`). See: https://github.com/dlang/druntime/blob/master/src/rt/dmain2.d#L245 If you declare your main function as `extern(C)`, then the compiler does not generate one and you get handed control from the C runtime. Which in turn means you have to handle initialization of the D runtime yourself.
Re: Can we use "ImportC" used yet?
On Thursday, 21 October 2021 at 23:06:18 UTC, jfondren wrote: On Thursday, 21 October 2021 at 22:23:50 UTC, data pulverizer wrote: I'd first check that the type names look OK in the processed C. If they do, then it's an importc bug. Those are still getting reported, but yours might be new. Worth checking out. I've double-checked and the types names are fine in translated C file. It might also be a bug that's been fixed since release--try dmd master on it. I have the latest compiler installed and I just double-checked by compiling dmd-master with the same result. The specific error is: ``` Error: function `Rf_allocVector(__tag28, long)` is not callable using argument types `(int, long)` cannot pass argument `REALSXP` of type `int` to parameter `__tag28` ``` Here `__tag28` should be `SEXPTYPE` which is an `enum int` containing `REALSXP`. Another (superficial by maybe related) issue is that `REALSXP` is an `SEXPTYPE` which is an `enum int` under the hood but dmd skips the `SEXPTYPE` description altogether, even though SEXPTYPE is correctly converted in the imported C file. Also, with some definitions in the C file, when I try to `#undef` something to get some conditional C definitions to be converted with `gcc -E -P ...`, nothing happens. d doesn't do any C preprocessing, so any problem here is with gcc. Your `#undef`s may be coming before the C preprocessor's own `#define`s and have no effect. I thought I'd ask anyway, it looks like a question for the R community, where `#undef R_NO_REMAP` in the script has no effect. This is unrelated to the first issue. As @Imperatorn said (and I was aware as I asked the question) this is a new feature that is currently being worked on, and we should expect and report stuff like this. It's a great feature and lots of people will use it heavily. Including myself.
