dub ldc2 static linking
Dear All, I am trying to create a static executable to be able to run it on virtually any linux x86_64 OS. At the end I get a binary, however, multiple warnings are printed after compilation. My dub.sdl: dependency "mir" version="~>3.2.3" dependency "lubeck" version="~>1.5.1" lflags "-lopenblas" "-lgfortran" dflags "--static" "-O3" dub build --force --compiler=path_to_ldc/ldc2 curl.d:(.text._D3std3net4curl7CurlAPI7loadAPIFZPv+0xd): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking and many other warnings like this. What am I doing wrong? Any way to fix it?
Re: dub ldc2 static linking
On Thursday, 27 October 2022 at 08:08:38 UTC, Yura wrote: What am I doing wrong? Any way to fix it? https://forum.dlang.org/thread/gghcyaapjwfcpnvks...@forum.dlang.org worked for me.
Re: dub ldc2 static linking
Thank you! I tried this one, but it did not help. All these warnings survived : "... Using 'getservbyport' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking" On Thursday, 27 October 2022 at 14:18:01 UTC, Anonymouse wrote: On Thursday, 27 October 2022 at 08:08:38 UTC, Yura wrote: What am I doing wrong? Any way to fix it? https://forum.dlang.org/thread/gghcyaapjwfcpnvks...@forum.dlang.org worked for me.
Re: Importing modules under DUB on Windows
On Thursday, 27 October 2022 at 00:35:26 UTC, Hipreme wrote: On Wednesday, 26 October 2022 at 22:51:53 UTC, DLearner wrote: On Wednesday, 26 October 2022 at 18:53:58 UTC, Hipreme wrote: On Wednesday, 26 October 2022 at 18:37:00 UTC, DLearner wrote: [...] The linker failed to resolve because it didn't include the symbols you imported. Think of import a way to the compiler resolve the compilation. Think of source a way to both the compiler and the linker to resolve compilation and linking. If you give only the import path, you will need a library. What you actually want is to put your new importPath to the JSON array `sourcePaths` Added `"sourcePaths": [ "C\\Users\\..." ]` Unfortunately failed with `core.exception.AssertError@source\dub\internal\vibecompat\inet\path.d(222): Trying to append absolute path.` I tried to construct a relative path to the module directory from the project directory, that didn't work either. Okay. So this error is very strange, the other thing I can give you advice is: If your other thing is another dub project, you can add it as a dependency by putting in your dub.json ```json "dependencies" : { "your_project_name" : {"path" : "your/path/here"} } ``` AFAIK, there is no problem in putting an absolute path dependency, in fact, I'm using things from another drive letter. Hi I'm not getting on with DUB. Maybe fewer people use it under Windows, so Windows constructs don't get exercised so much. Is there a non-DUB way of arranging that `import arsd.terminal;` will use that module as held on GitHub? (DUB name: "arsd-official:terminal": "~>10.9.4"). OS: Windows 10. Compiler: DMD. Best regards
how to benchmark pure functions?
Hi, when trying to compare different implementations of the optimized builds of a pure function using benchmark from std.datetime.stopwatch, I get times equal to zero, I suppose because the functions are not executed as they do not have side effects. The same happens with the example from the documentation: https://dlang.org/library/std/datetime/stopwatch/benchmark.html How can I prevent the compiler from removing the code I want to measure? Is there some utility in the standard library or pragma that I should use? Thanks AB
Re: how to benchmark pure functions?
On Thursday, 27 October 2022 at 17:17:01 UTC, ab wrote: Hi, when trying to compare different implementations of the optimized builds of a pure function using benchmark from std.datetime.stopwatch, I get times equal to zero, I suppose because the functions are not executed as they do not have side effects. The same happens with the example from the documentation: https://dlang.org/library/std/datetime/stopwatch/benchmark.html How can I prevent the compiler from removing the code I want to measure? Is there some utility in the standard library or pragma that I should use? Thanks AB Sorry, I don't understand what you're saying. The examples work for me. Can you provide an exact code example which does not work as expected for you?
Re: how to benchmark pure functions?
On Thu, Oct 27, 2022 at 06:20:10PM +, Imperatorn via Digitalmars-d-learn wrote: > On Thursday, 27 October 2022 at 17:17:01 UTC, ab wrote: > > Hi, > > > > when trying to compare different implementations of the optimized > > builds of a pure function using benchmark from > > std.datetime.stopwatch, I get times equal to zero, I suppose because > > the functions are not executed as they do not have side effects. > > > > The same happens with the example from the documentation: > > https://dlang.org/library/std/datetime/stopwatch/benchmark.html > > > > How can I prevent the compiler from removing the code I want to > > measure? Is there some utility in the standard library or pragma > > that I should use? [...] To prevent the optimizer from eliding the function completely, you need to do something with the return value. Usually, this means you combine the return value into some accumulating variable, e.g., if it's an int function, have a running int accumulator that you add to: int funcToBeMeasured(...) pure { ... } int accum; auto results = benchmark!({ // Don't just call funcToBeMeasured and ignore the value // here, otherwise the optimizer may delete the call // completely. accum += funcToBeMeasured(...); }); Then at the end of the benchmark, do something with the accumulated value, like print out its value to stdout, so that the optimizer doesn't notice that the value is unused, and decide to kill all previous assignments to it. Something like `writeln(accum);` at the end should do the trick. T -- Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg
Re: how to benchmark pure functions?
On Thursday, 27 October 2022 at 17:17:01 UTC, ab wrote: How can I prevent the compiler from removing the code I want to measure? With many C compilers, you can use volatile assembly blocks for that. With LDC -O3, a regular assembly block also does the trick currently: ```D void main() { import std.datetime.stopwatch; import std.stdio: write, writeln, writef, writefln; import std.conv : to; void f0() {} void f1() { foreach(i; 0..4_000_000) { // nothing, loop gets optimized out } } void f2() { foreach(i; 0..4_000_000) { // defeat optimizations asm @safe pure nothrow @nogc {} } } auto r = benchmark!(f0, f1, f2)(1); writeln(r[0]); // 4 μs writeln(r[1]); // 4 μs writeln(r[2]); // 1 ms } ```
Re: Importing modules under DUB on Windows
On 28/10/2022 5:40 AM, DLearner wrote: Maybe fewer people use it under Windows, so Windows constructs don't get exercised so much. I have actively contributed to dub specifically for Windows in the last year :) There is enough of us. Also UNC paths (those with drives and then the slash) are actually absolute, not relative. There are relative ones, but the path processing in dub is pretty simplified. You have to stick to completely relative, POSIX style. https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats You should be working with relatives paths in respect to the $PACKAGE_DIR, not the compiler or any root location of your file system (such as the drive would indicate). https://dub.pm/package-format-json.html#environment-variables
Re: dub ldc2 static linking
On Thursday, 27 October 2022 at 08:08:38 UTC, Yura wrote: curl.d:(.text._D3std3net4curl7CurlAPI7loadAPIFZPv+0xd): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking and many other warnings like this. What am I doing wrong? Any way to fix it? This has nothing to do with dub and is not a D issue specifically. Enter your error message in Google and you'll get a long list of results. Maybe one of them can help you.
Re: dub ldc2 static linking
For fully static linking on Linux, you'll need to move away from glibc to e.g. the musl C runtime, as used by the Alpine distro.
Re: dub ldc2 static linking
On Friday, 28 October 2022 at 01:37:50 UTC, Mike Parker wrote: This has nothing to do with dub and is not a D issue specifically. Enter your error message in Google and you'll get a long list of results. Maybe one of them can help you. Or do what kinke suggests :-)
Re: Importing modules under DUB on Windows
On Thursday, 27 October 2022 at 16:40:20 UTC, DLearner wrote: I'm not getting on with DUB. Maybe fewer people use it under Windows, so Windows constructs don't get exercised so much. Is there a non-DUB way of arranging that `import arsd.terminal;` will use that module as held on GitHub? (DUB name: "arsd-official:terminal": "~>10.9.4"). OS: Windows 10. Compiler: DMD. This has nothing to do with Windows. The source path error you encountered is an assertion failure that tells you what's wrong: dub does not allow you to add absolute paths to the source path. I don't know why. If you disagree, then you can file an issue in the dub github repository. In the meantime, you'll need to work around the limitation. You could 1. Add the file to your source tree 2. Use a relative path in `sourcePaths` 2. Add arsd-official as a dub dependency All of these would solve the problem. If you aren't going to do any of these things, then you'll need a fourth option. The compiler (not dub) needs to know where to find imports, and the linker needs an object file to resolve symbols. So you should: 1. Compile /arsd/terminal.d as a static library with ldc (named e.g., "arsd-terminal.lib") and output the library to the path where you want it (e.g., C:\libs) 2. Add the parent directory of the arsd folder to your `importPaths` in dub. 3. Add linker flags to your dub project to tell the compiler where to find the library You have two options for #3. If this is the only external libs you're working with, then you can just add the full path to the library in an `libs` entry: ```json "libs": ["C:\\libs\\arsd-terminal"] ``` Note that you do not add the ".lib" extension here. Dub will do that for you. If you have multiple external libs, then it's better to add the library path like so: ```json "lflags": ["/LIBPATH:C:\\libs"], "libs": ["lib1", "lib2", "lib3"] ``` Note that `/LIBPATH` is specific to the Microsoft linker, which I assume LDC uses on Windows: https://learn.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath?view=msvc-170 If it's using the LLVM linker, then you'll need the appropriate flag for that. If you aren't planning to build on other platforms, then you'll want to make these dub directives platform specific, e.g., `libs-windows` rather than `libs`.
Re: dub ldc2 static linking
On Friday, 28 October 2022 at 01:35:04 UTC, kinke wrote: For fully static linking on Linux, you'll need to move away from glibc to e.g. the musl C runtime, as used by the Alpine distro. I'm just right now having an issue with glibc version mismatch for my server, so i'm looking to move to musl to avoid that kind of issues Is there any guide to compile ldc with musl and then static link it?
Re: dub ldc2 static linking
On Friday, 28 October 2022 at 02:46:42 UTC, ryuukk_ wrote: On Friday, 28 October 2022 at 01:35:04 UTC, kinke wrote: For fully static linking on Linux, you'll need to move away from glibc to e.g. the musl C runtime, as used by the Alpine distro. I'm just right now having an issue with glibc version mismatch for my server, so i'm looking to move to musl to avoid that kind of issues Is there any guide to compile ldc with musl and then static link it? Actually nvm, `-static` as mentioned above seems to be enough
Re: dub ldc2 static linking
On Friday, 28 October 2022 at 04:02:15 UTC, ryuukk_ wrote: On Friday, 28 October 2022 at 02:46:42 UTC, ryuukk_ wrote: On Friday, 28 October 2022 at 01:35:04 UTC, kinke wrote: For fully static linking on Linux, you'll need to move away from glibc to e.g. the musl C runtime, as used by the Alpine distro. I'm just right now having an issue with glibc version mismatch for my server, so i'm looking to move to musl to avoid that kind of issues Is there any guide to compile ldc with musl and then static link it? Actually nvm, `-static` as mentioned above seems to be enough Static on alpine is possible - be aware of ‘ldc-static’ package. But static and LTO is something harder.. is it even possible without re-compilation of ldc-runtime? https://forum.dlang.org/thread/newwjfrebckphgwga...@forum.dlang.org